Subj : Re: RCU+SMR To : comp.programming.threads From : Joe Seigh Date : Fri Jul 08 2005 01:30 pm Randy Howard wrote: > Joe Seigh wrote > (in article ): .... >>The other thing here is api's are a really hard sell. > > > True. That's why I was wondering about standardization. With > all the pushing for SMP, dual-core, multi-core, (and the > abomination known as "hyperthreading", you would think some of > the big names (like Intel and AMD) would be pushing for ways to > get the most out of new processor features and parallelism > without everyone having to roll their own. Intel and AMD are basically hardware companies and are run by hardware not software types. They know HPC (high performance computing) and parallel programming. Anything outside of that is pretty much alien to them. They also have a view on ROI (return on investment) that's hardware rather than software oriented. We're still running Cobol programs written in the 60's because it cost too much to rewrite them. Intel and AMD will stick an extension on just long enough to sell a few million processors and then drop it once they got their money back. So while you could do some really neat things with hyperthreading, no one will because it will be gone by the time the OSes could provide an api to exploit it. A good example of what you can do with hyperthreading is producer/consumer. One of the problems with consumer/producer is either the consumers or producers will get ahead of the other. In normal threading, you use condition variables to suspend one and resume it when the other catches up. That suspend and resume adds overhead. One of the things people try to avoid this is use lock-free but if you spin wait you're wasting cycles. With hyperthreading, the faster thread can just spin wait using the PAUSE instruction and the cpu resources are given to the other thread to make it run faster. As soon as it catches up, the waiting thread resumes again with no overhead. There is no way to do the equivalent in normal threading except to say that condition variables act that way sometimes except with more overhead. It's not just Intel and AMD. Sun Research has a whole group that does synchronization, mostly lock-free. But I have yet to see any evidence that Sun exploits any of this. And they're coming out with Niagara which will have up to 8 cores, 4 threads per core. You would think. > > Oh well, I guess it will be a long time before this sort of > thing is widely used enough to become more generally applicable > to portable software. > Well, a killer app will speed things up. But people expect bigger and more feature rich apps. It's not like the old days when you could write something from scratch in a few days or weeks. I was going to suggest to Intel that they list and sponsor projects that would benefit from being "parallelized" much like IBM and Google did with some projects. But I'm not sure they know what projects those would be. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. .