tag:blogger.com,1999:blog-3971202189709462152.post7003493323596806737..comments2024-03-11T12:50:02.036+01:00Comments on PyPy Status Blog: PyPy's JIT now supports floatsCarl Friedrich Bolz-Tereickhttp://www.blogger.com/profile/00518922641059511014noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-3971202189709462152.post-50578717302446452842009-11-02T19:08:13.892+01:002009-11-02T19:08:13.892+01:00Not to rain on the parade, but Java's trig fun...Not to rain on the parade, but Java's trig functions are very slow outside of -pi/2,pi/2 range to correct terrible fsin/fcos results on Intel x86.<br /><br />See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4857011<br /><br />Your benchmark should include something to measure the error, or not use trig functions as a benchmark when comparing to Java.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-53556457918581401872009-10-13T11:34:41.627+02:002009-10-13T11:34:41.627+02:00One would imagine having different interfaces for ...One would imagine having different interfaces for the same objects when accessed from 2.x and 3.x code. Would that be difficult?<br /><br />Of course, I understand mapping data structures between languages that have many more differences between them than py2 and py3 would definitely be more complex.dellahttps://www.blogger.com/profile/16873331731877660793noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-74396728166998128672009-10-12T17:33:44.163+02:002009-10-12T17:33:44.163+02:00@della.
In general, that would not be that simple...@della.<br /><br />In general, that would not be that simple. You need to somehow map data types between interpreters in an unclear manner. For example, what would happen if you call Python2.x function passing argument that is py3k dict (which has different interface)?<br /><br />Cheers,<br />fijalMaciej Fijalkowskihttps://www.blogger.com/profile/11410841070239382771noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-53497721378345379332009-10-12T10:48:00.317+02:002009-10-12T10:48:00.317+02:00Would a Pypy implementation of Perl/Ruby/PHP mean ...Would a Pypy implementation of Perl/Ruby/PHP mean that it would be possible to use libraries developed in one language for the other one? That would be very cool indeed.<br /><br />And, for that matter, would that mean interoperability between python2 and python3 modules when the py3 interpreter will be done? :)dellahttps://www.blogger.com/profile/16873331731877660793noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-33839496784188787062009-10-11T21:37:13.277+02:002009-10-11T21:37:13.277+02:00@hihu:
It would be a bit easier than writing the ...@hihu:<br /><br />It would be a bit easier than writing the interpreter in C, since RPython is much nicer. Also, you get JIT for almost free and decent GC for free. On the other hand, writing interpreters it's quite a bit of work on it's own.<br /><br />@Anonymous:<br /><br />Indeed, well, spotted, it would be more fair. However, there is no measurable difference (at least in pypy running time).<br /><br />PS. We have weekends, too.<br /><br />Cheers,<br />fijalMaciej Fijalkowskihttps://www.blogger.com/profile/11410841070239382771noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-85355509974493786262009-10-09T22:23:03.306+02:002009-10-09T22:23:03.306+02:00In the correct original version of the benchmark t...In the correct original version of the benchmark there are two calls to sin(). A good compiler optimizes one of them away. A worse compiler don't. So it's more fair to put back the second sin in the Python code too.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-17549501057855202842009-10-09T20:06:21.848+02:002009-10-09T20:06:21.848+02:00Great work!
How large an effort would it be to ha...Great work!<br /><br />How large an effort would it be to have eg. Perl or Ruby working with this? Just out of curiosity, I'm trying to understand this project better.hihhuhttps://www.blogger.com/profile/08879737817088655554noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-90783534855086191472009-10-09T13:39:11.359+02:002009-10-09T13:39:11.359+02:00Michael: because our goal is to have a general fra...Michael: because our goal is to have a general framework, not a Python-centered solution. For example, the JIT generator works mostly out of the box with any other language that we implemented in RPython (which includes Smalltalk).Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-24181235339901368932009-10-08T20:32:25.418+02:002009-10-08T20:32:25.418+02:00I seem to recall grumblings from C++ programmers a...I seem to recall grumblings from C++ programmers a few years ago when Java started supporting multi-core architecture, which made Java execution as fast or faster than C++ with much less development effort (for free with the Java interpreter vs hand-written C++ support).<br /><br />If your testing machine is a multi-core/processor machine, it might be appropriate to say that PyPy is now as fast as C++ (without explicit multi-core support). Wow!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-54414768861909855572009-10-08T20:26:05.990+02:002009-10-08T20:26:05.990+02:00How come the pypy JIT is compiled AOT to C? I tho...How come the pypy JIT is compiled AOT to C? I thought the idea of PyPy was to implement a python runtime in python? Why not run the JIT on a python runtime?<br /><br />Awesome work. I wish the Ruby folk were as motivated...<br /><br />Cheers.Michael Allmanhttps://www.blogger.com/profile/02974012909747662741noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-88708786755276783752009-10-08T18:06:39.920+02:002009-10-08T18:06:39.920+02:00how about including unladen swallow results?how about including unladen swallow results?Baczekhttps://www.blogger.com/profile/16082573980107250579noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-76393692744557584412009-10-07T22:37:18.885+02:002009-10-07T22:37:18.885+02:00@Luis:
Maybe I should... I really run this 10 tim...@Luis:<br /><br />Maybe I should... I really run this 10 times while assembler was generated only during the first time. But also dilluting assembler generation time over runs is kind of real-life effect...Maciej Fijalkowskihttps://www.blogger.com/profile/11410841070239382771noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-60200380055470148402009-10-07T21:28:49.074+02:002009-10-07T21:28:49.074+02:00Well, no matter how they measure it, this is defin...Well, no matter how they measure it, this is definitely within the "Holy Crap" range...Luishttps://www.blogger.com/profile/01147433030878927988noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-53072249606526405322009-10-07T20:31:39.893+02:002009-10-07T20:31:39.893+02:00@Luis: no, I think fijal started the pypy-c interp...@Luis: no, I think fijal started the pypy-c interpreter 10 times, and each time it generates assembly (it's not cached afaik).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-91521707006947324972009-10-07T16:34:24.797+02:002009-10-07T16:34:24.797+02:00I'm still confussed.. if you post the average ...I'm still confussed.. if you post the average of 10 runs, and assembler is generated only in the first run, then this time is diluted. Shouldn't you compute the average of 10 runs, but excluding the first one? (that means, runing it 11 times and ignoring the first one?).Luishttps://www.blogger.com/profile/01147433030878927988noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-58373940187026404072009-10-07T15:42:52.313+02:002009-10-07T15:42:52.313+02:00@illume
that's a bit unfair comparison, since...@illume<br /><br />that's a bit unfair comparison, since shedskin is not python. you can compare RPython and shedskin though. RPython is sometimes faster than C even...<br /><br />And also, yes, in PyPy or psyco time we include compilation time.<br /><br />Cheers,<br />fijalMaciej Fijalkowskihttps://www.blogger.com/profile/11410841070239382771noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-77221560466482644782009-10-07T13:35:45.963+02:002009-10-07T13:35:45.963+02:00awesome! things are really starting to move along...awesome! things are really starting to move along now :)<br /><br />I tried the same little benchmark with the shedskin python to C++ compiler for comparison:<br /><br />cpython2.5: 16.2770409584<br />cpython2.6: 12.2321541309<br />shedskin: 0.316256999969<br /><br />Shedskin is 38.6 times faster than cpython2.6, and 51.4 times faster than cpython2.5... and to extrapolate from your numbers 3.9 times faster than the jvm.<br /><br />Of course that doesn't include the time it takes to generate the C++ and then compile it with g++ (using the old 4.0.1 g++, not the latest 4.4). I also didn't include the python interpreter startup cost.<br /><br />btw, I found map, reduce and filter all to be faster with pure python versions when using psyco too.<br /><br />cu!René Dudfieldhttps://www.blogger.com/profile/17762358075557755436noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-26913908896717228222009-10-07T05:15:11.631+02:002009-10-07T05:15:11.631+02:00Very exciting. Thanks! These are nearing "h...Very exciting. Thanks! These are nearing "holy crap" numbers.<br /><br /><mindControl><i>siiiixty foooouuur biiiiit<mindControl</i>><br /><br />:-)Anonymoushttps://www.blogger.com/profile/16763371844879659730noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-73460259137487462582009-10-06T21:55:10.705+02:002009-10-06T21:55:10.705+02:00Wicked! Keep the sweetness coming :)Wicked! Keep the sweetness coming :)Panos Laganakoshttps://www.blogger.com/profile/01655446764737514715noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-2899744107210217222009-10-06T21:36:52.688+02:002009-10-06T21:36:52.688+02:00I'd be interested to see the results for a muc...I'd be interested to see the results for a much longer run (n = 10 000 000?).Williamhttps://www.blogger.com/profile/02052684196866992031noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-53322584791444391222009-10-06T19:47:38.133+02:002009-10-06T19:47:38.133+02:00Great job! I really appreciate your work.
@Luis: ...Great job! I really appreciate your work.<br /><br />@Luis: I think, it does include the assembler. I just compiled trunk and ran the modified benchmark on python 2.6 and pypy-c-jit. Best time of 10 runs:<br />Python 2.6.2: 0.911113977432<br />Pypy: 0.153664112091<br />So it's nearly 6x faster for me (including the time for generating the assembler, of course) - even much better than on the postet numbers...I don't know, if cpython was run with the unmodified version of the benchmark though.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-1555602505933483092009-10-06T19:37:02.676+02:002009-10-06T19:37:02.676+02:00Great, you guys are heroes!
Btw, what's the ...Great, you guys are heroes! <br /><br />Btw, what's the next big hurdle to run real-world programs? Memory use? Threads?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-19176919849224479862009-10-06T19:31:43.535+02:002009-10-06T19:31:43.535+02:00Very exciting!
By the way, this result doesn't...Very exciting!<br />By the way, this result doesn't include the time to generate assembler. Right?Luishttps://www.blogger.com/profile/01147433030878927988noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-15096223404846656372009-10-06T19:26:56.030+02:002009-10-06T19:26:56.030+02:00So it's much faster than Psyco and only about ...So it's much faster than Psyco and only about 2x slower than the JVM. That's impressive, as Python is much more dynamic!<br /><br />Congrats and thanks for the regular updates, it's much appreciated.Anonymousnoreply@blogger.com