Closed kybernetyk closed 13 years ago
Agreed. Although the code could use some optimizations, 60% sounds too high, even for jsmad.
What browser are you running it on?
On Sat, Jun 18, 2011 at 12:30 PM, jsz < reply@reply.github.com>wrote:
on my core 2 duo macbook pro the playback eats 60% - 70% cpu. even if the c2d is somewhat older that's way too much for simple mp3 playback. (even for an pentium 100)
Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/jsmad/issues/10
Amos Wenger Community Development Engineer official.fm - "The Do It Yourself Music Club" I'm @nddrylliog https://github.com/nddrylliog on GitHub
FYI, Chrome 13.0.782.1 dev under Ubuntu 10.04 on an 2.0GHz Core 2 Duo MacBook from 2007 uses only 20% CPU.
The CC & GC are taking huge amounts of time, this is partly audiolib's fault, I'm working on that, but also, it might be a good idea to see if you're creating a lot of variables on every buffer fill or so, and if there's any way you could lower that amount, for example by reusing variables, or defining them lower in the scope (max 1 level down, otherwise it beats the purpose).
Well, we do that already in some places (reusing temp variables), but probably not everywhere we could. I did these premature optimizations back when jsmad was not working at all, so I didn't do too many in case it made things go wrong, so that we could revert easily. Scoping is not something to take likely in JS, it seems!
Other performance bottlenecks in jsmad are I/O, obviously, but the recent patches from gliese1337 (see nddrylliog/jsmad#12 ) are attempting to fix that, I think. Also, the full-synth is incredibly costly - I'm wondering if it would help if we replaced all those
a = b + c + d;
a += e + f + g;
a += h + i + j;
With
a = b + c + d +
e + f + g
h + i + j;
or if the JS engines are already smart enough to figure it out.
I had originally replaced all the a += with + but things didn't work so I reverted back to be as close as possible to the C code. Now I'm not sure it was the cause - probably not. But I'm wondering about rounding/precision, stuff like that. Floating point is weird shit, better be careful.
On Tue, Jun 21, 2011 at 12:24 AM, jussi-kalliokoski < reply@reply.github.com>wrote:
The CC & GC are taking huge amounts of time, this is partly audiolib's fault, I'm working on that, but also, it might be a good idea to see if you're creating a lot of variables on every buffer fill or so, and if there's any way you could lower that amount, for example by reusing variables, or defining them lower in the scope (max 1 level down, otherwise it beats the purpose).
Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/jsmad/issues/10#issuecomment-1406370
Amos Wenger Community Development Engineer official.fm - "The Do It Yourself Music Club" I'm @nddrylliog https://github.com/nddrylliog on GitHub
Floating point is weird shit, better be careful.
It sure is and if 0.1 + 0.2 !== 0.3, it's hard to rely on anything else working either. :)
Scoping is not something to take likely in JS, it seems!
True that! When I was writing the delay for audiolib, I did a mistake like
var feedback = 0.5;
time = 0.5;
And it was performance, sound integrity, etc right out the window.
It's probably helpful, because if it doesn't optimize that, you have two more assignment operations than you need, and that's not even a case of premature optimization. :)
It's probably helpful, because if it doesn't optimize that, you have two more assignment operations than you need, and that's not even a case of premature optimization. :)
Well, more like 9x7 too many assignments, see https://github.com/nddrylliog/jsmad/blob/master/src/synth.js#L1048 and below.
Also, this function is pretty mad: https://github.com/nddrylliog/jsmad/blob/master/src/synth.js#L100 - as the comment says "Totals: 80 multiplies, 80 additions, 119 subtractions, 49 shifts (not counting SSO)". I kind of want to use a JavaScript parser and rewrite the AST so that it fits in just one line. Just for the kicks :) (Well probably not one line because some values are reused so it would be a waste)
Amos
On Tue, Jun 21, 2011 at 10:38 AM, jussi-kalliokoski < reply@reply.github.com>wrote:
Floating point is weird shit, better be careful.
It sure is and if 0.1 + 0.2 !== 0.3, it's hard to rely on anything else working either. :)
Scoping is not something to take likely in JS, it seems!
True that! When I was writing the delay for audiolib, I did a mistake like
var feedback = 0.5; time = 0.5;
And it was performance, sound integrity, etc right out the window.
It's probably helpful, because if it doesn't optimize that, you have two more assignment operations than you need, and that's not even a case of premature optimization. :)
Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/jsmad/issues/10#issuecomment-1408816
Amos Wenger Community Development Engineer official.fm - "The Do It Yourself Music Club" I'm @nddrylliog https://github.com/nddrylliog on GitHub
Also, this function is pretty mad:
Yes, and I love how it looks! :) But I'd see if any shifts could be done with multiplying or dividing, shifts in JS, not so nice (getting better though).
I'm running firefox 4 on os x. (Sorry for responding so late - but I commented on the "epic rm -r /usr" comment and my github notification area is spammed to death since then)
(Sorry for responding so late - but I commented on the "epic rm -r /usr" comment and my github notification area is spammed to death since then)
Ha! I was the second commenter, my notification area is also wrecked beyond repair :)
I'm running firefox 4 on os x.
Then this is a duplicate of #18 (or 18 is a duplicate of this one, doesn't matter - the other has more details anyway). Closing, please follow issue #18 from now on (@maxart has opened a Mozilla issue on bugzilla)
(Also, by mail notification I received your comment containing "I'm running Safari 5", so I was wtf? Is he running a special Web Audio-enabled nightly build of Safari/Webkit? Cause those seem to be pretty experimental, although they would be pretty interesting testing platforms as well).
on my core 2 duo macbook pro the playback eats 60% - 70% cpu. even if the c2d processor is somewhat older that's way too much for simple mp3 playback. (even for a pentium 100)