V8 benchmark engines comparison #4386
Comments
|
With the following cmake configure options: QuickJs: NodeJS jitless NodeJs |
|
First of all, I highly suggest to turn My two concerns: Comparing a low-end engine with a high-end engine (V8) is quite unfair. Both engines have a different design pattern. In high end engines the main aspect is the performance which has significant memory/stack usage and enormous binary size. JerryScript was designed to low-end devices with restricted resources so the main priority is the low memory usage and the small binary footprint. However, keeping these numbers low work against the performance. So I suggest to compare only the low-end engines. What I'd call a fair and detailed comparison is:
Where Engine is one of Also good to mention the supported revision of the standard by the tested engines, since the new language elements above ES6+ are real challenges to the developers to support them without serious engine slowdown.
|
lygstate
changed the title
JERRY_LINE_INFO affect little, and Splay are toooo slow, this should be a bug. |
|
Let's get just a wee bit more professional. "too** slow" is not anything helpful. Same goes for "this should be a bug." Analysis is welcome. |
|
Splay is a specific test for GC. It was designed to test the evolutional GC. Since JerryScript uses single mark&sweep model it wouldn't perform well in this test. However increasing the |
What |
|
I have no optional number to say. Increasing the recursion limit will increase the score and stack usage simultaneously. So keep fine tuning it, I suggest to start doubling it continuously. |
|
@rerobika |
rerobika
changed the title
|
Now found the cause of splay too slow I guess mainly because of -DJERRY_LCACHE=1 and -DJERRY_PROPRETY_HASHMAP=1 benchmark result: |
|
cc @dbatyai |
Moreover I've tested the engine on splay with lcache and hashmap and without them and there were no significant difference. But feel free to share how that you came to this conclusion. |
|
As it was said before, the splay test was created specifically to test garbage collection, and thus uses a lot of memory and creates a lot of fragmentation. The fact that it is slow has nothing to do with the lcache, and very little with hashmaps (these can have a slight effect on fragmentation). The reason this test is slow is that the jerry allocator was not designed to handle this much memory, and maintaining the free block list gets more and more costly as the memory get fragmented. I have a few ideas on how to improve the logic behind the allocator to make it less affected by fragmentation, but can't really give anything specific for now. However the fact remains the same, the core idea behind the allocator will still be handling smaller amounts of memory with as little overhead as possible, and not high performance. When larger amounts of memory is required or performance is more critical then the system allocator should be used instead. |
Hi, verified, you are right, but the current situation is on 64bit processor, we can not using system allocator, that's why I have forced to using jerry memory allocator and leading to significant fragmentation |
|
Sorry to bring up an old topic but lvgl switched memory allocators recently which gave a pretty big speed boost. Could have a look at what they used. I forgot the name of the library right now. |
Refer to https://bellard.org/quickjs/bench.html
I am using the following branch to bench jerryscript
https://github.com/lygstate/jerryscript/tree/benchmark
Bench result:
Currently, the QuickJs
Splaysplay tree benchmark case are too slow exceptionally, this is more like an jerrscript issue--jerry-cmdline-snapshot=ON --jerry-math=ON --jerry-ext=ON
--amalgam=ON --snapshot-exec=ON --stack-limit=512 --gc-mark-limit=64
--cpointer-32bit=ON --system-allocator=ON --external-context=ON
--regexp-strict-mode=ON --js-parser=ON --line-info=ON --error-messages=ON
--logging=ON --cmake-param=-GNinja --cmake-param=-DJERRY_LCACHE=1
--cmake-param=-DJERRY_PROPRETY_HASHMAP=1 --profile=es.next
duktape.c duk_cmdline.c duk_console.c
-lm -lc -o duk
The text was updated successfully, but these errors were encountered: