Hey all,
I'm working on a 3D browser engine using WebGL and javascript. Something similar to what Irrilicht put out (Copperlicht). Recently I've implemented a terrain system and started to load some big terrains to push its limits. When loading a 1025X1025 heightmap I start to take a FPS hit, down to about 30 FPS. The thing is, when I look at my computers diagnostics, I'm still barely scratching what it can handle.
With the game being brought down to 30 FPS I'm using 20-25% of my CPU, I still have about a 1.75 gigs of DRAM, I'm only using 500MB of VRAM, with 1 gig available, and my gpu is only running at about 40%. The only thing I can think of that would cause this would be that I'm getting horrible cache coherency and my CPU is sitting idle most of the time.
I'm sure there are only a select group of people out there that know enough about how browsers handle javascript, but if you are reading this I could use some suggestions on how to find my bottleneck.
Thanks in advance.
Browser Game Engine Speeds.
Assuming you have a quad core CPU (or hyperthreaded dual core) 25% usage usually means that one core is at 100% usage and the others are at 0%. That is the engine isn't making use of threads, and is CPU bound.
Author
I do indeed have a quad core. I thought that browsers handled all thread creation and multiprocessing? Is there anything I can do to make use of my other cores?
Edit:
I guess there is something called Web Workers that is some basic way of implementing threads. I always thought that browsers were smart enough to make use of multicore processors.... I guess there aren't a lot of web applications that need more than one core.
Kind of ironic that my 6 year old desktop with a 3ghz single core has more CPU power than my brand new quad core i7.....
Edit:
I guess there is something called Web Workers that is some basic way of implementing threads. I always thought that browsers were smart enough to make use of multicore processors.... I guess there aren't a lot of web applications that need more than one core.
Kind of ironic that my 6 year old desktop with a 3ghz single core has more CPU power than my brand new quad core i7.....
I do indeed have a quad core. I thought that browsers handled all thread creation and multiprocessing? Is there anything I can do to make use of my other cores?
Edit:
I guess there is something called Web Workers that is some basic way of implementing threads. I always thought that browsers were smart enough to make use of multicore processors.... I guess there aren't a lot of web applications that need more than one core.
Kind of ironic that my 6 year old desktop with a 3ghz single core has more CPU power than my brand new quad core i7.....
There is now a concept of web workers that allows browsers that implement multiple threads. Check this out to get you started: Web Workers
I don't know specifically which browsers implement this yet (I suspect Chrome and Firefox do, whereas IE probably doesn't, except maybe IE9).
Unfortunately, if you're using a prebuilt engine that isn't aware of these sorts of things, you would have to implement all of the concurrency yourself, which is likely to be complicated to say the least.
Author
There is now a concept of web workers that allows browsers that implement multiple threads. Check this out to get you started: Web Workers
I don't know specifically which browsers implement this yet (I suspect Chrome and Firefox do, whereas IE probably doesn't, except maybe IE9).
Unfortunately, if you're using a prebuilt engine that isn't aware of these sorts of things, you would have to implement all of the concurrency yourself, which is likely to be complicated to say the least.
Thanks for the post. I've browsed through Web Workers a bit. Are these true OS threads? Are they making real system calls such as fork() to spawn processes? If so then that's awesome. It will be a lot of work to implement but I'm glad the technology is there.
Before resorting to creating multiple threads you might want to profile your existing code and find out which bits are slow, and if it can be optimized first. A quick search says FireBug has a JavaScript profiler.
Author
Before resorting to creating multiple threads you might want to profile your existing code and find out which bits are slow, and if it can be optimized first. A quick search says FireBug has a JavaScript profiler.
Awesome! Thank you very much, a great resource that I was unaware of.
I thought that browsers handled all thread creation and multiprocessing?
Ugh, no.
Is there anything I can do to make use of my other cores?[/quote]
Not really.
I guess there is something called Web Workers that is some basic way of implementing threads.[/quote]
Not usable for low-latency. Web workers are something you spin to parse or request a web page over 5 seconds so it doesn't block UI.
I always thought that browsers were smart enough to make use of multicore processors.... I guess there aren't a lot of web applications that need more than one core.[/quote]
Yes, they make use of multiple cores.
JavaScript however is painfully restricted to only ever having access to single-threaded processing due to DOM design.
Kind of ironic that my 6 year old desktop with a 3ghz single core has more CPU power than my brand new quad core i7.....[/quote]
JavaScript has computing power of 8086 running at 2MHz.
Author
JavaScript has computing power of 8086 running at 2MHz.
I find this kind of hard to believe, but I'll bite. So are you saying that there is nothing I can do to keep my cpu from running the engine on one core? Also, the statement above makes it seem like no matter what CPU I have, I'm running at 2MHz?
In one statement you say that browsers don't handle thread creation or multiprocessing, then you say that I don't have any ways to make threads or spawn processes myself, and then you say that browsers make use of multiple cores. I'm a bit confused here.
I can't seem to find any articles on how much slower javascript is compared to a compiled c++ program.
Of course he's "stretching it a bit" to make the concept clear by using a bold statement. It's not like that. It's more like "take your CPU speed and divide by 100"... and throw away most architectural improvements over the last few years, and slice your cache to 1/4.
You don't see many benchs around as they make no sense, especially for JS, as the implementation is king of the hill in determining performance. Furthermore, little details can make a lot of difference on some systems... but not others. Such as using proper data types instead of just "letting the runtime guess".
So, it's comparing apples to pineapples... nonetheless, the best effort I know about is here. You will see there's some dependancy on the exact workload.
You don't see many benchs around as they make no sense, especially for JS, as the implementation is king of the hill in determining performance. Furthermore, little details can make a lot of difference on some systems... but not others. Such as using proper data types instead of just "letting the runtime guess".
So, it's comparing apples to pineapples... nonetheless, the best effort I know about is here. You will see there's some dependancy on the exact workload.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
