Scalability issues

Steve is trying to download the blockchain on his Ubuntu 64 machine which runs up to 16 VMs and has 6 SATA 6gbs configured as RAID0 Drives and 32gb of RAM. He also mentions that he has never tried to download the blockchain on the master os. Steve has been doing extensive testing in this area and notes that he has an extensive setup of test machines, everything from e4300 to phenom2x6 to i5's. Steve asks Michael about a comment he made previously where he mentioned that he gets a full blockchain from scratch in 45 minutes on his laptop. Michael responds to Steve mentioning that it's numbers from March/April and it takes longer today but still far away from the 12 hours it takes for Steve. Michael mentions that he is using libcoin and the bitcoind build based on this and explains that libcoin uses a pure async concurrency model. Michael also stresses that these numbers will depend largely on the system running the test. Additionally, Michael asks Steve about his CPU load during a block download and mentions that the initial download is typically disk I/O bound while the verification stage is CPU-bound. Michael leans to believe that even there it is disk I/O bound. Michael quotes Dave Butenhof to explain how recursive mutexes encourage one to completely lose track of their locking scheme and scope, which is deadly.