1. Looping with a floating point increment is silly here because you can't be sure how many iterations it takes. 2. C translation takes 11 seconds (compare to 25.6 for SBCL) http://gist.github.com/288936#file_silly distance loop
Make Lisp 15x faster than Python or 4x faster than Java
61–70 of 100 posts
Re: Make Lisp 15x faster than Python or 4x faster than Java
#621.) A simple square macro will be faster than the expt function, because expt does special calculations for dealing with decimal exponents. All you really need to do is multiply it by itself. I think something like this:
(defmacro square (expression) (let ((symb (gensym))) `(let ((,symb ,expression)) (* ,symb ,symb))))
would work fine.
2.) you can turn degree to radian into a macro like so:
(defmacro degree-to-radian (deg) `(the single-float (* ,deg ,(/ (coerce pi 'single-float) 180))))
And avoid a couple of function calls and some multiplication. This way you also don't need to duplicate 'the single-float'...
On my machine, running clozure cl, this made it about 1/8th faster than the original optimized version.
3.) I was kind of wondering, could you do this sort of computation ahead of time for varying longitudes and latitudes, then store them in a table and do a simple look up and interpolation, instead of doing a lot of trigonometry (is this technically trigonometry?) at run time?
I'm not clear on the math exactly (whether it would work in this situation), but that sort of thing is done using pre-computed tables with fairly complex polynomial equations all of the time. In the case of a web app, it might be better to do this sort of thing (ram is cheap anyway).
Re: Make Lisp 15x faster than Python or 4x faster than Java
#63Earlier quoted context omitted.
Great stuff thanks! $Weekend--;
What platform are you on? 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 :-)
Re: Make Lisp 15x faster than Python or 4x faster than Java
#64Earlier quoted context omitted.
Wow, 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 op…
1. 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 impr…
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.
Re: Make Lisp 15x faster than Python or 4x faster than Java
#651. Looping with a floating point increment is silly here because you can't be sure how many iterations it takes. 2. C translation takes 11 seconds (compare to 25.6 for SBCL) http://gist.github.com/288936#file_silly distance loop
Changing the loop indexes to integers is sillier because it makes the program not only different from the original one but also slower.
Re: Make Lisp 15x faster than Python or 4x faster than Java
#66Earlier quoted context omitted.
1. 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 impr…
1. 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.
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.
Re: Make Lisp 15x faster than Python or 4x faster than Java
#67Earlier quoted context omitted.
Changing the loop indexes to integers is sillier because it makes the program not only different from the original one but also slower.
Incorrect code is silly. It is not unlikely that the different languages are performing a different number of iterations in these tests, correcting that by being precise about the range to be iterated over is not silly. The integer indices here produce the behavior that seems to be intended by the ` The speed difference is negligible since all but the inner multiplication is hoisted out, and each inner loop takes ove…
Re: Make Lisp 15x faster than Python or 4x faster than Java
#68The most common way to compute your distance from a deal is to assume the earth is a perfect sphere I thought you would only really be finding deals at distances small enough to just assume the earth is flat. Or at least, aren't those the only ones people would actually be interested in? If it's beyond my physical reach, I don't care how far it is. I'll get it shipped. Or am I missing something?
Re: Make Lisp 15x faster than Python or 4x faster than Java
#69Re: Make Lisp 15x faster than Python or 4x faster than Java
#70Earlier quoted context omitted.
I don't count the startup time for any of the languages (Java included). And the runtime for Java was over 2 minutes.
Wow, 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 op…
That's one valid method. Another is to compare idiomatic programs from each language. Both are valid and both measure different things.