Multi-threading? #3801
Replies: 1 comment
-
Posted at 2014-02-05 by @gfwilliams The issue really is stack space. As the parse tree is effectively on the stack, having two things running concurrently is likely to fill it up pretty quick. You could just rewrite the quicksort to jump out early. Can you post your quicksort? I'd like to add it as a benchmark. The best solution here would be to implement the quicksort natively though. It should be quite easy (and fast) with iterators and I imagine it would be used a lot. Posted at 2014-02-06 by TiCPU I forgot that you would need to instantiate a second parsing tree. I attached the tests I made with sorts. Here is the output:
Posted at 2014-02-06 by TiCPU Attaching did not work, I'll just paste it inline:
Posted at 2014-02-06 by TiCPU I tried optimizing the function, removing functions call seem to help quite a bit, and prevent stack overflows just a bit since it is easy to get one.
swap and qsort_partition not needed anymore:
Posted at 2014-02-06 by TiCPU And here is my final code for my needs, this won't stack overflow:
References: http://alienryderflex.com/quicksort/ Posted at 2014-02-06 by @gfwilliams This is great - thanks! I'll stick these in the benchmark suite - they should be really useful to help work on function call/array access overhead. By the way, if you want a little more speed, you can minify the function:
Posted at 2014-05-17 by user7029 Minifying is nice, bumped on github a javascript string compressor http://pieroxy.net/blog/pages/lz-string/demo.html which compress the minified (on a PC the 830 bytes becomes 322 bytes net). Posted at 2014-05-19 by @gfwilliams Looks handy - it would be good to have as an Espruino module... To be honest the USB link is more than fast enough for sending code, and unless I can make Espruino execute direct from the compressed strings I wonder how much memory this would save on Espruino itself. However being able to compress data could be very handy - especially when doing things like sending it over the internet or storing it on EEPROMs. Posted at 2014-05-19 by user7029 That's right. Actually, when I looked at Tessel's add-on board animation which gets inserted on the MCU board, it reminded me of the impractical USB custom devices: when plugged in the first time: It's plug and pray because compiled drivers need to be found (on top of being admin)... for the host (win, iOS, Android, Linux...) Would developers' life be easier if each "shield" comes with an EEPROM which contains the javascript drivers and web pointers (where to get spec, upgrades etc...), so the platform (whatever the MCU) can use it right away, like dynamic added resource? This would justify interpreted language implementation for portability. By the way, surveying around, got some questions:
Posted at 2014-05-20 by DrAzzy
How about inline assembler? http://www.espruino.com/Assembler Posted at 2014-05-20 by user7029 Assembly is not portable across cores (not future proof): C helps to be core agnostic. Few years back we learnt to optimize the way we code in C so the compiler is generating efficient machine code. I try to use only the NOP instruction for basic S/W delays. Javascript evolves and adopt what is popularly implemented new features in browsers. How about Embedded JavaScript? (no V8 engine to compete with eLua's performance) Posted at 2014-05-20 by @gfwilliams
It's a language that people actually know, there's lots of code available on the net, and you don't need a toolchain on the host. It's almost certainly not as fast, but if you were after raw speed and didn't mind pre-compiling then you'd probably be using C.
Without a JIT compiler I don't think that will help a great deal - if you want a fast pre-compiled language that looks a lot like C, I'd suggest that you use C.
This is true, however I think it's safe to assume that every Espruino device for the next few years at least will run ARM Thumb, so you're pretty safe. There are instructions on the link @drazzy posted that show you how to use C code in Espruino. Ideally the Web IDE would directly support 'inline C' - but I'm yet to find a compiler that can be compiled to JavaScript that targets thumb. If someone wants to port TCC (which can be compiled with emscripten) from ARM to ARM Thumb then I'd be only too happy to directly include inline C :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-02-05 by TiCPU
Would it be possible for a function to have a point where it could "yield" the CPU for other functions to execute? I added a quick sort function to Uint16Array which takes about 15 seconds to execute which breaks some timings when setInterval() are too short.
I take the "yield" expression from Lua which implements multi-threading as coroutines, see: http://lua-users.org/wiki/CoroutinesTutorial
Beta Was this translation helpful? Give feedback.
All reactions