| |||||||||||||
Should be: Goodnight, Perl 6.Should be: Goodnight, Perl 6.Posted Feb 13, 2013 21:30 UTC (Wed) by khim (subscriber, #9252)In reply to: Should be: Goodnight, Perl 6. by Cyberax Parent article: Chromatic: Goodnight, Parrot
That's because Dalvik should be used as a glue system for native code and the UI layer. But UI code is the code where latency is more important then throughput! It does not matter if you render new frame 10 milliseconds or 15 milliseconds, but if you usually render it in 5 milliseconds but occasionally need 50 then you have a problem - and this is exactly what typical GC does to your program.
(Log in to post comments)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:44 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
GC in G1 rarely took more than 20ms _and_ it was designed to be interruptible. I've actually debugged laggy applications on G1 and most of lags were caused by the native libraries taking too much time to do stuff.
Flash drive on G1 is also pretty crappy and can sometimes pause for a long time even on simple operations.
GC or not GC Posted Feb 13, 2013 23:04 UTC (Wed) by marcH (subscriber, #57642) [Link]
> GC in G1 rarely took more than 20ms _and_ it was designed to be interruptible. I've actually debugged laggy applications on G1 and most of lags were caused by the native libraries taking too much time to do stuff.
In fact the real problem that this discussion demonstrates is the lack of transparency. Not just developers but semi-technical, "power users" should be able to do basic "lag troubleshooting" with relative ease, on the field, not requiring a PC and remote debugger.
GC or not, Android or iOS, all these systems should have basic self-monitoring and logging features *built-in* producing clear, power-user readable reports of all events like "ran out of memory, terminated X while Y was using 100M" and "ran GC for 2 seconds", etc.
Nothing beats name and shame. This is how Powertop multiplied by 2 or 3 the battery life of many Linux laptops.
GC or not GC Posted Feb 13, 2013 23:08 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
You can get GC logs without debugger. But why do you need them? Debugging lags is not really a stuff that power users should do.
> GC or not, Android or iOS, all these systems should have basic self-monitoring and logging features *built-in* producing clear, power-user readable reports of all events like "ran out of memory, terminated X while Y was using 100M" and "ran GC for 2 seconds", etc.
GC or not GC Posted Feb 14, 2013 0:42 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Debugging lags is not really a stuff that power users should do.
It's the only way to identify the guilty applications/services/system configurations/etc
As another example Windows' Resource Monitor (from Vista onwards) totally changed my Windows experience. I used to struggle against bloatware, taking random shots in the dark. Thanks to the Resource Monitor I am now doing surgical and very successful strikes in no troubleshooting time at all.
Too bad there is no "bootchart for Windows" yet. Or isn't there? Autoruns is nice but just a list.
Any complex and professional system has monitoring features built-in. Why not smartphones too? They are certainly complex enough to deserve this.
> Android has something like it, it can estimate the power use by application. You can use various apps to view these stats.
These are averages - the opposite of latency measurements.
GC or not GC Posted Feb 15, 2013 0:04 UTC (Fri) by marcH (subscriber, #57642) [Link]
> Android has something like it, it can estimate the power use by application. You can use various apps to view these stats.
In fact what's needed is something very similar to this. An interface just as simple that displays the list of what the CPU/memory/network/applications were too busy doing in the last minute or so when it failed to react quickly.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:53 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
There are two general ways to deal with GC pauses in programs requiring a near-realtime response. You can use a realtime GC algorithm which amortizes the GC work across all allocations and guarantees a bounded response time, or you can guarantee that there is sufficient free memory available to run the critical path without invoking the GC. The latter is most suitable when the program can expect a certain amount of idle time, e.g. between frames. It should be a simple matter of determining how much memory is needed to render a frame and then adding a call to the GC just before going idle to free at least that much space for the next frame.
Realtime GC algorithms are rare, because they're not usually required and they tend to have more overhead. While Java has System.gc(), it's apparently not very well defined (could be anything from a no-op to a stop-the-world full GC pass), and JavaScript has no standardized control over the GC at all, probably for security reasons. The end result is that while GC response time is manageable in principle, applications written in the most popular GC languages are not provided with the necessary tools for the job.
|
|||||||||||||