The percent number is calculated from the time it takes to generate 1 second of sound data, so it's a pretty accurate measure of CPU time for the emulation.
On Tuesday, December 24, 2013 5:59:32 AM UTC+1, azakai wrote: > > I was hoping that getting the compiler to emit different stuff would help > the JITs. But it sounds like in this case hand-optimizing as you are doing > makes the most sense, if it is one big and important switch at the core. > > What does the 40% on Android mean? What is compared to what? > > - Alon > > > > On Sun, Dec 22, 2013 at 12:37 PM, <[email protected] <javascript:>> wrote: > >> I got it a lot faster by breaking up the switch statement manually >> (Around 4x - 5x). Interestingly, even though this is quite CPU-heavy code >> (emulation) the difference between Chrome and Firefox is marginal (Around >> 10%) >> >> Outlining does not seem to help, neither with compilation speed nor run >> speed. >> >> I compile with normal optimizations (-O2) and no extra flags that may >> slow things down as far as I know. >> >> Have not checked the useIfs-thing, becuase this was a JIT problem and >> that seems to be about the compiler. Also, my switch statement has close to >> 256 statements so I don't think it applies anyway. >> >> -- Sasq >> >> On Sunday, December 22, 2013 12:11:39 AM UTC+1, azakai wrote: >> >>> Yes, outliner is one option here. If that doesn't help, you can manually >>> change the heuristics for switches vs ifs in the compiler, look for >>> `useIfs` in src/jsifier.js. >>> >>> Was this with optimizations on, or not? >>> >>> - Alon >>> >>> >>> >>> On Sat, Dec 21, 2013 at 2:35 PM, Sören Balko <[email protected]>wrote: >>> >>>> Why don't you change the source to split up that single large switch >>>> statement across multiple functions? The Chrome profiler should then tell >>>> you if that was effective, no? You could also try Alon's outlining feature >>>> and see if that does the trick without touching the source. I think this >>>> was introduced to split large functions into smaller ones in order to make >>>> it easier (and faster) for JITs to optimize the code. >>>> >>>> >>>> Am Samstag, 21. Dezember 2013 20:11:10 UTC+10 schrieb [email protected]: >>>> >>>>> So the SID-chip/C64 emulation part of my music player runs very slow - >>>>> about 10x native. Checking in the Chrome profiler I see that the main >>>>> function has an exclamation mark with: >>>>> Not Optimized: SwitchStatement: Too many clauses >>>>> >>>>> The 6510 emulation core is one big switch statement, so this is true. >>>>> I realize this is a JIT problem but I wonder if you can get the >>>>> emscripten >>>>> compiler to help in this situation? >>>>> >>>>> Otherwise maybe I can try breaking it up manually, but would that help? >>>>> >>>>> -- Sasq >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
