3 ms·
Possibly in some browsers. An alternate (better) model would be to simply have a single thread with a main loop, have async networking, and UI updates periodic
by axod 17y ago
Possibly in some browsers.
An alternate (better) model would be to simply have a single thread with a main loop, have async networking, and UI updates periodically in the same thread.
while(true) {
networking.check(); // Check if any sockets are ready for read/write/connect
ui.update(); // Update the UI a bit if needed
}
The only case this would be a terrible idea is if you don't have control of all the code, or need to interface to things that may block/crash/etc.
- gaius 17y agoThis is how Tcl works.
- coliveira 17y agoThis only works if the UI library has good performance. During years this was a big issue in Java, and why it really needed multi-threading.
- scott_s 17y agoNo modern web browser controls all of the code, since it must execute arbitrary JavaScript - which can block and crash. Everyone doing something doesn't make them right. But when all major instances of an application are implemented differently than you think is best, perhaps you don't understand the problem as well as you think you do. Chrome, I think, is the best browser architecture, and it looks like IE and Firefox will adapt something similar. I think they use separate processes to manage tabs instead of threads, but it's still parallel.
- 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.