I was curious about the difference between multithreading and hyperthreading so I did a little digging. I've linked the article at the end of the post.
When a process forks it creates a copy of itself, in a mulithreading environment this means the thread is duplicated.
When I learned about multithreading in school I learned about temporal multithreading, this is where the processor gives a slice of time to each thread. Only one thread is ever running at any given time but the processor switches between threads so rapidly that it appears that the threads are running concurrently.
There have been some improvements.
There are 3 main ways to do multithreading:
1. coarse-grain (sometimes called block threading)
2. vertical
3. Simultaneous (Intel calls it hyperthreading, Sun calls it coolthreads)
Coarse-grain multithreading runs instructions on a thread until it comes across an instruction that is going to take a long time (like disk I/O for example), when this happens it switches to a different thread while it waits for the high latency task to complete. The disavantage of this type of multithreading is that all of the threads use the same instruction pipleline and when the processor switches to a different thread all of the instructions behind the high latency instruction are flushed.
Vertical threading (VT) and Simultaneous multithreading (SMT) do not suffer from the high cost of switching between threads. The difference between VT and SMT is that in a single CPU cycle a VT processor issues instructions on one thread and an SMT issues instructions on multiple threads.
Obviosly if an application isn't written to handle multiple threads there is little advantage to be gained from running on a multithreaded processor.
JB
Interesting. I was not aware of the types of threading implementations. I wonder what this means to the developer. As far as I can tell, we go on creating multi-threaded apps as normal and let the proc do its thing (using whichever type of multi-threading it uses).
ReplyDeleteSomewhat related. Here's a trick we learned from a JavaOne conference a couple years ago.
ReplyDeleteLogging causes disk IO and if you have a several threads logging a lot they end up wasting time waiting for each other for disk access.
To get better performance from this, we dedicated a thread specifically to logging. Log requests queue up and the dedicated thread is scheduled to run every second and dump whatever is queued in one big batch.
Wow, nice one shaler!
ReplyDelete