Transcript of presentation plus my comments in blue.
Computing models have to evolve with new pressures:
- many tiny devices – low powered, cheaper, but not faster
- many little flakey data centers (put on a truck and drive away) … we are not seeing this. The reasons is clear: the technology proposed in this talk is not easy to build.
Forces in Processors
Moore’s Law continues – number of transitors doubles every two years, but the voltages isn’t dropping as fast. This is because the high-end chips have huge power consumption.
Why isn’t the CPU frequency getting a lot faster? Pat spent a week reading up. The hardware guys call “the power wall”. “Static Power” is consuming half of the power – reason: as transistors get smaller, they leak. Current technology that’s just about to emerge is 45 nm. When Pat graduated, they were working on 6 micron. Soon we are moving to 32 nm technology. As frequency goes up, the dynamic power goes up; As dynamic power goes up, chip gets hotter; As chip gets hotter, the leakage goes up! The hardware guys are fighting year after year against this. Hence, frequencies aren’t going to get much faster. Maybe 10%. But the chips will get a lot hotter.
Memory wall – access time to DRAM remains essentially flat. We’re getting more bandwidth to DRAM but not lower latencies. Chips may be faster but time to read memory isn’t becoming faster. Speculative execution in CPU is bringing execution into cache before it’s executed (out of order). This is five times as complicated. In-order CPU is cheaper in terms of transistor and power use.
Hardware will be moving to 500 processors on a single chip. But software guys don’t really know what to do. We are not ready.
Many-Core – On-chip shared memory. So we don’t have to go to DRAM (which is slower).
Forces in the Data Center
Computers are relatively cheap. Power is 40% of cost of running data center. Building shell represents 15%. Most buildings have a lot of empty room because they are limited by power. Reducing power means more computing capacity, less cooling, less battery backup and less diesel power generator back up.
e.g. Sun is selling premanufactured shipping container fitted out with computers – far more space, heat and power efficient. Just hook in chilled water and high voltage power. Expect to lose processors, let them fail in place. Just ship out the container after a few years.
Don’t use back up power. Just use many data centers.
This is only going to work when data is distributed between many data centers. OK, Google already does this, but then it’s a free service, and makes no promises about data consistency. Search results will vary from data center to data center.
Low End Devices
Cheap computer at 1 Watt. Increasingly stateful – holding partitioned data.
Pressures on Storage
The amount of time it takes to read and write on disks is getting longer. Jim Gray explained to Pat that capacity increases with areal density, but read/write time with linear density. 10 TB disk will take 5-15 hours to read sequentially but 15-150 days to read randomly.
“Disk is Tape” - we have to treat disks as cold storage. No offsite media.
“Flash is Disk” – Flash is getting cheaper because of phones, cameras. Flash will replace disk. The IO per GB of flash remains about 200 compared to 4 on SCSI disks. By 2012, flash will cost the same as SCSI. Furthermore, flash runs cool.
All this is true, but I can’t see how this would change the way we would write software.
Bandwidth and Latency
We are getting more bandwidth but latency is limited by the speed of light.
Data Center to Data Center have a special backbone, which is very fast. Total bandwidth triples every twelve months. Faster than Moore’s Law!
As bandwidth gets cheaper, it’s growing at a rate faster than Moore’s Law. The users are getting charged on the peak usage. There’s spare capacity (free) available between the peaks. [Chui: what can we do with those, background transfer of back up information, synchronization ?]
Wireless is increasingly available. But there are still dead spots. We still need to see offline behavior.
Increasing LAN, Increasing WAN, Increasing Wireless … Increasing Expectations!
Forces in the Cloud
Runs video showing how useful separating application state from the machine.
Need to have:
- per-user-per-app state, the browser does this.
- controlled sharing across applications, safely [Chui: see BitFrost on OLPC]
Kinds of Parallelism
Pipelined parallelism – [Chui: like unix pipes, or python generators]
To compute faster, we have to bring the data closer. i.e. waiting for DRAM is slow, waiting for network is slow, waiting while offline is slow. We have to make copies of data close by. [Chui: Is the the answer to Joel's architecture astronauts?]
Get used to the idea of not knowing what is truth. Gone is assurance of data consistency, since data hasn’t synchronized yet.
Pat had thought back in 1995 that internet was going to fail because the internet wasn’t transactionally consistent. But turns out people were prepared to accept the lack of consistency.
We need to
- admit we’re confused – computers only have partial knowledge. They are separated from the real world, and separated from other replicas – so make guesses, but there’s no certainty in computing.
- If there’s no data consistency, then it’s possible to be decisive at the cost of making mistakes. I think it’s time to start annotating database tables or columns with this kind of rule relaxation for better partitionability.
- Smaller computers
- Smaller data centers
- Smaller data sets – small independent pieces of data
Transactions will be different. You will be doing transactions on a few unique objects, and server will move the current object all to the same machine.
Subjective consistency – be decisive before you can have all up to date information. Ambassadors had to do this hundreds of years ago! Eventual consistency when getting updated data. Make another decision this time.
C.A.P. rule – Consistency, Availability, Partitionability … pick two out of three. Pat argued that people want to relax the business rules in order to have lower power, more disconnectivity, etc.