4 ms·
> All the benchmarks were run 5x each on the same Debian machine I refer the honourable gentlman to Zed Shaw's "Programmers Need To Learn Statistics Or I Will
by wendroid 17y ago
> All the benchmarks were run 5x each on the same Debian machine
I refer the honourable gentlman to Zed Shaw's "Programmers Need To Learn Statistics Or I Will Kill Them All"
http://www.zedshaw.com/essays/programmer_stats.html http://www.zedshaw.com/essays/programmer_stats.html
- smanek 17y agoI'm actually a mathematician by training ;-) I ran all tests 5 times each, and averaged the results. Each of the results for each of the tests were within 2% of each other, and the machine wasn't used for anything else while the tests were running. I know it's not perfect, but I don't see any obvious sources of error ... I did provide all the source, so you're welcome to verify my results.
- wendroid 17y agoI refer the honourable gentleman to the answer I gave a few moments ago :)
- Retric 17y agoIt shows, you are comparing optomized LISP with unoptomized Java and C. Java has a long startup process so it is relativly faster on 20 second benchmarks than sub second ones. As to C, it does what you tell it do do, so the compiler needs a little more handholding. I suspect LISP's compiler is not acctually doing the computations because they are never used, granted I have not really looked into it.
- smanek 17y agoI don't count the startup time for any of the languages (Java included). And the runtime for Java was over 2 minutes.
- Retric 17y agoWow, that is slow. Well java's pow function uses floats on the exponent so it would be a lot faster if you used a temporary variable, and then multiplied it by its self. Other than that I don't know, most of these math functions should translate to a single ASM function so I don't know why it's that slow. PS: I would probably inline the C function, but that's not a huge deal. My point was each language has its own optimizations; the only way to compare them is to write reasonably optimized programs in each of them and compare that. Edit: I think Java's sin functions are slower than the HW implementation but more accurate, which is irrelevant because you don't care but it's something to look into. I dislike Java for other reasons, but it's easy to make code slow which code that looks very similar runs a lot faster.
- jedbrown 17y ago1. There is no C function. 2. Inlining in an actual C implementation doesn't matter because there is no register pressure and each trig function generates a real function call. Function calls to known addresses are really fast (~2 cycles), even indirect calls are fast compared to transcendental functions (~ 6 cycles). For comparison, the C implementation takes ~260 cycles each distance computation. This can't be improved much without vectorizing the trig functions.
- Retric 17y ago1. There is no C function. What do you call public static float distance(float latA, float lngA, float latB, float lngB) { As I said but that's not a huge deal. Yes it's not a major slowdown, but a tight inner loop with a function call is begging for an inline.
- jedbrown 17y ago> import java.util.Calendar; might be your first clue... > but a tight inner loop with a function call is begging for an inline. The loop body makes several other function calls, you would be very hard pressed to measure the difference. And if it was a C function in a larger project, you probably wouldn't want to inline it because that would slow your compile times and cause you to lose modularity (i.e. you'd have to rebuild all client code rather than just update the DSO when you optimize the distance function). This function does enough work that it doesn't deserve to be inlined.