Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Fortran now 20% faster than C, fastest language on Shootout

shootout.alioth.debian.org

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#31

Post by figglesonrails »

gcp wrote: post #19
wolf550e wrote: post #18

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…

void* p1; void* p2;

p2 = function(p1);

Do p1 and p2 alias? Note: function() is in a *.so file, no source available.

How many times do you have all of the source code available for analysis?

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#32

Post by igouy »

jbooth wrote: post #26
mrich wrote: post #15

Earlier quoted context omitted.

This. ICC is known to beat gcc usually.

Yeah, I'd suspect that better use of SSE instructions is the big win for number crunching.

https://alioth.debian.org/forum/forum.php?thread_id=14867&#3...

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#33

Post by gcp »

figglesonrails wrote: post #31
gcp wrote: post #19

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…

void* p1; void* p2; p2 = function(p1); Do p1 and p2 alias? Note: function() is in a *.so file, no source available. How many times do you have all of the source code available for analysis?

I pointed out specifically that all source code is available exactly for this reason. The original claim was that "for Fortran this is expected" which isn't true at all in this condition. So aliasing information can't explain the performance difference.

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#34

Post by igouy »

wheaties wrote: post #8
chj wrote: post #7

These reports are worse than useless. Any person with good understanding of computing knows that implementation plays a huge part in it. Why people wasting their time comparing speed of different programming languages while they should focus on different implementations. I guess the latter one is difficult so people all try to avoid it, and the first one is just so easy to do and everybody is doing it.

That fact stands out immensely. The Scala code and java code should be equal as the first can be written exactly like the second. Don't even see Clojure. Hate to see what times they get there.

What would be interesting about Scala programs written exactly like Java programs?

Hint: If you want to check for some text on a web page, use page search.

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#35

Post by igouy »

BindGuice wrote: post #13
wheaties wrote: post #8

Earlier quoted context omitted.

That fact stands out immensely. The Scala code and java code should be equal as the first can be written exactly like the second. Don't even see Clojure. Hate to see what times they get there.

Clojure is there but where is clang?

clang is waiting for someone like you, who wants to spend their time building language implementations on the LLVM toolchain and measuring program runtimes -

http://shootout.alioth.debian.org/demo2/which-programming-la...

http://shootout.alioth.debian.org/help.php#llvm

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#36

Post by chalst »

gcp wrote: post #30
stephencanon wrote: post #16

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 study says close to nothing about "Fortran" and "C", or about any of the other languages involved. 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 fa…

Median is a bad choice, because it completely ignores just how bad the worst performance holes are for a compiler. Discarding outliers is bad methodology in this case.

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#37

Post by stephencanon »

gcp wrote: post #30
stephencanon wrote: post #16

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 study says close to nothing about "Fortran" and "C", or about any of the other languages involved. 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 fa…

The median really is a spectacularly bad choice when there are so few data points, and especially when thinking about performance. If A and B get 3x faster, but C gets 3x slower, then your overall workload gets slower, even though the "median performance improvement" is 3x. Obviously the effect is magnified with only 3 data points, but the number of points used in the examples on that page is not so much greater as to eliminate this effect.

Adding to this is that significant slowdowns, the "outliers" that you're keen to disregard, tend to dwarf performance improvements that the median might show (because of the multiplicative nature of these values: if A/fortran is 10x faster than A/C, and B/fortran is 10x slower than B/C, then A+B/fortran is 5x slower than A+B/C).

What's really right is to show the complete distribution of speedups and slowdowns (as one of the detail pages on that site does). If you look at the actual distribution for the comparison of C and Fortran in question, C actually comes out looking much better than Fortran does (which shows precisely how misleading using the median can be).

If you must to boil it down to a single number, there are several choices better than the median. I would be happier with a mean, despite its imperfections.

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#38

Post by igouy »

stephencanon wrote: post #29
mrgoldenbrown wrote: post #28

Earlier quoted context omitted.

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.

They conducted a series of experiments, and reported their results. If that's not a "study", I don't know what is. The fact that the authors acknowledge that it's a "game" doesn't change that. What is misleading is the title on the link: "Intel Fortran now 20% faster than C".

What makes you think the title shown on Hacker News has anything to do with the linked website?

Can you find the statement "Intel Fortran now 20% faster than C" anywhere on the linked website?

> the authors acknowledge that it's a "game"

See http://shootout.alioth.debian.org/dont-jump-to-conclusions.p...

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#39

Post by jbooth »

igouy wrote: post #32
jbooth wrote: post #26

Earlier quoted context omitted.

Yeah, I'd suspect that better use of SSE instructions is the big win for number crunching.

https://alioth.debian.org/forum/forum.php?thread_id=14867&#3...

Cool. Yeah, seems like it's better inlining and use of XMM registers more than the SSE instructions themselves.

Re: Intel Fortran now 20% faster than C, fastest language on Shootout

#40

Post by igouy »

stephencanon wrote: post #37
gcp wrote: post #30

Earlier quoted context omitted.

This study says close to nothing about "Fortran" and "C", or about any of the other languages involved. 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 fa…

The median really is a spectacularly bad choice when there are so few data points, and especially when thinking about performance. If A and B get 3x faster, but C gets 3x slower, then your overall workload gets slower, even though the "median performance improvement" is 3x. Obviously the effect is magnified with only 3 data points, but the number of points used in the examples on that page is not so much greater as t…

> What's really right is to show the complete distribution of speedups and slowdowns

The page the OP linked DOES show all the distribution - that's the beauty of box plots.

Post reply on HN