41–50 of 100 posts
Any guesses as to why the Java implementation is relatively slow? JNI boundary crossings for floating point arithmetic, or lack of use of the math coprocessor?
Earlier quoted context omitted.
I'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.
It 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.
Earlier quoted context omitted.
There is no source data. I just iterate through each latitude from -90 to 90 and each longitude from -180 to 180 in increments of 2.5 (for both the start and end). Check out the source code for any of the 5 examples (included in the post). If you'd like, post the code up somewhere and I'll be happy to run it on the same machine and post the results along with the rest.
I also wonder why your java benchmark is slow. Java seems to be around 2-3x slower than C on average, this would make your optimized CL to be around 1.5x faster than C.
And of course, Haskell can be faster than all of these.
Earlier quoted context omitted.
I'm glad you asked ;-) http://blog.postabon.com/a-simple-lisp-webapp-for-beginners
Great stuff thanks! $Weekend--;
Let me know if you're on Win32 and I will package for you my setup, with a double-clickable installer, and your choice of Emacs or Win32 friendly IDE :-)
In all seriousness, how does one start with setting up and learning how to program a CL web app?
The result of the distance() function is unused and can be optimized away by the compiler. Runs in 0.04s with LuaJIT 2.0. No type declarations needed. :-) local radius = 6371 local function distance(latA, lngA, latB, lngB) local latAr = math.rad(latA) local lngAr = math.rad(lngA) local latBr = math.rad(latB) local lngBr = math.rad(lngB) local deltaLat = latBr - latAr local deltaLng = lngBr - lngAr return radius * 2 *…
Java does actually keep a table for trig functions on small values -- they just haven't widened the table definition, which is filed as a bug at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005861
"I just performed some simple benchmarks of my own, and noticed that summing e.g. sqrt, sin and tan for small values are just as fast as their C equivalents. This was a great relief to me.
However, when computing sin in the range of pi/2 ... pi and 10 ... 10+pi/6 Java became 3-5 times slower, while the C program was just as fast. This is explained above by lack of precision, but for example sin(10.0) yields bit-to-bit exactly the same result in Java and C! This comparison was performed on a rather old 1GHz Mobile Intel Pentium, so I would assume that the precision has been fixed in virtually all modern processors, and therefore these operations could be intrinsified for a much larger value range (possibly the entire double range)."
Earlier quoted context omitted.
It 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.
I don't count the startup time for any of the languages (Java included). And the runtime for Java was over 2 minutes.
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.
Python without Psyco : 522
Python with Psyco : 190
for latA, lngA, latB, lngB in itertools.product(*[xrange(-90,91), xrange(-180,181)]*2):
distance(latA, lngA, latB, lngB)
Also, the 2nd python example doesn't work; you need to drop all the 'math.' and use radians, sqrt, etc directly.