The only way I have to run this is on a Gadget Gangster SDRAM board. Any suggestions welcome.
Just now I slapped the I/O support from the Linux platform into the build. The console I/O is mostly commented out as it uses termios.h which we don't seem to have.
It's normal for us but some people would say that having a thing called an "integer" that silently overflows when you exceed it's bit representation is nuts. It would be better if it totally failed with an exception rather than producing incorrect results. Indeed the Ada language can do that and people who are fussy about writing correct systems will use Ada.
I think my point there really is: All these languages with types and type checking and such don't go far enough and they don't help you find bugs in your code. Might as well give that all up and use a dynamic language, like JS. Enjoy the superior features it offers and the ease of development. The bugs you will find by unit testing which is what you should be doing in any language anyway.
Re: The performance of JS.
There are a lot of dimensions to measuring JS performance, as there are any kind of bench marking. At the end of the day it's the performance of your app that counts not any benchmarks.
But here are few things that have struck me about JS in the browser and elsewhere:
1) In the past couple of years JS has has gotten a lot faster. The Google guys have been optimizing their V8 engine, as used in Chrome and node.js. The FireFox guys have been keeping up well with Seamonkey and so on. There has been something of a JS race going on. They have introduced just in time compilation (JIT) and all kinds of other optimization tricks.
2) In the browser a lot of the sluggishness you experience is due to load times and the browser rendering. Turns out that in many cases the JS execution time is small enough compared to everything else going on that if you made JS ten times faster you would hardly notice. You can see this for yourself if you open up the dev tools in Chrome or FireFox where you can see where all the time goes when you view a page.
3) On the server I have been replacing some C++ processes with JavaScript running
under node.js. That was an experiment and I was amazed to find that the JS versions were running at almost the same CPU load as the old C++. This works so well that all my new server code will be JavaScript. It's so much easier and quicker to develop than C++ or Java and performs about the same.
My guess is that actually I am dealing with a lot of streams of data, parsing XML, filtering it and passing it on to connected clients. A lot of the actual work there is being handled by C code. The operating system network stack, the XML parsing library and so on. JS is only orchestrating it all so even if it is a bit slow it does not have much impact.
4) In a similar vain, in the browser, if you are using webgl you can get some damn impressive results. The real work is done by the system and GPU, JS is only gluing it all together. Check out some demos: http://lib.ivank.net/?p=demos&d=bunnymark
5) There is now a thing called asm.js. You can now compile your C/C++ code to JavaScript (google emscripten) and have it run in your browser or under node,js. Blimey, turns out the the JS engines will run that stuff almost as fast as running native code. People have been benchmarking this a lot http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench[url]
Even my crude experiments with that could get within a factor 6 against native
code.
6) How about this crazyness: Write an emulation of an Intel processor in JavaScript. Have that emulated processor boot up Linux. In your browser! [/url]http://bellard.org/jslinux/ Seems to boot about as fast as my Raspi. When you get there there is a hello.c you can compile. Amazing.
Having said all that, no I don't expect TinyJS on a Prop to fly. There is not enough space to put in all those optimization tricks. But for the real-time work we have all those other COGS running PASM:)
None of the browsers that I have installed on Raspbian support WebGL, as such I was unable to see the effect of that example that you gave. And Iceweasel is at version 17.0.8 so it should and does not.
Comments
The only way I have to run this is on a Gadget Gangster SDRAM board. Any suggestions welcome.
Just now I slapped the I/O support from the Linux platform into the build. The console I/O is mostly commented out as it uses termios.h which we don't seem to have.
Probably. They are both in my office and I'm far away from there just now.
Just now it won't run anywhere as I haven't figured out how it's I/O hardware dependencies hang together.
I was just happy it compiles with propgcc. I think tomorrow I might start again from scratch.
Re: integer maths and programming languages.
It's normal for us but some people would say that having a thing called an "integer" that silently overflows when you exceed it's bit representation is nuts. It would be better if it totally failed with an exception rather than producing incorrect results. Indeed the Ada language can do that and people who are fussy about writing correct systems will use Ada.
I think my point there really is: All these languages with types and type checking and such don't go far enough and they don't help you find bugs in your code. Might as well give that all up and use a dynamic language, like JS. Enjoy the superior features it offers and the ease of development. The bugs you will find by unit testing which is what you should be doing in any language anyway.
Re: The performance of JS.
There are a lot of dimensions to measuring JS performance, as there are any kind of bench marking. At the end of the day it's the performance of your app that counts not any benchmarks.
But here are few things that have struck me about JS in the browser and elsewhere:
1) In the past couple of years JS has has gotten a lot faster. The Google guys have been optimizing their V8 engine, as used in Chrome and node.js. The FireFox guys have been keeping up well with Seamonkey and so on. There has been something of a JS race going on. They have introduced just in time compilation (JIT) and all kinds of other optimization tricks.
2) In the browser a lot of the sluggishness you experience is due to load times and the browser rendering. Turns out that in many cases the JS execution time is small enough compared to everything else going on that if you made JS ten times faster you would hardly notice. You can see this for yourself if you open up the dev tools in Chrome or FireFox where you can see where all the time goes when you view a page.
3) On the server I have been replacing some C++ processes with JavaScript running
under node.js. That was an experiment and I was amazed to find that the JS versions were running at almost the same CPU load as the old C++. This works so well that all my new server code will be JavaScript. It's so much easier and quicker to develop than C++ or Java and performs about the same.
My guess is that actually I am dealing with a lot of streams of data, parsing XML, filtering it and passing it on to connected clients. A lot of the actual work there is being handled by C code. The operating system network stack, the XML parsing library and so on. JS is only orchestrating it all so even if it is a bit slow it does not have much impact.
4) In a similar vain, in the browser, if you are using webgl you can get some damn impressive results. The real work is done by the system and GPU, JS is only gluing it all together. Check out some demos: http://lib.ivank.net/?p=demos&d=bunnymark
5) There is now a thing called asm.js. You can now compile your C/C++ code to JavaScript (google emscripten) and have it run in your browser or under node,js. Blimey, turns out the the JS engines will run that stuff almost as fast as running native code. People have been benchmarking this a lot http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench[url]
Even my crude experiments with that could get within a factor 6 against native
code.
6) How about this crazyness: Write an emulation of an Intel processor in JavaScript. Have that emulated processor boot up Linux. In your browser! [/url]http://bellard.org/jslinux/ Seems to boot about as fast as my Raspi. When you get there there is a hello.c you can compile. Amazing.
Having said all that, no I don't expect TinyJS on a Prop to fly. There is not enough space to put in all those optimization tricks. But for the real-time work we have all those other COGS running PASM:)
You make three good points.
Yes Java Script is getting faster. And JS JIT is nothing new (circa 1998 Netscape), it is just getting better.
Yes the problem with the implementation and integration in browsers is not the core engine. Still that is where most people most encounter JS.
Yes in most cases JS is a flow control, while other components written in verious compiled HLLs and or Assembly do most of the heavy lifting.
***************************************************************************************
None of the browsers that I have installed on Raspbian support WebGL, as such I was unable to see the effect of that example that you gave. And Iceweasel is at version 17.0.8 so it should and does not.