LOL firefox Nightly build is again about twice as fast :O. On Fri, May 9, 2014 at 11:01 PM, Christoph Husse <[email protected]> wrote: > Well damn xD. Firefox is twice as fast :O. Game plays totally smooth > there with only 50% CPU utilization... > > Here can see for yourself if you like... Finally got it working I am > so happy lol: > > https://dl.dropboxusercontent.com/u/27687180/WebServer/SNESOnline/SNESOnline.html > > Input is: > > Left, Right (steer), up, down (menu) > "A" for jump > "S" for use collectible > "D" for drive and advance menu > > I think anyone who is older than 20 years knows this game anyway :D > > Awesome job with emscripten. This is really impressive to myself. > Even though I have to say that the performance is still quite bad. On > my native C++ build it consumes about 30 times less CPU than in the > browser. > > > On Fri, May 9, 2014 at 10:13 PM, Christoph Husse > <[email protected]> wrote: >> Meh damn you are right... There was something wrong with firefox ;). >> Since the Web Audio API im using seems to be broken on Firefox, it >> doesn't utilize much CPU because it seems to be stalled by some audio >> stuff. Weird. I will have a look into it and keep you updated with the >> performance when audio is active :). >> >> On Fri, May 9, 2014 at 10:08 PM, Alon Zakai <[email protected]> wrote: >>> Ah, CPU emulator makes some sense if it has a bytecode VM or something else >>> with packed data. >>> >>> That performance sounds very surprising. Is it on a fully optimized build? >>> Do you see errors in the web console in firefox? It should warn if there is >>> a perf problem like asm.js not validating. >>> >>> - Alon >>> >>> >>> >>> On Fri, May 9, 2014 at 1:06 PM, Christoph Husse >>> <[email protected]> wrote: >>>> >>>> Well I am porting a CPU emulator and it seems to think unaligned >>>> memory accesses are really cool, or well at least the programs that >>>> run on this emulator :) >>>> >>>> BTW, The port works now and runs almost good on Chrome... Like 100% >>>> CPU utilization (one core). I think I can queeze out a bit more by >>>> skipping some frames and using webworkers for some stuff too to get a >>>> smooth experience. >>>> >>>> But on Mozilla Firefox this port stinks. Like its a slideshow. Really bad. >>>> >>>> On Fri, May 9, 2014 at 10:01 PM, Alon Zakai <[email protected]> wrote: >>>> > That hasn't been my experience, actually - when I've ported apps, they >>>> > tended to have just a small amount of unaligned accesses (e.g. in >>>> > network-reading code, serializing code, or GC code). Just rebuilding >>>> > after >>>> > fixing each one was fast enough. I'm surprised you have so many - what >>>> > is >>>> > their cause? Does your app purposefully pack structs to unaligned >>>> > offsets or >>>> > something like that? Generally speaking it isn't "easy" to cause an >>>> > unaligned access in C/C++. >>>> > >>>> > - Alon >>>> > >>>> > >>>> > >>>> > On Thu, May 8, 2014 at 11:06 PM, Christoph Husse >>>> > <[email protected]> wrote: >>>> >> >>>> >> But back to the general public... I think its an awesome idea to add >>>> >> this >>>> >> option you described. Because an application with misaligned accesses >>>> >> usually will not only contain one of them and it gets very tedious to >>>> >> figure >>>> >> them all out if SAFE_HEAP terminates your app on every occasion. Even >>>> >> further it might be possible to only report for each single line of >>>> >> SAFE_HEAP_LOAD etc ONCE per run, so that you don't get spammed with >>>> >> useless >>>> >> double reports. It's then easy to map the reported lines back to C++ >>>> >> sources >>>> >> with a debug info options as each SAFE_HEAP_LOAD will have the C++ code >>>> >> line >>>> >> as a comment behind it (could be done in a simple script for >>>> >> instance)... >>>> >> >>>> >> As far as I know there is no tool outside of emscripten which allows >>>> >> you >>>> >> to enumerate unaligned accesses. Valgrind had a feature request but it >>>> >> seems >>>> >> it landed on the GTFO TODO list for whatever reason... >>>> >> >>>> >> -- >>>> >> 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/d/optout. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to a topic in the >>>> > Google Groups "emscripten-discuss" group. >>>> > To unsubscribe from this topic, visit >>>> > >>>> > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe. >>>> > To unsubscribe from this group and all its topics, send an email to >>>> > [email protected]. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> 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/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "emscripten-discuss" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout.
-- 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/d/optout.
