g3: Probably you have seen my emulator.
http://s-macke.github.io/jor1k/
It does more or less the same, but emulates a different CPU.
Your emulator is impressive and especially fast. I think it took a long time for you to optimize it.
I tried to start TinyCore, but it stops after decompressing the kernel. So still some work to do ;)
I saw the source and I have some tips for you:
Avoid the UInt32 Arrays and the >>> operator.
They could be transformed by the JIT compiler into doubles and slow everything down. This does not happen with the Int32 Arrays and the >> operator.
There is a plug-in called JIT-Inspector which give you this information. Unfortunately it does no longer work in Firefox 24. Firefox 22 was the last working version.
Additionally worker threads gave me an incredible speed boost in Firefox. The whole GUI stuff is then separated. Especially the costly canvas update.
Hi s-macke. I've read the source code of your emulator before, good job.
I'm aware of the problem with big integers. I'll look into this more closely, thanks for your help.
Regarding workers: I need some restructuring to get this working. I'll also need to figure out the fastest way to exchange the canvas buffer between the worker and the browser.
I did the copying by a for loop copying In32 Arrays which is an acceptable solution. It slows down the worker thread by 1-2% by using 10fps and a screen size of 640x400x32. I think the reason why I didn't used more advanced ArrayBuffer functions to do this was the IE. Probably this has changed.
The color transformations and so on can be done in the master GUI-thread.
Do you have any documentation to support the stuff about UInt32? The old Firefox JIT had some limitations like this but I'm not aware of anything like that in the current one (which has been shipping for multiple versions). Is it a v8 limitation similar to the 31-bit 'small integer' limitation?
Indeed at the moment I have nothing to support it. Half a year ago I had dozens of examples. Now it is more or less experience. In v8 I had two weeks ago some strange deoptimizations behavior in my code. It was almost gone after I exchanged two >>> operations. So in my experience it is still better to avoid such cases. No one knows really how the JIT compiler are working. What makes it worse. The behavior is changing every 6 weeks. And don't forget: Out there is more than Firefox and Chrome ;)
Have you consider reporting strange deoptimization behaviour to V8 team? Performance issues are better investigated than worked around.
V8 has special support for uint32 values in optimized frames to avoid converting them to doubles when they flow into truncating operations. If that support somehow became broken that would be unfortunate. (and it's actually only >>> 0 that is problematic from the optimization point of view. as long as you shift by non zero result is within Int32 range).
The problem is that I can't really explain it. I can hardly say: Hey, if I change this line (from 3000 lines) from A to B I get a 80% reduced chance that my program is deoptimized after 30 seconds and slows down by a factor of five.
No one will take the time to look at it.
What I want is information. They have to provide a tool that let me see what happens. Especially if a variable or operation is treated as double or int. The JIT-inspector for Firefox (is)/was a great tool for this. Unfortunately it does not support worker threads.
No, I think you are making a wrong assumption here. A bug report like that, that pinpoints a line in question and provides observable metrics is the best kind of performance issue that you can file against V8.
Back when I was on the V8 team I would immediately set aside some time to investigate and triage/fix/explain it because stable performance is as important for any VM as correctness.
So don't hesitate to file bugs like that against JavaScript VMs be it V8 or SpiderMonkey. You might be surprised with VM engineers' eagerness to investigate and address performance problems.
> What I want is information.
There are ways to trace optimizations and deoptimizations in V8. Unfortunately nothing as simple to use as JIT-inspector. Most of what V8 has right now is geared towards VM engineers.
I have a tool called IRHydra[1] that can display some information that V8 dumps in a more or less digestible form. It's most useful for performance investigations in the console but to a certain degree works for browser as well (biggest problem for it "multithreading": because V8 dumps part of the information into stdout and as a result it can arrive arbitrary mixed if you have many workers).
Your emulator is impressive and especially fast. I think it took a long time for you to optimize it. I tried to start TinyCore, but it stops after decompressing the kernel. So still some work to do ;)