Live data from Hacker News

Make Lisp 15x faster than Python or 4x faster than Java

blog.postabon.com

61–70 of 100 posts

Re: Make Lisp 15x faster than Python or 4x faster than Java

#61

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

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

#62
A couple of notes:

1.) 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

#63
post #45

Earlier 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 :-)

Even though I do 90% of my dev work in *nix, I'd be very interested in the emacs version of this (if only to satiate my geek hunger).

Re: Make Lisp 15x faster than Python or 4x faster than Java

#64
post #48

Earlier 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…

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.

Re: Make Lisp 15x faster than Python or 4x faster than Java

#65
post #61

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

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 over 250 cycles.

Re: Make Lisp 15x faster than Python or 4x faster than Java

#66
post #64

Earlier 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.

> 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.

Re: Make Lisp 15x faster than Python or 4x faster than Java

#67
post #61

Earlier 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…

The speed difference is hardly negligible especially when talking about benchmarks. It's actually about 15% on my OS X laptop, less but still measurable on a Linux server. Your change actually has a greater impact on execution time than off-by-ones in the iteration counts which don't really take place.

Re: Make Lisp 15x faster than Python or 4x faster than Java

#68
post #2

The 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?

Even if you assume a local mercator projection (centered on your business or whatever) you still need to know that the earth is spherical. Otherwise, you're likely to assume that an 0.1 degree change in latitude is the same distance as an 0.1 degree change in longitude. To correct this erroneous assumption (for small distances) divide your longitude differences by the sine of your latitude.

Re: Make Lisp 15x faster than Python or 4x faster than Java

#70
post #48
post #42

Earlier 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…

... the only way to compare them is to write reasonably optimized programs in each of them and compare that.

That's one valid method. Another is to compare idiomatic programs from each language. Both are valid and both measure different things.

Post reply on HN