Quote:Original post by dbzprogrammer
C/C++ is the best tool for intense calculations.
D is not, along with C#.
Errr... right. And I haven't shown that D gets as fast as C++ when using the GCC-based compiler...
Quote:Original post by dbzprogrammer
C/C++ is the best tool for intense calculations.
D is not, along with C#.
Quote:Original post by StachelQuote:Original post by MaulingMonkeyI read about the profile guided assumptions, and the theory that JITs can therefore produce faster code. But the results always seem to be missing in action.
For all you know, this is significantly faster than the equivilant C/C++ due to optimizaitons based on input data which absolutely could not be made in the equivilant staticly compiled program (because, as that first article mentions, Java is able to make profile guided assumptions, even when those assumptions may later prove invalid for the general case!). For all you know, it's been running faster than the static equivilant for all those hours!
Here's one set of benchmarks comparing Java with C++: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=java&lang2=gpp
Score 1 out of 17 for Java.
Quote:Original post by dbzprogrammer
C/C++ is the best tool for intense calculations.
D is not, along with C#.
Quote:Original post by StachelIt's not about writing a benchmark that favors the way Java works. It's about writing a benchmark that functionally resembles a real application.
Quote:Original post by AldacronThink of it like a test in school. There's teaching the test so the students can pass it, then there's teaching knowledge so passing the test falls out naturally.Quote:Original post by StachelIt's not about writing a benchmark that favors the way Java works. It's about writing a benchmark that functionally resembles a real application.I'm not sure what your point is. For a real-world application, a Java programmer would code in a manner that favors the way Java works. If a benchmark doesn't reflect that, then it isn't accurate.
Quote:Original post by StachelActually that particular optimization was not an optimization any compiler could do. It could be said being a (minor) algorithmic change because it changes the input/output mapping of the div and mul functions. It just "happens" to work in this application because it's not so important how the numbers are distributed in the array that represents large numbers, only that the array's "real" value is correct. (e.g. 4*10^2+1*10 is same as 3*10^2+11*10)
For the Java benchmark, it's been tweaked to replace (x / 10) with (x * .1f). That's faster on some CPUs, but slower on others. Doesn't that mean the Java JIT should do this transformation on its own because after all, isn't the great strength of the JIT being able to adapt to the particular CPU?
Quote:Original post by Stachel
For a benchmark, consider that D supports inline assembler. That means one could write the Pi benchmark entirely in hand-optimized assembler, and that would technically be writing it in D. Nothing could beat that for speed. But is that a reasonable benchmark for D? I'd sure cry foul. I didn't see any special tweaking in the D or C versions of Pi.
Quote:
For the Java benchmark, it's been tweaked to replace (x / 10) with (x * .1f).
...
I'm not interested in benchmarks custom carefully designed to avoid weaknesses in an implementation, and only show its strength.
...
Write benchmarks in a manner that's straightforward to the language being used.
Quote:Original post by Stachel
For a benchmark, consider that D supports inline assembler. That means one could write the Pi benchmark entirely in hand-optimized assembler, and that would technically be writing it in D. Nothing could beat that for speed. But is that a reasonable benchmark for D? I'd sure cry foul. I didn't see any special tweaking in the D or C versions of Pi.
Quote:For the Java benchmark, it's been tweaked to replace (x / 10) with (x * .1f). That's faster on some CPUs, but slower on others. Doesn't that mean the Java JIT should do this transformation on its own because after all, isn't the great strength of the JIT being able to adapt to the particular CPU?
Quote:Original post by RagharYes. The 386/387 CPU combination and the 486 have integer division faster than float multiply according to clock cycle counts. Not to mention any processor that doesn't have hardware floating point (seen in embedded processors). It isn't just the multiply, there's the conversion to and from float to add in, plus resetting the rounding mode.
Are you saing that there are CPUs where division isn't 80 cycles monstrosity, and multiplication 1 - 1.5 cycle sweety operation?
Quote:Original post by Kevlar-XQuote:Original post by deathkrush
The fastest way to calculate PI in C is of course:
*** Source Snippet Removed ***
Hey, I loved the snippet!
Though, it wouldnt compile as given (F_00() is used before defined) so I rearranged the code blocks.
Then it crunches out the number '0.250'.
So I might add: it may be a great way to calculate pi, compact and cool looking, but it lacks one extra nicety we would like in a program to calculate pi. Determining the correct result.
On all other accounts its cool though! :)
- Jacob