Showing posts with label Hardware. Show all posts
Showing posts with label Hardware. Show all posts

Saturday, December 1, 2012

Intel’s Haswell is an unprecedented threat to Nvidia, AMD

http://www.extremetech.com/computing/136219-intels-haswell-is-an-unprecedented-threat-to-nvidia-amd

Transactional Synchronization eXtensions

Transactional Synchronization eXtensions (TSX) extend the x86 ISA with two new interfaces: HLE and RTM.

Restricted Transactional Memory (RTM) uses Xbegin and Xend, allowing developers to mark the start and end of a critical section. The CPU will thread this piece of code as an atomic transaction. Xbegin also specifies a fall back path in case the transaction fails. Either everything goes well and the code runs without any lock, or the shared variable(s) that the thread is working on is overwritten. In that case, the code is aborted and the transaction has failed. The CPU will now execute the fall back path, which is most likely a piece of code that does coarse grained locking. RTM enabled software will only run on Haswell and is thus not backwards compatible, so it might take a while before this form of Hardware Transactional Memory is adopted.


The most interesting interface in the short term is Hardware Lock Elision or HLE. It first appeared in a paper by Ravi Rajwar and James Goodman in 2001. Ravi is now a CPU architect at Intel and presented TSX together with his colleague Martin Dixon TSX at IDF2012.
The idea is to remove the locks and let the CPU worry about consistency. Instead of assuming that a thread should always protect the shared data from other threads, you optimistically assume that the other threads will not overwrite the variables that the thread is working on (in the critical section). If another thread overwrites one of those shared variables anyway, the whole process will be aborted by the CPU, and the transaction will be re-executed but with a traditional lock.
If the lock removing or elision is successful, all threads can work in parallel. If not, you fall back to traditional locking. So the developer can use coarse grained locking (for example locking the entire shared structure) as a "fall back" solution, while Lock Elision can give the performance that software with a well tuned fine grained locking library would get.

According to Ravi and Martin, the beauty is that the developer of your locking libraries simply has to add a few HLE instructions without breaking backwards compatibility. The developer uses the new TSX enabled library and gets the benefits of TSX if his application is run on Haswell or a later Intel CPU.

Wondered why Amazon ec2 virtual machine instances were so fast?

Read an article that said that they used Xen Hypervisor
http://www.codinghorror.com/blog/2006/05/virtualization-and-ring-negative-one.html
 
Take a look at Xen. It's interesting because it offers better performance than traditional
virtualisation systems by modifying both host OS and guest OS. It's really interesting to learn about
its optimisation techniques.
http://download.intel.com/design/intarch/PAPERS/325258.pdf
http://www.codinghorror.com/blog/2006/10/the-single-most-important-virtual-machine-performance-tip.html
http://www.codinghorror.com/blog/2005/02/virtual-pc-2004-tips.html
http://searchservervirtualization.techtarget.com/feature/Xen-vs-KVM-Linux-virtualization-hypervisors
Apparently KVM is going to be the upcoming technology.

Hypervisor and does the guest os run in protected mode?



Seems it does and they are different levels of protected mode, 0 for the kernel and 3 for applications.
Intel and AMD both implement different ways to support virtualization, one way has a protection level of -1.

http://en.wikipedia.org/wiki/Ring_(computer_security)

Monday, November 5, 2012