By: RichardC (tich.delete@this.pobox.com), May 12, 2013 12:20 am
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on May 11, 2013 7:51 pm wrote:
> > Most desktops/laptops are most running web browsers and office apps
> > (word processing, spreadsheet etc). Which don't exploit many
> > threads very effectively, if at all.
>
> This argument can be criticized from two directions. First, there is some potential for "ordinary" applications
> to increase the use of threading. This could be made more probable with better tools and better software and
> hardware interfaces (which are at least being considered). Being able to spawn a thread with a cost similar
> to a function call would seem likely to significantly increase the potential utility of multithreading.
Better tools for parallel programming have been coming for decades. But they don't
solve the problem. And the problem gets worse as cpu cores get more complex and
faster at single-thread in-cache work - synchronization/locking primitives keep
getting more expensive relative to single-thread unsychronized operations.
> Second, support for SMT in particular would facilitate implementation of hardware speculative
> multithreading, so that in some cases even single-threaded code could have a performance boost
> from using the hardware infrastructure provided for software-managed multithreading.
Huh ?
> The flexibility of resource use and lower overhead communication makes SMT and fine-grained MT relatively
> attractive for short-duration thread spawning.
Usually a bad idea because a "short-duration thread" will not have what it needs
in L2/L1 cache, so will have low hit rate and will go slow. Successful threaded
apps are those which use coarse-grain parallelism and worry about cache locality.
> For budget-focused CPUs, dropping multithreading would seem to have more substantial benefits since the relative
> overhead in complexity and hardware resources would be greater. (However, I receive the impression that
> you are asking about high-performance, lowish-thread-count CPUs for performance sensitive workloads that
> do not substantially exploit multithreading.)
I would like my laptop and desktop to render webpages faster. That is
"performance-sensitive" if it ever takes more than 500mS or so.
> > Most desktops/laptops are most running web browsers and office apps
> > (word processing, spreadsheet etc). Which don't exploit many
> > threads very effectively, if at all.
>
> This argument can be criticized from two directions. First, there is some potential for "ordinary" applications
> to increase the use of threading. This could be made more probable with better tools and better software and
> hardware interfaces (which are at least being considered). Being able to spawn a thread with a cost similar
> to a function call would seem likely to significantly increase the potential utility of multithreading.
Better tools for parallel programming have been coming for decades. But they don't
solve the problem. And the problem gets worse as cpu cores get more complex and
faster at single-thread in-cache work - synchronization/locking primitives keep
getting more expensive relative to single-thread unsychronized operations.
> Second, support for SMT in particular would facilitate implementation of hardware speculative
> multithreading, so that in some cases even single-threaded code could have a performance boost
> from using the hardware infrastructure provided for software-managed multithreading.
Huh ?
> The flexibility of resource use and lower overhead communication makes SMT and fine-grained MT relatively
> attractive for short-duration thread spawning.
Usually a bad idea because a "short-duration thread" will not have what it needs
in L2/L1 cache, so will have low hit rate and will go slow. Successful threaded
apps are those which use coarse-grain parallelism and worry about cache locality.
> For budget-focused CPUs, dropping multithreading would seem to have more substantial benefits since the relative
> overhead in complexity and hardware resources would be greater. (However, I receive the impression that
> you are asking about high-performance, lowish-thread-count CPUs for performance sensitive workloads that
> do not substantially exploit multithreading.)
I would like my laptop and desktop to render webpages faster. That is
"performance-sensitive" if it ever takes more than 500mS or so.