4 ms·
If you want the code to run slower, yes, you could do that. Because there are no pointers in Fortran, only arrays, and because arguments to functions aren't all
by not2b 3y ago
If you want the code to run slower, yes, you could do that. Because there are no pointers in Fortran, only arrays, and because arguments to functions aren't allowed to alias (let's ignore the horror of COMMON blocks for now), aggressive optimization and vectorization is easier.
The standard Fortran math libraries just work, and they are fast.
I should clarify that you can write C/C++ code that would have equivalent speed, especially with the C restrict keyword, but putting in an f2c step to translate the existing code will making things significantly worse in many cases.
- Sohcahtoa82 3y ago> Because there are no pointers in Fortran, only arrays, and because arguments to functions aren't allowed to alias [...], aggressive optimization and vectorization is easier. Can you explain this like I'm 12? What's an example of an aggressive optimization you can make based on arguments not being aliased and there being no pointers?
- Falell 3y agoNot a direct compiler optimization, but consider memcpy() vs memmove() as an example. If you know two regions of memory do not overlap you can call memcpy() for a direct optimized copy, but if they overlap you must call memmove() and introduce an intermediate copy.
- Sohcahtoa82 3y agoIt makes sense, but when would you ever memcpy with overlap? I would think any situation that lets that happen is from a bug, like you have an incorrect buffer length or an incorrect destination address.
- murderfs 3y agoInserting an element in an array is something along the lines of memmove(arr + idx + 1, arr + idx, (length - idx) * sizeof(*arr)); arr[idx] = foo;
- johncolanduoni 3y agomemmove does not (in any implementation I’ve ever heard of) introduce an intermediate copy, it just performs the copy loop in the reverse direction to handle the overlap (and can’t always vectorize in the same way memcpy can).
- superlopuh 3y agoHere's a relevant thread: https://users.rust-lang.org/t/possible-rust-specific-optimizations/79895/3 https://users.rust-lang.org/t/possible-rust-specific-optimiz...
- hurryer 3y agoint *x; int *y; // ... *x = 5; Because of aliasing, x and y might point to the same memory location, so the compiler must assume that when you modified x to 5, y also potentially got modifed, so at next access it will read y again from memory and discard any cached value in a register it might have. The compiler will try proving that no such aliasing is present, by tracking your pointer usage, but it's not always possible, in those cases it will assume the worse and re-read values from memory.
- Sohcahtoa82 3y agoAh that makes sense. Thank you!
- wycy 3y agoI finally understand—-thanks for this example.
- dwheeler 3y agoAlso, in Fortran arrays are normally stored in column-major order (sometimes called “Fortran order”). C uses row order. A simplistic translation would have terrible performance.
- pklausler 3y agoFortran has had pointers in the standard language since F'90 and as a ubiquitous vendor extension since ca. 15 years earlier.
- Affric 3y agoAre the often used in the big linear algebra libraries?