I always feel like mainframes are off in some weird parallel universe.
Well they are. These things are built for a specific audience and it so happens that they are still willing to spend money on this, otherwise it wouldn't be made, especially not by IBM that is otherwise quick to disband business units that don't make heaps of money.
In my research I'm using an even older language: Fortran. Believe it or not, but in a field that is less narrow and specific than you would think[1], there's still no real replacement for (modern) Fortran.
[1] numeric applications that need to get close to the hardware's peak performance, written in a higher level language than C that is usable by non-CS-graduates.
It's not just learnability. In some cases, Fortran can be considered to be faster than C since it can apply something like -fno-strict-alisasing by default.
Not to mention that most compilers have OpenMP suport built-in. Also, there's the tons of heavily-optimized Fortran math libraries that make it easy to take advantage of big machines and big clusters.
Those scientists that are still using Fortran after all these years know what they're doing. It's not that they're ignorant of new technoglogy. A well-informed and open-minded CS person would probably end up using Fortran for these use cases, too.
It's not just learnability. In some cases, Fortran can be considered to be faster than C since it can apply something like -fno-strict-alisasing by default.
Yes. In my experience, you can make C as fast as Fortran, but it will be a lot more work (and you need more knowledge about the machine). Fortran's defaults are very strong when it comes to crunching numbers as quickly as possible. Multidimensional arrays with Matlab-like slicing and operations, implemented as performant as possible, is enough reason alone to stay with Fortran.
Those scientists that are still using Fortran after all these years know what they're doing. It's not that they're ignorant of new technoglogy. A well-informed and open-minded CS person would probably end up using Fortran for these use cases, too.
Well, I'm sort of coming out of CS (computer engineering with focus on software) and I'm using it, so there ;)
I always wonder why you can't just add a library to another language to get most of the features of somebody else's favorite language. If not a library, couldn't any other language add matlab style matrices and end up being as good as it, fortran, etc? Do we really need a whole different language with a whole different set of arbitrary rules just so a few features are easier or faster?
For Fortran style multidimensional arrays, libraries fly right out the window. First of all, you need slicing syntax and operators baked into the language. The compiler needs to be aware of the array's storage order, such that it can implement operations like A + B optimally for A, B as n-dimensional arrays. Then it needs to be aware of their boundaries, such that it can align the memory optimally.
So that leaves language level support. So far the only contender that I can see coming up is Julia - and it will take a lot of effort until it can reach performance levels on par with Fortran. This basically would require a big push by one of the big software companies - who all aren't making a lot of money in HPC software anymore. I could see Nvidia picking up the ball at some point, it would suit them well - but then we're getting into vendor lock-in again.
Sure. That is what you get e.g. with NumPy in Python. However, as you already said you only get "most" of it. The remaining niche is still large enough that Fortran has lots of users.
One of many possible reasons is the way arrays are stored. In a matrix representation, should the memory be laid out one row at a time or one column at a time? It's mostly an arbitrary decision, but different languages have made differennt choices.
If you wanted to take a native Fortran matrix and turn it into a native C matrix, you'd either need to copy everything to re-arrange the in-memory layout or do funky things with the indexing. Neither option is great.
---
Bringing it back to a higher level, I'd agree that your point makes sense most of the time. In most cases, the cost of a memcpy(3) would be a rounding error. That's certainly the case for most web applications. In a tight loop in a math-heavy application, though, the standards are a bit higher.
One disadvantage of libraries is that the compiler treats them as regular code. If something is baked into the language, the compiler and run time (if any) can reason about particular operations and optimize them.
To be fair, anyone who uses numpy or scipy ends up using Fortran even if they don't know it. A lot of scientific libraries have been ultra optimized for Fortran.
I'm sure optimized libraries could be written in any language, however the vast number of researchers have decided that Fortran is by far more accurate and faster (for these libraries) so they go with that.
optimized libraries could be written in any language
Well, at least in anything that has really performant compilers. That's currently true for C, Fortran and Assembly, to some extent also C++. Between the first three, Fortran is by far the easiest to use for numerics - its syntax is in fact not much more difficult than Matlab. It's clunky in anything but numerical code (such as when you try to create a nice API or when you try to have generic methods), but at the end it still wins.
Comments
Well they are. These things are built for a specific audience and it so happens that they are still willing to spend money on this, otherwise it wouldn't be made, especially not by IBM that is otherwise quick to disband business units that don't make heaps of money.
In my research I'm using an even older language: Fortran. Believe it or not, but in a field that is less narrow and specific than you would think[1], there's still no real replacement for (modern) Fortran.
[1] numeric applications that need to get close to the hardware's peak performance, written in a higher level language than C that is usable by non-CS-graduates.
It's not just learnability. In some cases, Fortran can be considered to be faster than C since it can apply something like -fno-strict-alisasing by default.
Not to mention that most compilers have OpenMP suport built-in. Also, there's the tons of heavily-optimized Fortran math libraries that make it easy to take advantage of big machines and big clusters.
Those scientists that are still using Fortran after all these years know what they're doing. It's not that they're ignorant of new technoglogy. A well-informed and open-minded CS person would probably end up using Fortran for these use cases, too.
Yes. In my experience, you can make C as fast as Fortran, but it will be a lot more work (and you need more knowledge about the machine). Fortran's defaults are very strong when it comes to crunching numbers as quickly as possible. Multidimensional arrays with Matlab-like slicing and operations, implemented as performant as possible, is enough reason alone to stay with Fortran.
Well, I'm sort of coming out of CS (computer engineering with focus on software) and I'm using it, so there ;)
I always wonder why you can't just add a library to another language to get most of the features of somebody else's favorite language. If not a library, couldn't any other language add matlab style matrices and end up being as good as it, fortran, etc? Do we really need a whole different language with a whole different set of arbitrary rules just so a few features are easier or faster?
For Fortran style multidimensional arrays, libraries fly right out the window. First of all, you need slicing syntax and operators baked into the language. The compiler needs to be aware of the array's storage order, such that it can implement operations like A + B optimally for A, B as n-dimensional arrays. Then it needs to be aware of their boundaries, such that it can align the memory optimally.
So that leaves language level support. So far the only contender that I can see coming up is Julia - and it will take a lot of effort until it can reach performance levels on par with Fortran. This basically would require a big push by one of the big software companies - who all aren't making a lot of money in HPC software anymore. I could see Nvidia picking up the ball at some point, it would suit them well - but then we're getting into vendor lock-in again.
Sure. That is what you get e.g. with NumPy in Python. However, as you already said you only get "most" of it. The remaining niche is still large enough that Fortran has lots of users.
http://www.numpy.org/
One of many possible reasons is the way arrays are stored. In a matrix representation, should the memory be laid out one row at a time or one column at a time? It's mostly an arbitrary decision, but different languages have made differennt choices.
http://en.wikipedia.org/wiki/Row-major_order explains it nicely.
If you wanted to take a native Fortran matrix and turn it into a native C matrix, you'd either need to copy everything to re-arrange the in-memory layout or do funky things with the indexing. Neither option is great.
---
Bringing it back to a higher level, I'd agree that your point makes sense most of the time. In most cases, the cost of a memcpy(3) would be a rounding error. That's certainly the case for most web applications. In a tight loop in a math-heavy application, though, the standards are a bit higher.
One disadvantage of libraries is that the compiler treats them as regular code. If something is baked into the language, the compiler and run time (if any) can reason about particular operations and optimize them.
couldn't any other language add matlab style matrices and end up being as good as it, fortran, etc?
In theory, sure. In practice a bunch of languages have tried and yet Fortran is still the king.
To be fair, anyone who uses numpy or scipy ends up using Fortran even if they don't know it. A lot of scientific libraries have been ultra optimized for Fortran.
I'm sure optimized libraries could be written in any language, however the vast number of researchers have decided that Fortran is by far more accurate and faster (for these libraries) so they go with that.
Well, at least in anything that has really performant compilers. That's currently true for C, Fortran and Assembly, to some extent also C++. Between the first three, Fortran is by far the easiest to use for numerics - its syntax is in fact not much more difficult than Matlab. It's clunky in anything but numerical code (such as when you try to create a nice API or when you try to have generic methods), but at the end it still wins.