Re: Intel details future Larrabee graphics chip



On a sunny day (Thu, 07 Aug 2008 07:08:52 -0700) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<d10m94d7etb6sfcem3hmdl3hk8qnels3kg@xxxxxxx>:

Been there - done that :-)

That is precisely how the early SMP systems worked, and it works
for dinky little SMP systems of 4-8 cores. But the kernel becomes
the bottleneck for many workloads even on those, and it doesn't
scale to large numbers of cores. So you HAVE to multi-thread the
kernel.

Why? All it has to do is grant run permissions and look at the big
picture. It certainly wouldn't do I/O or networking or file
management. If memory allocation becomes a burden, it can set up four
(or fourteen) memory-allocation cores and let them do the crunching.
Why multi-thread *anything* when hundreds or thousands of CPUs are
available?

Using multicore properly will require undoing about 60 years of
thinking, 60 years of believing that CPUs are expensive.

John

Ah, and this all reminds me about when 'object oriented programming' was going to
change everything.
It did lead to such language disasters as C++ (and of course MS went for it),
where the compiler writers at one time did not even know how to implement things.
Now the next big thing is 'think an object for every core' LOL.
Days of future wasted.
All the little things have to communicate and deliver data at the right time to the right place.
Sounds a bit like Intel made a bigger version of Cell.
And Cell is a beast to program (for optimum speed).
Maybe it will work for graphics, as things are sort of fixed, like to see real numbers though.
Couple of PS3s together make great rendering, there is a demo on youtube.




.



Relevant Pages

  • Re: Intel details future Larrabee graphics chip
    ... That is precisely how the early SMP systems worked, ... for dinky little SMP systems of 4-8 cores. ... Why multi-thread *anything* when hundreds or thousands of CPUs are ... Sounds a bit like Intel made a bigger version of Cell. ...
    (sci.electronics.design)
  • Re: [Bugme-new] [Bug 12562] New: High overhead while switching or synchronizing threads on diffe
    ... High overhead while switching or synchronizing threads ... Component: Scheduler ... Is there a known good kernel? ... different cores for some reason. ...
    (Linux-Kernel)
  • Re: [9fans] Plan 9 and multicores/parallelism/concurrency?
    ... 100s of cores per die. ... much any sophisticated scheduling. ... not sure thread placement belongs in the kernel. ... that lets me deal with affinitizing 3 resources that run at different ...
    (comp.os.plan9)
  • Re: Intel details future Larrabee graphics chip
    ... That is precisely how the early SMP systems worked, ... for dinky little SMP systems of 4-8 cores. ... and this all reminds me about when 'object oriented programming' was going to ... Sounds a bit like Intel made a bigger version of Cell. ...
    (sci.electronics.design)
  • Re: Possible bug from kernel 2.6.22 and above
    ... We have a simple pthread program that measures the synchronization overheads for various synchronization mechanisms such as spin locks, barriers and so on. ... We have dual quad-core AMD opterons clusters running 2.6.23.8 kernel at this moment using Fedora Core 7 distribution. ... Can the scheduler move threads to different cores according to the load balance algorithm even though the threads are bound to cores using pthread_setaffinity_np call when the number of threads is fewer than the number of cores? ... But the synchronization overhead actually decreases as the number of threads increases in the kernel 2.6.23.8. ...
    (Linux-Kernel)