Linked by Thom Holwerda on Tue 19th Dec 2017 19:22 UTC
Android

Today, we are excited to announce Quick Boot for the Android Emulator. With Quick Boot, you can launch the Android Emulator in under 6 seconds. Quick Boot works by snapshotting an emulator session so you can reload in seconds. Quick Boot was first released with Android Studio 3.0 in the canary update channel and we are excited to release the feature as a stable update today.

There's a quite a few other improvements and new features, as well.

Thread beginning with comment 652251
To view parent comment, click here.
To read all comments associated with this story, please click here.
gilboa
Member since:
2005-07-06

Your comparison is invalid on three counts.

A. Kernel boot time has nothing to do with storage performance and has everything to do with the complexity of you call a "PC". While the C64 had very limited set of devices that were initialized from ROM, a modern kernel needs to support 1000 upon 1000 of CPU types, chipsets, devices, etc. Most of them with unbelievably complex initialization sequence. If you don't believe me look at the driver source code of modern GPUs or 25/40/100 GbE network devices.

B. The amount of optimization that goes into the kernel these days is million miles ahead of type-a-couple-of-1000s-of-ASM-LOC and shove them into a ROM that was used to design the C64.

C. Same goes for file systems, system services, network services, etc.

D. That said, you are completely correct when it comes to user facing applications (GUI, web applications, business applications, etc).

- Gilboa

Edited 2017-12-20 18:37 UTC

Reply Parent Score: 3

cybergorf Member since:
2008-06-30

Your comparison is invalid on three counts.

D. That said, you are completely correct when it comes to user facing applications (GUI, web applications, business applications, etc).

- Gilboa


Well in this case it is D: the android emulator is a user facing application.

Reply Parent Score: 1

gilboa Member since:
2005-07-06

... He was talking about PC vs. C64.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

gilboa,

Your comparison is invalid on three counts.

A. Kernel boot time has nothing to do with storage performance and has everything to do with the complexity of you call a "PC". While the C64 had very limited set of devices that were initialized from ROM, a modern kernel needs to support 1000 upon 1000 of CPU types, chipsets, devices, etc. Most of them with unbelievably complex initialization sequence. If you don't believe me look at the driver source code of modern GPUs or 25/40/100 GbE network devices.


In all honestly most of the complexity is bloat. Even linus torvalds has acknwoledged linux has a bloat problem. Android is tuned for very specific hardware. If the kernel on your android phone does "support 1000 upon 1000 of CPU types, chipsets, devices, etc.", then whoever built it did a pretty bad job in trimming it down to only the hardware present on the device. Know what I mean? The build it supposed to be optimized for that specific hardware.

B. The amount of optimization that goes into the kernel these days is million miles ahead of type-a-couple-of-1000s-of-ASM-LOC and shove them into a ROM that was used to design the C64.


Arguably not true by performance per clock...

C. Same goes for file systems, system services, network services, etc.


Sure, but it doesn't explain why the overhead is so much greater.

D. That said, you are completely correct when it comes to user facing applications (GUI, web applications, business applications, etc).

- Gilboa


IMHO it's true of most code.

Reply Parent Score: 1

gilboa Member since:
2005-07-06

In all honestly most of the complexity is bloat. Even linus torvalds has acknwoledged linux has a bloat problem. Android is tuned for very specific hardware. If the kernel on your android phone does "support 1000 upon 1000 of CPU types, chipsets, devices, etc.", then whoever built it did a pretty bad job in trimming it down to only the hardware present on the device. Know what I mean? The build it supposed to be optimized for that specific hardware.


The OP in this sub thread was comparing C64 to a PC. He wasn't talking about Android, nor was I.


Arguably not true by performance per clock...


Actually, The amount of rows/sec PostgreSQL -on- Linux can store or index is billion years a head of any database that existed in the C64 or even the early PC days. Even if you generate odd matrices such as rows/sec per Mhz or rows/second per disk RPM, the performance difference is simply staggering.
Same goes for networking (packets/sec per Mhz) and graphics (triangles/sec per Mhz).


Sure, but it doesn't explain why the overhead is so much greater.


Sure it does.
Back in the C64 or even in the XT days, a graphics card was nothing more than a dual ported memory chip.
Today a graphics card is a hugh-SMP CPU that's expected to push billions of vertices and handle complex requests simultaneously. How can you possibly expect to continue program such a beast by calling 'int 10h'?

Networking is no different. How can you possibly compare a C64 modem that was barely cable of pushing 1200bps via the simplest of interfaces (serial port) to a multi-PCI-E 100GbE network device that includes smart buffering, packet filtering and load-balancing?


IMHO it's true of most code.


Being a system developer I can't say that I care much for user facing code ;)

- Gilboa

Edited 2017-12-21 13:22 UTC

Reply Parent Score: 4