Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
7 years, 7 months ago.
What is the javascript performance
If we look at a comparable option, Espruino, the performance is best summarized as 'questionable'. They can toggle a pin at max 4kHz, if you don't put comments in your code. That MCU (I assume the F103), should easily do that at 4MHz. That is at least a factor 1000!!! overhead.
So how is the overhead with your implementation?
On a related note, your comparison in code is not exactly fair. If we do it like that I get the C++ code on 4 lines:
DigitalOut led(LED1);
InterruptIn button(SW2);
void toggle_led() {led = !led;}
int main() {button.fall(&toggle_led);}
Since that third line of the javascript code is also just adding 4-5 lines into one.
And your second example is a reason to stick to mbed instead of mbed-os ;). Since with just mbed lib that is also acceptable in many programs. (Or doing the same in mbed-os with RawSerial).
Another question: Will you support this in the online compiler?
Question relating to:
1 Answer
7 years, 7 months ago.
Hi Erik,
On your first question, we'll do some performance tests this week, and report back on the numbers.
On the second question, regarding syntax, yes, syntactically they're very close, but in JS it's a lot more acceptable to inline callbacks than in C/C++. Might change with C++11 Lambdas (if they ever reach embedded), but we put a disclaimer:
"The above example may not exactly inspire you to want to run out and embrace JavaScript just yet" :-)
And your second example is a reason to stick to mbed instead of mbed-os ;). Since with just mbed lib that is also acceptable in many programs. (Or doing the same in mbed-os with RawSerial).
On the ISR's. Serial is one thing, but we see people do all kinds of crazy stuff in ISRs. Network operations for example, or writing to BLE characteristics (safe on Nordic, not safe on ST). Presenting (especially novice) users with a 'safe-by-default' programming style where you don't care whether your code run because it was triggered by an interrupt, or was 'just' scheduled is very important to provide people with a friendly environment when they're new to embedded development. Advanced users *know* when to delegate from an ISR to main thread, and they know when they want to run in an interrupt context and when not. If it was up to me (and maybe it's good that it isn't) we'd make InterruptIn actually not run in an interrupt context, but automatically dispatch the callback on main thread: safe by default. Then put a new RawInterruptIn class in for people who have a clue what they're doing.
Another question: Will you support this in the online compiler?
Not in the online compiler at developer.mbed.org, will remain as-is. JavaScript is still very experimental and not officially supported. If any third-party mbed Enabled IDEs will launch anytime soon they might have support.
Hi Erik,
I've just done some basic speed tests with JerryScript running on the ST F401RE and the K64F, and here are the results I got:
ST F401RE: JerryScript: 7 kHz C++: 1.33 MHz
factor of 190
K64F: JerryScript: 7.14 kHz C++: 800 kHz
factor of 112
To be clear, the testing methodology isn't quite a level playing field (JerryScript was compile with -O3 in both cases, the C++ code was just compiled with the default (-Os possibly) in the online compiler).
Hope that answers part of your question.
posted by Matthew Else 14 Sep 2016That is also partially a sign that the mbed GPIO code isn't really something that makes me a happy panda, but yeah that does answer that question :).
posted by Erik - 14 Sep 2016Hi Mathew,
May I know how you get the perf data of ST F401RE borad when you running a sample JS code?
posted by dooriya li 10 Feb 2017