Fortress - the future math programming language ?

[Vlad]

I just want to share with you a subject I was following for some time : Fortress. It may be just a look into the future and it may not even happen(be used) at all. We are still going to use C++ <> . But some companies will have another option on the table. A BSD open source was released recently and it is available for download.
---
Fortress is a new programming language designed for high-performance computing (HPC) with high programmability.
Fortress ~= replacement for Fortran, and runs on the 1.5 JVM.
Research funded by DARPA - High Productivity Computing Systems.
Try to make the mathematical parts of a program look like mathematics.
Key Ideas
• Don't build the language—grow it
• Make programming notation closer to math
• Ease use of parallelism
Fortress is designed to make parallel programming as painless as possible.
Fortress automatically breaks the job into pieces and farms each piece out to different cores, processors or servers.

Sample code for Fortress implementation of Conjugate Gradient.
http://research.sun.com/projects/plrg/faq/NAS-CG.pdf

The NAS (NASA Advanced Supercomputing) Conjugate Gradient Parallel Benchmark is a small program used in high-performance computing to evaluate and compare performance of parallel supercomputers.
http://www.nas.nasa.gov/Resources/Software/npb.html

---
Links
http://research.sun.com/projects/plrg/
http://research.sun.com/projects/plrg/faq/index.html
http://research.sun.com/minds/2005-0302/
http://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdfhttp://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdf
http://fortress.sunsource.net/
---

 

[Andy Nguyen]

Vlad,
The code looks like a cross between C++ and Matlab. I'm curious to know the con/pro of Fortress and C++ MPI library ?

 

[Vlad]

Vlad,
The code looks like a cross between C++ and Matlab. I'm curious to know the con/pro of Fortress and C++ MPI library ?

I do not have a finalized opinion but here are my thoughts. To me the main thing is that it looks like they want the scientist/matematician to be free of knowing too much about software dev / machine architecture.
Regarding the pro/con/differences I can say that in one hand MPI is based on message passing and sometimes on a machine with multiple core CPUs it has an overhad in transferring that information. Plus you have to know all concurrency possible problems when you design your algorithm that implements the solution to your problem - parralel safe. Fortress has some built in capabilities : the loop is by default parralel. You do not need to know how it is done or if it runs on a PC with multiple CPUs or on a cluster/grid. For same machine processing Fortress looks like is using some sort of Software Transactional Memory (http://en.wikipedia.org/wiki/Software_transactional_memory) using shared memory as it is known that in java object level synchronization is slow.
I do not want to compare C++MPI with Fortress but comparing JavaMPI(DPPEJ) with Fortress is like comparing message passing with shared memory - faster. Message passing makes more performance-sense in a distributed environment. I think you can compare it with C++ or Fortran OpenMP locally and with MPI in distributed environment. Basically it comes down to how much money and how much time you have (how manny developers) to get the project done.
As we have today PCs with multiple core CPUs more effort is being put into providing parralel processing support at the language level and that is reflected in the language memory models.
IMHO looks like they want you to focus more on your core business logic.

 

[DominiConnor]

I like some of the ideas, and certainly am in favour of multithreading being both a defualt and discipline in the early development of the language.

 

[joe_bradley]

In case any of you are following this thread, I spotted this article in IEEE "Spectrum" magazine:

http://spectrum.ieee.org/jan07/4837

This describes a platform (the company's name is RapidMind) which uses an extension to C++ to automatically schedule and handle tasks in C++. If this is correct, the programmer must identify what portions need to run in parallel and how, but lets the programming platform take care of all the locking and scheduling on the multicore processors. It seems like a viable approach, given that the programmers who write this stuff should know what needs to run parallel and most developers would rather avoid learning yet _another_ language.

It also seems something like this will have to catch on - either an extension to a known language, or through a development platform. Dual cores are already standard, and most programmers have very little experience in writing the parallel code needed to take advantage of it.