fannkuch old version vs fast setslice
- __jsdict_pop replaced by direct call to __array_insert
- __array_getslice replaced by __array_getslice_lowerstep: 200ms faster
- __array_setslice 90ms faster
Brython, on the other hand, has attempted to fully support all of the dynamic features of Python, including operator overloading. As you will see in this benchmark, the price is very fucking high, Brython is 50 times slower than regular CPython3, and 295 times slower than Rusthon.
The Brython FAQ states that Brython is "somewhere between 3 to 5 times slower", nice try guys, that should be updated to say something like: "Brython is a toy, and can not actually be used for anything".
def benchmark(n): a = [ Vector(i*0.09,i*0.05, i*0.01) for i in range(n)] b = [ Vector(i*0.08,i*0.04, i*0.02) for i in range(n)] c =  d =  for j in range(n): with oo: u = a[j] v = b[j] c.append( u+v ) d.append( u*v ) return [c,d]
Above is a snippet of code from the benchmark, the special syntax with oo: enables operator overloading for just those statements under it in Rusthon. If you hate this syntax, you can also use with operator_overloading:, or fore go operator overloading and directly use the method names like this:
def benchmark(n): a = [ Vector(i*0.09,i*0.05, i*0.01) for i in range(n)] b = [ Vector(i*0.08,i*0.04, i*0.02) for i in range(n)] c =  d =  for j in range(n): u = a[j] v = b[j] c.append( u.__add__(v) ) d.append( u.__mul__(v) ) return [c,d]
Above is the result of my second implementation. The difference is huge, what did i change? Instead of running this.__init__(args) in the constructor, the __init__ method (and all other methods) gets attached to the nested function __call__ and not rebound, then when calling __call__.__init__(args) the calling context of this is already __call__, and so we can skip coping values from this. This allows the V8 JIT to know that __call__ is not so dynamic, and to optimize it however it can. The only performance question now is, what is the overhead of returning a function object, rather than a normal object from the class constructor? Lets compare to another version of the benchmark where __call__ gets replaced by a normal method named call
Above is the result of the same benchmark but without using the special method __call__, here it is replaced by a normal method call. The class constructor returns a regular object, not a function-object like above. This is less dynamic, and the V8 JIT is able to optimize it even more. In conclusion, there is indeed a price to pay for having callable objects, the cost being about six times slower.
Above are the absolutely terrible results of Brython running the same benchmark. In this test, Brython is 80 times slower than CPython, and 88 times slower than Rusthon.
What is killing RapydScript in the Fannkuch benchmark? I am not sure, looking over the output from RapydScript, it looks almost the same as Rusthon, except for the way it performs array slicing, could that be the cause of the slow down? See the transpiled code here: RapydScript output and Rusthon output
update: I ran the Fannkuch benchmark again in Brython, this time unchecking the "debug" box, but the results were not much better, Brython still takes 150seconds. That makes it 500 times slower than CPython3.
After almost two years of development, Rusthon is nearing the stable 1.0 release. The project originally began with my fork of PythonScript by Amirouche, who had written a two-pass transpiler that was easy to understand and modify. PythonScript was then renamed to PythonJS, and optimized for speed. Early benchmarks tests showed that many dynamic pythonic features would have to be thrown away, because of the high performance overhead. The minimal python syntax that evolved over several months, ended up having many of the same behavior and rules that Alexander Tsepkov's RapydScript also had.
There was alot of hype on Dart not long ago, but already it has faded away into the trash bin of so many other failed languages, with over 33,000 commits and less than 400 github stars, nobody gives a fuck, nice try Google+.
There are several full-stack frameworks for python like: Django, Web2Py, and CherryPy. This PDF from the Web2Py docs has a pretty good overview of these frameworks, see web2py_vs_others.pdf. What you will notice with these frameworks is they each have their own fucked up way of embedding code and logic into HTML templates. These huge frameworks try to hide the details of the object relational mapping and database, but in doing so force you to use their HTML template language. Andy Shora has some interesting insights on full-stack dev, check out http://andyshora.com/full-stack-developers.html
Writing a full-stack system in Rusthon is pretty simple, this demo is just 300 lines and includes: backend, database, and frontend. See source code here. The HTML is raw and can be easily integrated with modern solutions like Angular.js. By not having some huge framework in your way, you can directly code the server to send data in the way you want, with whatever ad-hoc protocol you choose. In this demo all data is moved around over a websocket, and both clients are kept in sync with the server and database in realtime.
The Python library Dataset is used to hide all the SQL, and provides a NoSQL like solution in combination with property getter/setters on the client side, you never have to worry about directly writing SQL code.