What are we going to do with 16 cores? Over clockable, 192-bit DDR3-1333
and DDR2-1600 memory. Their are cooling solutions that will take the IC
down to -100 degrees Celsius.
From what I have read, Windows does not scale well above 4 cores. New
languages will have to be perfected to take advantage of so many cores.
Re: Intel comming out with a 16 core Nehalem family.
And over-clocking and extreme cooling only go so far. Just because you
double the clock rate doesn't mean you get double the performance. Different
parts of the cpu scale differently, and when Intel pushed the P4 up to
3.8GHz, they had to push the pipeline out to about 31 stages. It gave them
bragging rights, but it didn't perform anywhere near as well as people
thought it did. A clock cycle can only propagate so fast through the core,
no matter how cold the core is, which is why cooling and clock speed will in
the end give limited gains.
Since we can't get much faster and we can't get much smaller, one of the
pathways still open is multi coring. Microsoft wants to make drastic changes
to the OS such that each app will run on it's own core with part of the OS
embedded into the app. Instead of 2 or 3 high powered cores, we will have
dozens of slower cores, each with their own tasks to do.
Consider also that they applications of the future will be more suited to
milti threaded and multi processing systems. Multi cores is the future.
"William" <nospam@pacifier.com> wrote in message
news:k9GdnUNuI9BzQtXVnZ2dnUVZ_trinZ2d@posted.palin acquisition...
> Lots of new stuff being announced out of Taipei Taiwan lately. See:
> http://www.tgdaily.com/content/view/37824/135/
>
>
> What are we going to do with 16 cores? Over clockable, 192-bit DDR3-1333
> and DDR2-1600 memory. Their are cooling solutions that will take the IC
> down to -100 degrees Celsius.
>
> From what I have read, Windows does not scale well above 4 cores. New
> languages will have to be perfected to take advantage of so many cores.
>
> Interesting times.
>
> William
>
Re: Intel comming out with a 16 core Nehalem family.
"Zootal" <giganews@zootal.nospam.com> wrote in message news:FradnZOLvbL9WdfVnZ2dnUVZ_hCdnZ2d@giganews.com ...
> And over-clocking and extreme cooling only go so far. Just because you
> double the clock rate doesn't mean you get double the performance. Different
> parts of the cpu scale differently, and when Intel pushed the P4 up to
> 3.8GHz, they had to push the pipeline out to about 31 stages. It gave them
> bragging rights, but it didn't perform anywhere near as well as people
> thought it did. A clock cycle can only propagate so fast through the core,
> no matter how cold the core is, which is why cooling and clock speed will in
> the end give limited gains.
>
> Since we can't get much faster and we can't get much smaller, one of the
> pathways still open is multi coring. Microsoft wants to make drastic changes
> to the OS such that each app will run on it's own core with part of the OS
> embedded into the app. Instead of 2 or 3 high powered cores, we will have
> dozens of slower cores, each with their own tasks to do.
>
> Consider also that they applications of the future will be more suited to
> milti threaded and multi processing systems. Multi cores is the future.
That sounds great for servers and other heavy multitasking, but
"part of the OS embedded into the app" doesn't make any sense.
An OS function by definition may be required and used
(potentially) by any or all apps running under a given OS, and
having a function (e.g. print spooling) embedded in an app,
with possibly more than one version of a function existing on the
same system, would be a logistical nightmare for SW developers.
Re: Intel comming out with a 16 core Nehalem family.
> That sounds great for servers and other heavy multitasking, but
> "part of the OS embedded into the app" doesn't make any sense.
> An OS function by definition may be required and used
> (potentially) by any or all apps running under a given OS, and
> having a function (e.g. print spooling) embedded in an app,
> with possibly more than one version of a function existing on the
> same system, would be a logistical nightmare for SW developers.
>
I think that the line between a traditional OS function and the application
is not quite so black and white. If running a specific app is all a core
does, then there is a vague line between the app and the OS, and certain OS
functionality can be embedded into the app. For example, since the app has
exclusive access to the cpu, it could utilize it's own cpu scheduler running
in its own memory space using it's own scheduling algorithm instead of being
dependent on some main OS. If the job of a certain core is to exclusively
talk to certain i/o devices, then the core would have it's own i/o scheduler
running in its own space.
A few weeks ago I saw plans for a 256 core cpu. How do you get 256 cores to
talk to each other, and fast? One researcher I met is working on using
wireless technology, and sticking small antennaes above the cpu. Yeah,
sounds weird, but with that many cores, you have to get pretty exotic and
think outside of the box. Huge multi core cpus won't be anything like what
we are used to today.
Todays technology does not scale up to hundreds of cores. Going massively
multi core is a major paradigm change, and I'm curious as to how we are
going to do it.
Re: Intel comming out with a 16 core Nehalem family.
"Zootal" <giganews@zootal.nospam.com> wrote in message
news:UuKdnW1hzd2dpdbVnZ2dnUVZ_gSdnZ2d@giganews.com ...
>> That sounds great for servers and other heavy multitasking, but
>> "part of the OS embedded into the app" doesn't make any sense.
>> An OS function by definition may be required and used
>> (potentially) by any or all apps running under a given OS, and
>> having a function (e.g. print spooling) embedded in an app,
>> with possibly more than one version of a function existing on the
>> same system, would be a logistical nightmare for SW developers.
>>
>
> I think that the line between a traditional OS function and the
> application is not quite so black and white. If running a specific app is
> all a core does, then there is a vague line between the app and the OS,
> and certain OS functionality can be embedded into the app. For example,
> since the app has exclusive access to the cpu, it could utilize it's own
> cpu scheduler running in its own memory space using it's own scheduling
> algorithm instead of being dependent on some main OS. If the job of a
> certain core is to exclusively talk to certain i/o devices, then the core
> would have it's own i/o scheduler running in its own space.
>
> A few weeks ago I saw plans for a 256 core cpu. How do you get 256 cores
> to talk to each other, and fast? One researcher I met is working on using
> wireless technology, and sticking small antennaes above the cpu. Yeah,
> sounds weird, but with that many cores, you have to get pretty exotic and
> think outside of the box. Huge multi core cpus won't be anything like what
> we are used to today.
>
> Todays technology does not scale up to hundreds of cores. Going massively
> multi core is a major paradigm change, and I'm curious as to how we are
> going to do it.
>
Zootal:
I think your analysis is spot on. It is amazing that the speed of an
electron down a piece of silicone or a piece of wire is becoming such a
bottle neck. (What is it, ~1.5" per ns.) I believe in the near future we
will see the integration of laser - optic I/O on our cpu's to improve
communications and throughput between cpu, I/O and whatever.
I especially agree with the dedicated core for specific tasks, such as
speech recognization and synthesization, i/o and any other identifiable
repeatable process. Many will be identified and tailored to a specific core
as you have described.
Do you think that future cpu's will become cubes, one core or more, stacked
ontop of another to conserve in distance between cores for communications?
Re: Intel comming out with a 16 core Nehalem family.
"William" <nospam@pacifier.com> wrote in message
newsvKdnewcg4QI39bVnZ2dnUVZ_s7inZ2d@posted.palin acquisition...
>
> "Zootal" <giganews@zootal.nospam.com> wrote in message
> news:UuKdnW1hzd2dpdbVnZ2dnUVZ_gSdnZ2d@giganews.com ...
>>> That sounds great for servers and other heavy multitasking, but
>>> "part of the OS embedded into the app" doesn't make any sense.
>>> An OS function by definition may be required and used
>>> (potentially) by any or all apps running under a given OS, and
>>> having a function (e.g. print spooling) embedded in an app,
>>> with possibly more than one version of a function existing on the
>>> same system, would be a logistical nightmare for SW developers.
>>>
>>
>> I think that the line between a traditional OS function and the
>> application is not quite so black and white. If running a specific app is
>> all a core does, then there is a vague line between the app and the OS,
>> and certain OS functionality can be embedded into the app. For example,
>> since the app has exclusive access to the cpu, it could utilize it's own
>> cpu scheduler running in its own memory space using it's own scheduling
>> algorithm instead of being dependent on some main OS. If the job of a
>> certain core is to exclusively talk to certain i/o devices, then the core
>> would have it's own i/o scheduler running in its own space.
>>
>> A few weeks ago I saw plans for a 256 core cpu. How do you get 256 cores
>> to talk to each other, and fast? One researcher I met is working on using
>> wireless technology, and sticking small antennaes above the cpu. Yeah,
>> sounds weird, but with that many cores, you have to get pretty exotic and
>> think outside of the box. Huge multi core cpus won't be anything like
>> what we are used to today.
>>
>> Todays technology does not scale up to hundreds of cores. Going massively
>> multi core is a major paradigm change, and I'm curious as to how we are
>> going to do it.
>>
>
> Zootal:
>
> I think your analysis is spot on. It is amazing that the speed of an
> electron down a piece of silicone or a piece of wire is becoming such a
> bottle neck. (What is it, ~1.5" per ns.) I believe in the near future we
> will see the integration of laser - optic I/O on our cpu's to improve
> communications and throughput between cpu, I/O and whatever.
>
> I especially agree with the dedicated core for specific tasks, such as
> speech recognization and synthesization, i/o and any other identifiable
> repeatable process. Many will be identified and tailored to a specific
> core as you have described.
>
> Do you think that future cpu's will become cubes, one core or more,
> stacked ontop of another to conserve in distance between cores for
> communications?
>
> William
I'm not sure about the stacking of cores - makes you wonder why it's not
being done already? My guess is heat dissapation. One side of the slab is
for heat dissapation, and the other side is for pins. I can see how it would
be difficult to put slabs together. If you could come up with some exotic
cooling - superconductor cooling, for example - then you could make 3d
arrays of cores. Imagine an 8x8x8 array of cores? Instead a flat 8x8 slab
with 64 cores, imagine building a cube with 512 cores in it? Woooooo....
Another problem is that once the signal leaves the silicon, you loose
massive amounts of bandwidth. Physically bolting cpus together is very slow.
The wireless inter-core communication is designed to overcome part of that
challenge. Another option would be to use optical routers and pipes between
the cores, so you don't have the loss associated with physical wiring
connecting cores.
Maybe the cpu of the future will be a cube with exotic cooling and
laser/optical routers and pipes for core to core communication?
Re: Intel comming out with a 16 core Nehalem family.
On Thu, 5 Jun 2008 23:57:49 -0700, "William" <nospam@pacifier.com>
wrote:
>Lots of new stuff being announced out of Taipei Taiwan lately. See:
>http://www.tgdaily.com/content/view/37824/135/
>
>
>What are we going to do with 16 cores? Over clockable, 192-bit DDR3-1333
>and DDR2-1600 memory. Their are cooling solutions that will take the IC
>down to -100 degrees Celsius.
>
>From what I have read, Windows does not scale well above 4 cores. New
>languages will have to be perfected to take advantage of so many cores.
Re: Intel comming out with a 16 core Nehalem family.
"Andrew Hamilton" <Ahamilton90900@yahoo.com> wrote in message
news:nu8o44huvd0aptu28avs3bvmotbqru9dl7@4ax.com...
> On Thu, 5 Jun 2008 23:57:49 -0700, "William" <nospam@pacifier.com>
> wrote:
>
>>Lots of new stuff being announced out of Taipei Taiwan lately. See:
>>http://www.tgdaily.com/content/view/37824/135/
>>
>>
>>What are we going to do with 16 cores? Over clockable, 192-bit DDR3-1333
>>and DDR2-1600 memory. Their are cooling solutions that will take the IC
>>down to -100 degrees Celsius.
>>
>>From what I have read, Windows does not scale well above 4 cores. New
>>languages will have to be perfected to take advantage of so many cores.
>
> Solaris/X86. Linux.
>
> -AH
The linux 2.6 kernel has a lot of smp improvements - seperate read and write
spin locks, seperate request queues for each cpu, etc., - but it really
wasn't made with massive multi cores in mind, and can choke depending on
what you do. Not sure about Solaris - the sparc processor itself is somewhat
limited, but IIRC the OS scales up nicely to relatively large numbers of
cores.
It's not the languages that need perfecting - it's more of a change, not a
perfection. Most developers think single thread, and
multithreading/multiprocessing is a difficult concept for many of them. I've
worked as a programmer for 20 years, and I've met more then my share of
stupid programmers. Half of the people that call themselves programmers
should never be allowed to touch a keyboard :P
Re: Intel comming out with a 16 core Nehalem family.
"Zootal" <giganews@zootal.nospam.com> wrote in message news:UuKdnW1hzd2dpdbVnZ2dnUVZ_gSdnZ2d@giganews.com ...
> > That sounds great for servers and other heavy multitasking, but
> > "part of the OS embedded into the app" doesn't make any sense.
> > An OS function by definition may be required and used
> > (potentially) by any or all apps running under a given OS, and
> > having a function (e.g. print spooling) embedded in an app,
> > with possibly more than one version of a function existing on the
> > same system, would be a logistical nightmare for SW developers.
> >
>
> I think that the line between a traditional OS function and the application
> is not quite so black and white. If running a specific app is all a core
> does, then there is a vague line between the app and the OS, and certain OS
> functionality can be embedded into the app. For example, since the app has
> exclusive access to the cpu, it could utilize it's own cpu scheduler running
> in its own memory space using it's own scheduling algorithm instead of being
> dependent on some main OS. If the job of a certain core is to exclusively
> talk to certain i/o devices, then the core would have it's own i/o scheduler
> running in its own space.
Yes, but the app and cpu (and scheduler in your example) are still
required to work under the rules and constraints of the OS. The point
is, whatever functions an app embeds are by definition not part or no
longer part of the OS. It's one or the other, and for good reason.
Intel comming out with a 16 core Nehalem family. 
vKdnewcg4QI39bVnZ2dnUVZ_s7inZ2d@posted.palin acquisition...
Linear Mode
