New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dart slower than V8 when drawing to canvas #10344
Comments
Note: check the VM's raw perf of Tracer here: http://www.dartlang.org/performance/ |
cc @sgmitrovic. |
FWIW using Dartium Version 28.0.1485.0 (195393) and Dart Editor version 0.5.1_r22072 and Chrome Version 26.0.1410.65 |
Update: this might be an issue with toString() on Color, which is only called when we actually visualize. So, we're still investigating. Still, can we confirm that the "fast path" for canvas data is the same with V8 and Dart VM? |
This comment was originally written by @bp74 I was wondering about the same issue. Here is a simple benchmark which shows that Chrome/Firefox/IE can draw more than twice as many objects compared to Dartium: http://www.stagexl.org/demos/performance.html If i collect a JavaScript CPU profile with the Chrome developer tools, i can see that ~50% of the CPU usage is pure JavaScript and the other ~50% are the drawImage calls to the canvas. So there is a huge potential for the DartVM to shine. |
One data point is that the overhead of calling a DOM function is much bigger with Dart than with V8. V8 has optimized stubs for these calls. I don't know if the Dart VM does. Simple example: Dart code: <html> flaf.dart: import 'dart:html'; update(context) { main() { JS code: <html> function f() { The JS version uses 325ms on my machine and the Dart version uses around 750ms. |
Thanks for the confirmation. Is there a known bug for this, or would you like me to open a separate new bug? |
Removed Area-Dartium label. |
Added C3 label. |
Mads seems to have confirmed that this is a problem in the bindings. Back to Dartium. Removed Area-VM label. |
I think there is a piece of VM engineering here as well. V8 has stubs that performs direct calls and that is integrated in the optimizing pipeline. I don't know if that is the case for the Dart VM, but I was under the impression that it isn't. The bindings code is calling the same methods as the V8 one. The difference is the interaction with the VM: how fast do you get to the bindings code and how fast is the interaction through the Dart VM API. Dartium bindings engineers and Dart VM engineers should get together and profile this. It is fine to leave it in Area-Dartium while we investigate. |
I used a bit of time profiling this. The main part of this is caused by extremely slow conversions from integers to doubles in the bindings. The VM API does not include any method that makes it easy to get out a double from an integer so the bindings end up calling toDouble on the number. I will put a fix into the bindings that will extract a 64-bit integer and cast it to a double and use that. I would like to have a fast method to extract a double from a number in the Dart VM API. With the hacked conversions V8 and Dart are close in performance on these calls. |
Ivan and I discussed this. There is also the option of modifying the dart code generated for these apis to perform a toDouble call on all arguments that are marked as floats in the IDL files. That way, we can optimize the conversions on the Dart side and use the fast double extraction through the API. |
On top of what Mads suggests in comment 13 we should consider changing the signature of DOM calls which expect doubles to double. There is a reason we have these types for documenting intent. |
note that adding toDouble on the boundary would imply allocation to convert smis into doubles, while V8 does not need one. |
|
This comment was originally written by antonm@google.com Added this to the Later milestone. |
I have a CL which changes all DOM float/double APIs to be exposed as doubles- Are there changes I can make on the C++ side to further optimize this? I'm not seeing noticeable perf changes with these changes alone (and after updating the renderer to use doubles). Is the expensive int->double conversion executed if the Dart code only passes in doubles? |
The int->double conversion is only executed if the number is an integer. It could be that the toDouble calls (which will box the integer in a heap allocated double in the VM) offsets the gains of not having to get the integer value and cast it to a double on the C++ side? |
I made the Tracer benchmark visible, and runnable in the browser. I noticed that Dartium is much slower than V8. After meeting with the VM folks, they think the issue isn't with the VM itself. Perhaps there is a slow path between the pixel data in the VM and getting that data into the canvas.
After ~ 10 clicks of the Render button, I see:
Chrome: 86
Dartium: 144
To replicate, use my branch of benchmark_harness: https://github.com/sethladd/benchmark_harness
To get the code:
git clone git://github.com/sethladd/benchmark_harness.git
cd benchmark_harness
pub install
and then open:
example/Tracer/js/index.html
example/Tracer/dart/index.html
See attached screenshot.
Hope that helps!
Attachment:
Screenshot_4_30_13_5_14_PM.jpg (934.06 KB)
The text was updated successfully, but these errors were encountered: