>>> That is what the emulator is already doing. If we start emulating HW >>> down to individual CPU cycles, it'll only get slower. :( >> >> I think this is wrong in some way. Otherwise I wouldn't see this: >> 1) running on TBPL (AWS) the internal timings reported show the specific >> test going from 30 seconds to 450 seconds with the patch. >> 2) on my local system, the test self-reports ~10 seconds, with or >> without the patch. >> >> The only way I can see that happening is if the simulator in some way >> exposes the underlying platform performance (in specific timers). > >Right. What I mean is that we're currently emulating an ARM chipset, but >without timing. If we start doing cycle-correct emulation, it won't get >faster.
I still think there's a confusion here. How are timers connected? If I set a timer for 20ms, is that NNNN ARM instructions? (ignoring if they're cycle-accurate numbers or now, I'd be fine with assuming 1 instruction-per-cycle. Or is is 20ms on the host machine, regardless of how fast or slow the ARM emulation is running? (I think strongly it's the latter.) >>>> Another option (likely not simple) would be to find a way to "slow down >>>> time" for the emulator, such as intercepting system calls and increasing >>>> any time constants (multiplying timer values, timeout values to socket >>>> calls, etc, etc). This may not be simple. For devices (audio, etc), >>>> frequencies may need modifying or other adjustments made. >>> >>> If we do that, writing and debugging tests will take even longer. >> >> It shouldn't, if the the system self-adapted (per below). That should >> give a much more predictable (and closer-to-similar to a real device) >> result. BTW, I presume we're simulating a single-core ARM, so again not >> entirely representative anymore. > >Oh, I now get the point of this idea. We could probably implement this >by modifying the emulated timer(s?) within the emulator; >hw/goldfish_timer.c might be the place. Although I wouldn't do this if >we have other options. Don't know how this would affect frequencies >(audio, etc.). If we do this, it wouldn't really affect those - but from the host side the data coming out would be "slow" (or even fast on a fast machine). I wouldn't use this for interactive use for media (that gets even more fun); this would be an option to adjust timing or not. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
