3 ms·
>> "No modern web browser controls all of the code, since it must execute arbitrary JavaScript - which can block and crash." That's a silly argument. The follo
by axod 17y ago
>> "No modern web browser controls all of the code, since it must execute arbitrary JavaScript - which can block and crash."
That's a silly argument. The following can't block or crash.
while(true) {
jsRuntime.executeInstruction();
// Other stuff.
}
- scott_s 17y agoExecute a single JavaScript instruction at a time? I doubt the performance of that would be acceptable. But if you're aware of any browsers doing that, I'd like to know.
- axod 17y agoIf I were to write a browser right now, it's how I'd do it. You would more likely execute a few js instructions per loop, depending on what else you have to do in that loop also - network check, ui update, etc. Why would there be a performance hit in doing js instructions one by one though ;) A loop isn't expensive.
- scott_s 17y agoYou would have terrible cache performance, since you would constantly bounce back and forth between the JavaScript VM and other browser code.
- axod 17y agoCode is code. If you can explain that a bit more I'd be interested. Obviously you wouldn't update the UI every time you execute a js instruction. That would be insane. I just put 1 js instruction in the loop to have the minimum unit, in case anything else needs to be updated very quickly at the same time - eg some animation etc
- tsuraan 17y agoCPUs (or cores in a CPU) have a pretty small instruction cache. On a Core2, I believe it's 32K cache per core. It's somewhat expensive (slow) to fetch instructions from RAM to L1, but once code is in L1, reading from it is immediate, or close to it. If you have a two-core machine where one core can do most of your js dispatch logic, and the other core can do the inner loop of your rendering logic, then you can have much better performance than constantly swapping out your logic on the cache of a single core. I'm really not sure how useful it is to cache-optimise a browser. You need to be able to fit a significant amount of logic into 32K in order to take advantage of cache. When I used to do realtime image processing (AR), I could get an order of magnitude speedup by just getting my logic to fit into 32K; image processing code can literally go from 3fps to 30fps just by tightening code to the point where it can fit in L1 cache. I don't know if it's possible to fit significant amounts of rendering logic or js logic into 32K, but if it is, then dedicating a core to each of those functions could give a significant speedup.
- scott_s 17y agoThe JavaScript VM will have a significant amount of state associated with it. Executing a virtual instruction will require accessing that state. If that data is not in the CPU's cache, it will cause cache misses, which stall code progression. If you then use that data in the cache for a while, then the cost of the cache miss will be amortized. But what you're proposing is going back and forth quickly between the JavaScript VM and the rest of the browser code. The browser code will also need to bring its data into the cache, which will kick out the JavaScript VM's data. Since you're proposing that the JavaScript VM should do a very small amount of work at each time, and it will likely need to bring all of its data back into the cache each time, you will see a lot of CPU stalls.
- axod 17y agoYeah I think we have a long way to go before js performance is affected by CPU caches.
- dkersten 17y agoA loop isn't expensive, but swapping your interpreters code out of registers and cpu cache for each js instruction may be. Anyway, this method doesn't really get you much in the way of JIT compiling your JS either..