21–30 of 53 posts
Most of Fortran's gain is on mandelbrot, but it sucks on binary-trees (10x slower than C). It also tends to use 2x more memory (with a 23x outlier on fannkuch): http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Earlier quoted context omitted.
AFAIK GCC doesn't add "restrict" to pointers by itself. Fortran semantics mean that pointers are "restrict" by default.
How does this matter when the compiler can see all the source code? It can see what the pointers are pointing to and determine if there is aliasing. Feel free to point out the source code in the shootout where this would somehow not be the case. Shouldn't be hard to find if you focus on the benchmarks where Fortran beats C heavily. Additionally, the argument about restrict is flawed because it can be added to the C c…
Most of Fortran's gain is on mandelbrot, but it sucks on binary-trees (10x slower than C). It also tends to use 2x more memory (with a 23x outlier on fannkuch): http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
I've been doing some tuning work on our parallel dialect of ML, and many of the C programs are fairly well-optimized, though mandelbrot still has some room for improvement.
Earlier quoted context omitted.
How does this matter when the compiler can see all the source code? It can see what the pointers are pointing to and determine if there is aliasing. Feel free to point out the source code in the shootout where this would somehow not be the case. Shouldn't be hard to find if you focus on the benchmarks where Fortran beats C heavily. Additionally, the argument about restrict is flawed because it can be added to the C c…
It is impossible write a compiler that reads a C source code and for every point in program decides if two names visible from that point cannot alias each other. You cannot do that even under assumption that every code path may be visited.
The impossibility of solving aliasing in the general case doesn't stop C compiler writers from implementing alias analysis.
Earlier quoted context omitted.
It is impossible write a compiler that reads a C source code and for every point in program decides if two names visible from that point cannot alias each other. You cannot do that even under assumption that every code path may be visited.
I agree it is impossible in the general case (it's obviously impossible when input data controls program flow, for example). But I don't think that has much meaning for the benchmarks under consideration, which, by the way, one would expect to sidestep the obvious pitfalls here. The impossibility of solving aliasing in the general case doesn't stop C compiler writers from implementing alias analysis.
Intel Fortran vs gcc ??? How about Intel Fortran vs. Intel C ? How about gcc C vs. gcc Fortran ? Hyper-optimized compiler for Intel architecture beats compiler designed to be portable to many, many target architectures? Not very shocking.
This. ICC is known to beat gcc usually.
With Fortran this is expected, since for language semantics the compiler can perform more assumptions compared to C, resulting into more optimizations.
This is a really terribly done study, with a misleading title to boot. First, even if we take the conclusion as given, "Fortran" isn't faster than "C". The median of one set of programs, compiled with one Fortran compiler with one set of options and run on one processor, is faster than the median of another set of programs compiled with one C compiler with one set of one and run on that processor. This tells us appro…
This is a really terribly done study, with a misleading title to boot. First, even if we take the conclusion as given, "Fortran" isn't faster than "C". The median of one set of programs, compiled with one Fortran compiler with one set of options and run on one processor, is faster than the median of another set of programs compiled with one C compiler with one set of one and run on that processor. This tells us appro…
This is a really terrible criticism of the linked page, with a misleading first statement to boot. Where do you see the word study? The title at the top of the page says "Computer Language Benchmarks Game". How is calling it a benchmark game misleading? That's what it is, and it doesn't pretend to be anything else - it is a sorted list of benchmarks run on one particular configuration.
This is a really terribly done study, with a misleading title to boot. First, even if we take the conclusion as given, "Fortran" isn't faster than "C". The median of one set of programs, compiled with one Fortran compiler with one set of options and run on one processor, is faster than the median of another set of programs compiled with one C compiler with one set of one and run on that processor. This tells us appro…
Sorry, but I disagree here. It's one of the best resources out there for getting numbers on the relative performance of languages, despite the pitfalls. The implementations of popular languages are well tuned (sometimes extremely so), the used compilers and settings are quite sane, and the benchmark programs are fairly well distributed in functionality.
The median is a reasonable choice because it's less sensitive to outliers and was probably chosen for that reason. "Spectacularly poor metric" seems to be an opinion, not a fact.
I admit it would have been better to compare Intel C with Intel Fortran. Why wasn't this done? Perhaps some of the submitted programs don't compile correctly with Intel C, or perhaps Intel C doesn't actually perform well on them. Who knows.
But to say that this is a "terribly done study" because of that is doing it injustice.