121–130 of 136 posts
BLAS uses Fortran I think, and Lapack. Good luck calling that slow. Another clueless JS hipster, maybe.
The reference BLAS in Fortran is indeed slow. I'm not aware of any tuned version in Fortran. It might be possible to re-write the BLIS structure in Fortran and get reasonable performance on, say, Haswell, but not on SKX, if we talk x86.
Intel on HPCs.
Earlier quoted context omitted.
It took until C99 for C to have complex numbers and `restrict`. Those are two features FORTRAN has had for a much longer time, right?
I __think__ Fortran just never gave you this particular footgun. No aliasing of pointers allowed from the getgo. It was never an issue. Somebody let me know if that is wrong. I read Complex numbers came in FORTRAN IV, so mid 60’s. I never used anything older than FORTRAN 77, and it certainly had complex numbers, and also ways for the “inventive” programmer to make use of pointer like functionality. You could e.g. pas…
FYI, this link [PDF] https://personalpages.manchester.ac.uk/staff/paul.johnson-2/... contains the peculiar statement "Over the next few years, FORTRAN II would also add support for the DOUBLE PRECISION and COMPLEX data types."
At face value, that statement implies complex numbers came later but before FORTRAN III, which also implies a point release (FORTRAN II was released in 1958). Moreover, I read somewhere that FORTRAN III had it but it wasn't widely released. Likely then that FORTRAN IV was the first widely released version with complex numbers. As it was released in 1961, we should assume then that this was the likely date.
Earlier quoted context omitted.
That sounds like it belongs in the top 10% of the worst (programming-related) things I could wish upon another programmer: Having to maintain projects where you have to read the build system's configuration and keep it in mental context just to figure out if an array access is mathematically correct or not. I would imagine this support to be stomachable if it was active at all times but using a visually different syn…
It's hard enough to understand a codebase, but if a language was like Haskell for instance (you can enable certain extensions in Haskell with a flag at the top of a file), you could have a line at the top of a file defining that this file is 0 based, while maybe the default is 1 based for the language. It doesn't seem like that much more than you already have to consider in many languages.
I'm not familiar at all with the world of high performance scientific computing. Are C++, Rust, Nim, Zig, & co. even remotely considered as potential candidates in the future, or is it really only C and Fortran with no expectation to see much changes? Just curious.
C++ certainly, and I would not be surprised to see Rust in the near future. I have not seen anyone use Nim or Zig yet. There are also some special-purpose languages like Fortress (apparently now defunct), Coarray-Fortran, and Chapel, though none seems to have achieved too much market-share. Personally I have almost entirely switched to Julia (from mostly C), which lets me do my everyday plotting / analysis / interpre…
Earlier quoted context omitted.
C++ certainly, and I would not be surprised to see Rust in the near future. I have not seen anyone use Nim or Zig yet. There are also some special-purpose languages like Fortress (apparently now defunct), Coarray-Fortran, and Chapel, though none seems to have achieved too much market-share. Personally I have almost entirely switched to Julia (from mostly C), which lets me do my everyday plotting / analysis / interpre…
Wow, Julia is already good enough to replace C in that context? I didn't know.
If you wanted to use Julia at petascale or above (like the Celeste folks), then you'd probably want to be doing that in a case where you see fundamental algorithmic improvements you could readily make over the current SOTA with a higher level, dispatch-oriented language - or else a case where you really need, say, certain types of AD or the DiffEq + ML capabilities of the SciML ecosystem (the latter of which very much depends on the level of composability that follows from the dispatch-oriented programming paradigm).
In general, my two cents on what it takes to get "good enough" performance from Julia for my sort of HPC are that you (1) embrace the dispatch-oriented paradigm and take type-stability seriously, and (2) either disable the GC and manage memory manually or else (my usual approach) allocate everything you need heap-allocated up-front, and subsequently restrict yourself to in-place methods and the stack.
MPI.jl pretty much "just works" in my usage so far (just have to point it towards your cluster's OpenMPI/MPICH) and things like LoopVectorization.jl are great for properly filling up your vector registers with minimal programmer effort.
Earlier quoted context omitted.
It's hard enough to understand a codebase, but if a language was like Haskell for instance (you can enable certain extensions in Haskell with a flag at the top of a file), you could have a line at the top of a file defining that this file is 0 based, while maybe the default is 1 based for the language. It doesn't seem like that much more than you already have to consider in many languages.
Funny you put it like that, because the fragmentation regarding language extensions is frequently discussed as one of the biggest issues affecting real world Haskell.
Earlier quoted context omitted.
I __think__ Fortran just never gave you this particular footgun. No aliasing of pointers allowed from the getgo. It was never an issue. Somebody let me know if that is wrong. I read Complex numbers came in FORTRAN IV, so mid 60’s. I never used anything older than FORTRAN 77, and it certainly had complex numbers, and also ways for the “inventive” programmer to make use of pointer like functionality. You could e.g. pas…
"I read Complex numbers came in FORTRAN IV, so mid 60’s." FYI, this link [PDF] https://personalpages.manchester.ac.uk/staff/paul.johnson-2/... contains the peculiar statement "Over the next few years, FORTRAN II would also add support for the DOUBLE PRECISION and COMPLEX data types." At face value, that statement implies complex numbers came later but before FORTRAN III, which also implies a point release (FORTRAN II…
Earlier quoted context omitted.
I remember some version of BASIC from the early 80's. You could create real multi-denominational arrays including sparse ones with any starting index(s) you wanted. Matrix operations were first class.
I curious, can you remember which ones?
Earlier quoted context omitted.
I curious, can you remember which ones?
I think it was a SDS Basic or a variant. https://en.wikipedia.org/wiki/SDS_BASIC#MAT_commands
Earlier quoted context omitted.
"I read Complex numbers came in FORTRAN IV, so mid 60’s." FYI, this link [PDF] https://personalpages.manchester.ac.uk/staff/paul.johnson-2/... contains the peculiar statement "Over the next few years, FORTRAN II would also add support for the DOUBLE PRECISION and COMPLEX data types." At face value, that statement implies complex numbers came later but before FORTRAN III, which also implies a point release (FORTRAN II…
Pretty cool, thanks for the details! This is about what I’d expect from ancient FORTRAN. (I read fortran IV off Wikipedia, maybe there was fine print)
At the time it was anything but ancient. We students felt both cocky and privileged in that we knew that we were some of the very few people in the country who had access to a state-of-the-art IBM mainframe.
BTW, the mainframe, a System/360, had just 44kB memory and ran 7 concurrent operations at once. It was a red-letter day when the '360 got upgraded to 77kB memory. The university's rag had the fact as large headlines on its front page.