The demo is of CPython, the original/standard Python implementation, compiled from C to JavaScript. What's cool about compiling CPython itself is that we get all the language features 'for free', both the common stuff you'd expect and think of first, and also things that if you were writing a new implementation, you might leave for last.
Known limitations:
- No import of modules - just the core language works. It should be possible to get imports working, of both C modules and Python ones, but it would require writing code for dynamic linking etc.
- I tested in Firefox 4 beta and Chrome 8, and for some reason the demo runs very slowly in Chrome 8 (perhaps related to V8 Issue 947?). Firefox 4 runs much faster but still obviously slower than native CPython. In any case that should improve once we get LLVM optimizations working.
Awesome work guys!
ReplyDeleteI'm getting "ReferenceError: _llvm_memmove_p0i8_p0i8_i32 is not defined." for the following:
print [dir(x) for x in dir()]
Thanks puffnfresh! It is fixed now.
ReplyDeleteI think the difference in v8 is in this:
ReplyDeletethe global array i in python.js has many elements 'undefined' in Chrome, but these are 0 in Firefox. Them being undefined makes slice a lot slower.
Seems like Firefox initalizes them and v8 not?
Int32Array doesn't initialize them, however, v8 should do that as is said here: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
ReplyDeletefiled a bug: http://code.google.com/p/v8/issues/detail?id=1001&q=array&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars
this makes it faster for now:
ReplyDeletefor(var a = 0; a < 1000000; a++) {if(i[a]==undefined) i[a]=0}
for(var a = 0; a < i.length; a++) {if(i[a]==undefined) i[a]=0} of course, but that took long and got an error while it was busy.
ReplyDeletehm
ReplyDeleteit isn't true. As i create an Int32Array it becomes an 0.
The problem lies in ka.
@Daniel:
ReplyDeleteChrome initializes typed array values to 0 (unless there is a serious bug there). However older Chrome versions don't have typed arrays enabled by default (needs --enable-typed-arrays), so they would have normal JS stuff, with lots of undefineds in HEAP as you mentioned.
However this is slow even with typed arrays, and the code in the bug I filed is slow with or without typed arrays (when comparing to SpiderMonkey).
So I don't really know why Chrome is slow on this code...
But I have undefineds in the heap (just type i[8] in the and I have Chrome version 10.0.615.0 (69640), so it must have typed arrays.
ReplyDeleteJust enter i[8] etc. and you see there are many undefined elements. Undefined makes the slice slow. And the mentioned code makes it fast again. So it must be an unitialized Array.
I found it: if(aaa=this.Int32Array&&this.Float64Array) {}
Chrome doesn't support Float64Array yet, so it becomes a normal array with lots of undefineds. Initializing them with 0 makes it fast again.
@Daniel: Good catch, thanks!
ReplyDelete