asm.js or WebAssembly

[Damien Polizzi]

Hello
At first I apologize because I'm french and not very good in english writing and speeking. If I make some mistakes, ... sorry !

I'm searching a way to put python in my web browser. Why ? Because I think that javascript is a poor language in comparaison of python. For example it is difficuld to deal with objects or tuples correctly ...
A thing where python is realy good and i like very much how the python language is done.

I've found a few monts ago Brython and tryed it. I've done one or two think for seeing how it worked. And I' was happy to see that is looked good.

Then I tryed to play with a game writtent in Brython, but I was sad because it was slow, then I've search other technologies for my purpose but it was difficult to compile ...

And then I asks myself why the developpers in of Brython didn't try to make a asm.js compiler instead of classic javascript, and that the code build whith brython could be in asm.js too.
I know that it could be very hard and long to handle it, but it could be a very useful challenge, since Brython is the unique technology simple to use and capable of embedding directly some python 3 code in the html page and testing it without compiling it.

Ok I understand that asm.js is not the definitive goal, since WebAssembly will be ready this year, but I think that when the source of Brython will be compiled to asm.js it will be easy to transform it into wasm.

I've tryed to compiled a bonifaci algorith whitten in Python to C whith Cython, and then to LLVM. The time was /2
And then I wrote a pyx file I did the same whith it. The result were very impressive (tryed with an bonifaci algorithm) and the time was /100.

I didn't manage to compiled into asm.js because I'm not very good in compiling and command line using...

I hope that my little experience will be interesting for you.
What do you think about that ?

[Joao S. O. Bueno]

Brython is a "transpiler" to Javascript that happens on the client side-  and that is its intent. 

It is not that slow, and if you make games that delegate animation and position of raster elements

to the proper Browser engines using the same calls javascript does, they should be quite playable.

If you want raw numeric work done (like fibonacci algorithms) - maybe it is just not the right technoogy for you

(just as cPython can fall orders of magnitude short on this kind of performance when compared to native languages).

Anyway, brython itself should not be subject to such a great change - if you want a Python

interpeter that would run on NaCL or other "fastr-than-javascript"  technology, you need a different project,

even if one that forks from brython and evolve to something else.

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brython/9d9db936-d1f9-41c1-9fee-1ec31a1f28d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Olemis Lang]

On 5/2/16, Damien Polizzi <damien....@gmail.com> wrote:
> Hello
>

[...]

>
> And then I asks myself why the developpers in of Brython didn't try to make
> a asm.js compiler instead of classic javascript, and that the code build
> whith brython could be in asm.js too.
> I know that it could be very hard and long to handle it, but it could be a
> very useful challenge, since Brython is the unique technology simple to use
> and capable of embedding directly some python 3 code in the html page and
> testing it without compiling it.
>

Compiling to asm.js would limit scope to Mozilla's browsers . cmiiw

> Ok I understand that asm.js is not the definitive goal, since WebAssembly
> will be ready this year, but I think that when the source of Brython will
> be compiled to asm.js it will be easy to transform it into wasm.
>

[...]

In a few words , I plan to work towards this target soon after more
progress is made on running the CPython test suite to track regresions
and compatibility issues.

--
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Brython committer
http://brython.info
http://github.com/brython-dev/brython

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Olemis Lang]

On 5/2/16, Joao S. O. Bueno <gwi...@gmail.com> wrote:
>
[...]

>
> Anyway, brython itself should not be subject to such a great change - if
> you want a Python
> interpeter that would run on NaCL or other "fastr-than-javascript"
> technology,

Indeed since asm.js and NaCL look like candidates for implementing
WebAssembly , the later seems to be aimed at providing an intermediate
(standard) layer between low-level browser components (faster) and
code executed by scripting engines (slower) .

[...]

[Damien Polizzi]

Le lundi 2 mai 2016 20:03:01 UTC+2, Olemis Lang a écrit :

Compiling to asm.js would limit scope to Mozilla's browsers . cmiiw

I don't think so, asm.js works on chrome (I don't know for IE...)

Indeed since asm.js and NaCL look like candidates for implementing

WebAssembly , the later seems to be aimed at providing an intermediate
(standard) layer between low-level browser components (faster) and
code executed by scripting engines (slower)

Sorry I thought the project were based on asm.js

 

In a few words , I plan to work towards this target soon after more
progress is made on running the CPython test suite to track regresions
and compatibility issues.

It's a very good new ! For me and Python

Since I haven't the skills to work on such a project, I'm happy to see that there is people like you !
Thanks for your work
 

[Carl Smith]

ASM code will work in any browser. It's just a subset of JavaScript (that modern browsers can execute very efficiently). Firefox added an explicit "use asm" directive that tells the browser it's safe to make a bunch of assumptions. Chrome Team decided to aim for comparable speeds without the need for the directive (aiming to keep the Web spec less complicated). Older browsers will not optimise the execution of ASM code very well, but every browser will run it. It's just JS.

Web Assembly is basically the byte code that ASM is compiled to internally by browsers. ASM source is pretty verbose, so it's bulky and takes a while to parse. WASM basically does the same job as Python's pyc files. Precompiling ASM source doesn't solve some of the core issues with JS though. For example, everything is still going to be single-threaded. People are discussing ways to provide new features like threads through WASM, but it's all open still. If it was just a matter of accepting precompiled binaries, it'd be pretty easy to implement WASM support, but people want to explore exposing new, lower-level features, so it's going to take longer.

Web Assembly in its current form doesn't offer much help for implementing Python in the browser. You still have all the same issues; you can just speed some things up. You still have to implement a Python interpreter in a subset of JavaScript, and interop with JS will be very difficult/impossible to provide if you compile C code to ASM or WASM - at least currently.