OpenEuphoria

1. Benchmarks revisited

• Posted by mattlewis (admin) May 21, 2009
• 1190 views

After fixing the memory leak, I've re-run the binary trees benchmark. I'm on the same machine, but different operating system. I ran with a parameter of 16, like before, though the official stuff has moved to 20 (they've got more powerful equipment than I do).

I reran the C/C and translated euphoria with 20:

The gcc estimate got closer to theirs, but it's interesting to see. The C code used boost::object_pool, which meant that they weren't going to the OS for memory all the time. exu 3.1.1 does something similar, which I suspect is the difference between 3.1.1 and the current 4.0 build.

Either way, this shows that in this test, at least, ruby is getting closer to euphoria, though perl is pretty far down.

Matt

PS: The last benchmarks, for reference:

3. Re: Benchmarks revisited

• Posted by mattlewis (admin) May 27, 2009
• 1187 views

I got the python code from the shootout. The euphoria code (as I said before) came from the Jason Gade's shootout submission.

Matt

5. Re: Benchmarks revisited

• Posted by jimcbrown (admin) May 27, 2009
• 1122 views

Well, if one picked numbers out of this benchmark very optimistically, euc's best number is 9.03 while Python's worst number is 69.

69/9.03 = 7.6

Even if we round up, Python is only slower than Eu by a factor of 8. (And this is comparing intepreted Python with translated Eu.)

7. Re: Benchmarks revisited

• Posted by jeremy (admin) May 27, 2009
• 1108 views

However, I don't think we should update the manual until we are ready to release 4.0, as right now very little regard has been given to optimization so things are not very well optimized right now. These numbers will probably be in quite a state of flux during the beta stages when we turn focus from new features to bug fixing, testing, optimization, etc...

Jeremy

9. Re: Benchmarks revisited

• Posted by mattlewis (admin) May 27, 2009
• 1180 views

I used python 2.6.2 (see the second column in the table) as it's what was on the system to begin with. I installed ruby, but didn't bother getting the latest python.

Actually, given the benchmarks I reported, python 3 was faster than python 2. I guess my table was somewhat incorrect, since I ran python 2.6.2, but marked it down as 3. Whatever.

This is largely a test of allocation and deallocation. As sequences were assigned as elements of other sequences, it also requires a fair amount of reference counts, which was more or less the point of doing this particular benchmark. So, in this, euphoria certainly wasn't 30 times faster than python, but a lot of time was presumably spent inside malloc() and free()--I didn't profile, but it's a pretty reasonable assumption.

I don't know enough about how python does garbage collection to make any comments about that.

What I thought was interesting was that the C code beat the C code by a lot. I ran on a dual core machine, and the C code used multiple threads. Using time to capture the running times, the user time for the C code was about twice the real time. The C code used a single thread, but because it cached the objects, it didn't have to spend so much time allocating and deallocating, which seems kinda like cheating:

Which is definitely what boost::object_pool looks like to me, though it's not listed at the bottom with the others.

Matt