| Author |
Message |
Nick Maclaren
Guest
|
 Posted:
Fri Dec 24, 2004 1:09 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
In article <FoDyd.24308$uM5.12641@bgtnsc05-news.ops.worldnet.att.net>,
Stephen Fuld <s.fuld@PleaseRemove.att.net> wrote:
| Quote: |
Yes. But outside of your world (HPC), I wonder what percentage of threads
require any FP/graphics stuff. I suspect it is a minority. I could see a
chip designed for say a database server, with a few FP capable cores and a
lot more non-fp capable cores.
Nowadays, almost all - it is often used in libraries and for other
purposes where it avoids the need for complicated fixed-point code.
Wow, I'm surprised. Can you give some examples of common routines that
coulde be expected to be used by most threads that use FP and for what
specific purpose?
|
Things like formatted I/O, space calculations, the ability to manipulate
timespec values simply, a simple and clean way of handling large file
sizes and so on. A second and equally common use is to provide the
integer division and remainder operations/functions on a system that
does not have them in hardware.
A program needs to call only one library that does one of those things
to need floating-point.
Regards,
Nick Maclaren. |
|
| Back to top |
|
 |
del cecchi
Guest
|
| Posted:
Sun Dec 26, 2004 7:55 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
"Sander Vesik" <sander@haldjas.folklore.ee> wrote in message
news:1103747119.796784@haldjas.folklore.ee...
| Quote: | Stephen Fuld <s.fuld@pleaseremove.att.net> wrote:
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:cq73uj$79g$1@gemini.csx.cam.ac.uk...
In article
q3Exd.1129653$Gx4.891539@bgtnsc04-news.ops.worldnet.att.net>,
"Stephen Fuld" <s.fuld@PleaseRemove.att.net> writes:
|
|> > For example, half might be strictly in-order, with really
slow
|> > floating-point, graphics and other gizmos, but with support
for
|> > access to hardware devices, the specialised and privileged
I/O
|> > and other instructions and so on.
|
|> I wonder how much die area one would save by doing this? Is it
really
|> significant? ...
I doubt it, but that's not where the gain would be. The real gain
would be that you could abandon perfect interruptability on the
other cores, which could considerably simplify performance (as
usual, depending on a lot of things). And, by supporting only
in-order execution, you make some of the nastier kernel
interactions
a LOT simpler.
One point is that trying to be all things to all men is hard to
get
right, and a second is that you don't need to have different ISAs
to have two simpler designs. The ability to switch the
unspecialised
threads also means that you get the efficiency of having a uniform
design.
But if the two types of cores had differences in handling precision
of
interrupts, etc. could you switch between the two types arbitrarily?
If you
expected precision interrupts, were executing on a core without them
and got
one, couldn't that cause problems for you?
Not arbitrarily - you would run parts of the kernel on one set of them
and everything else on the others.
--
To inject a note of reality here, if you have two different cores you |
have twice as much design and verification work to do. And having code
that only runs on a particular flavor of core makes additional
bottlenecks possible. And it saves what? a few mm**2? Now if the
processors have radically different workloads, ie graphics or emulation
assist that's one thing. But designing two flavors just to save a buck
in manufacturing seems unlikely. Besides I would expect the software
folks to not be happy about it either.
del cecchi |
|
| Back to top |
|
|
Dan Koren
Guest
|
| Posted:
Sun Dec 26, 2004 7:55 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
"Stephen Fuld" <s.fuld@PleaseRemove.att.net> wrote in message
news:6zlyd.21131$uM5.19190@bgtnsc05-news.ops.worldnet.att.net...
| Quote: |
Not arbitrarily - you would run parts of the kernel on
one set of them and everything else on the others.
Sure. But if you were going to do that, the "kernel" cores
wouldn't need floating point nor fancy graphics instructions
at all, and we are back to my original proposal.
|
Not meaning to taunt you ;-) but if you're willing to
have dedicated silicon for the kernel, one might as
well put the kernel in silicon. Nowadays, compiling
C/C++ into silicon isn't that much harder than
compiling C/C++ into soft object files.
dk |
|
| Back to top |
|
|
Stephen Fuld
Guest
|
| Posted:
Sun Dec 26, 2004 4:15 pm Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
"Dan Koren" <dankoren@yahoo.com> wrote in message
news:41ce3e80$1@news.meer.net...
| Quote: |
"Stephen Fuld" <s.fuld@PleaseRemove.att.net> wrote in message
news:6zlyd.21131$uM5.19190@bgtnsc05-news.ops.worldnet.att.net...
Not arbitrarily - you would run parts of the kernel on
one set of them and everything else on the others.
Sure. But if you were going to do that, the "kernel" cores
wouldn't need floating point nor fancy graphics instructions
at all, and we are back to my original proposal.
Not meaning to taunt you ;-)
|
Not a problem. :-) But you have my intentions exactly backward. See below
| Quote: | but if you're willing to
have dedicated silicon for the kernel, one might as
well put the kernel in silicon. Nowadays, compiling
C/C++ into silicon isn't that much harder than
compiling C/C++ into soft object files.
|
I am not going to comment on the idea of putting the kernel into silicon
except to say that makes changes harder. But my original proposal was NOT
for a "kernel only" core, but for a core which had no floating point nor
enhanced graphics instructions in order to save die space in a many cored
system. I felt that many, and for some applications, the vast majority of
threads, even non kernel ones, could run on such cores. Nick made the point
about many "non-tradtional" uses of floating point in what one might assume
were integer-only threads (which still surprises me!), thus believeing that
my idea would not be useful. Sander was the one who suggested segregating
workload to different cores based on the kernel/non-kernel distinction.
--
- Stephen Fuld
e-mail address disguised to prevent spam |
|
| Back to top |
|
|
Guest
|
|
| Back to top |
|
|
Dan Koren
Guest
|
| Posted:
Mon Dec 27, 2004 12:52 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
<lynn@garlic.com> wrote in message
news:1104085135.842902.202030@z14g2000cwz.googlegroups.com...
| Quote: | Dan Koren wrote:
Not meaning to taunt you ;-) but if you're willing to
have dedicated silicon for the kernel, one might as
well put the kernel in silicon. Nowadays, compiling
C/C++ into silicon isn't that much harder than
compiling C/C++ into soft object files.
can you say i432?
|
No ;-) the real name was iAPX432!
You didn't seem to notice (or you
ignored it for the convenience of
having a pretext for pun) that
compiling a kernel into silicon
was not at all what the iAPX432
tried to do.
BTW I once interviewed for a job
on the iAPX432, which I did not
get since the interviewing crowd
obviously did not think I shared
enough of their religion! ;-)
dk |
|
| Back to top |
|
|
Guest
|
| Posted:
Mon Dec 27, 2004 6:08 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
Dan Koren wrote:
| Quote: | BTW I once interviewed for a job
on the iAPX432, which I did not
get since the interviewing crowd
obviously did not think I shared
enough of their religion! ;-)
|
i worked on putting critical pieces of vm operating system into
microcode on the 138/148. there was about 10:1 ratio of native engine
instructions to 370 instructgions ... and much of operating system type
code dropped into microcode instructions almost on a one-for-one basis
.... given 10:1 speedup ... and some cases were state save/restore could
be avoided ... more than 10:1 speedup. the feature was released as
ecps. The design constraints was that there was 6kbytes of micrcode
space available for the effort (so we were looking for approx. the
highest used 6kbytes worth of kernel instructions) ... a specific ecps
microcode posting
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
random additonnal posts mentioning microcode efforts
http://www.garlic.com/~lynn/subtopic.html#mcode
about the same time I was also working on a 5-way SMP ... where i had a
little more latitude in designing microcode features. I did a little
bit better effort of design a logical dispatch/scheduling metaphor for
abstracting execution of the multiple processors. I also got to do a
higher level abstraction for some of other common operating system
features to microcode. unfortunately this project called VAMPS was
canceled before the product shipped ... lots of random past posts
mentioning VAMPS and abstracting smp kernel support:
http://www.garlic.com/~lynn/subtopic.html#bounce
an issue here was that all of the machines loaded microcode from floppy
at power-up ... as opposed to having it etched in silicon and reguiring
physical stuff to be done to correct issues. a new floppy could be just
shipped out for corrections. minor digression ... floppy had been
invesnted by shugart originally for loading microcode into 370 disk
controllers ... but it came to be used also for loading microcode into
lots of other boxes ... lots of past misc. posts about work in bldg.
14&15, disk enginneering and product test labs:
http://www.garlic.com/~lynn/subtopic.html#disk
the sigops i432 presentation had a lot to say about difficulty they had
with complex operating system stuff embedded in silicon and the
problems with fab'ing new silicon (with fixes) and getting the new
generation of chips out into the running boxes. the smp abstraction
that they had done in i432 was similar to the earlier stuff that i had
done for VAMPS ... except if any problems showed up in VAMPS, i would
have had a much easier time correcting it by shipping out new floppy
disks.
This was done in the 138/148 ECPS case (and availability on follow-on
processors 4331 & 4341) ... not so much because of bugs found in ECPS
.... but because ECPS was so tightly tied to specific operating system
operation ... that sometimes you needed new ECPS load to go along with
newer kernel changes. The kernel did have work around being able to
query ECPS version load and disable specific ECPS features that were
incompatible with the executing kernel.
list of past i432 posts including in the previous post
http://www.garlic.com/~lynn/2004q.html#59 |
|
| Back to top |
|
|
Rupert Pigott
Guest
|
| Posted:
Mon Dec 27, 2004 8:30 pm Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
Stephen Fuld wrote:
| Quote: |
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:cq6lq6$760$1@gemini.csx.cam.ac.uk...
In article <cq6krv$av0$1@pcls4.std.com>,
Alex Colvin <alexc@TheWorld.com> writes:
|
|> >Once we get to say 32nm where 16 current cores could fit easily on a
chip,
|> >would they even execute the same ISA? Perhaps there'd be a few that
|> >execute Java or .NET bytecode directly, a couple that do vector FP
|> >(or
|> >heck, IA-64), a few traditional cores, and an idiot convention? OK,
hell
|> >to debug so probably not, but I see no reason for them all to be
identical
|> >once you get beyond four.
|
|> So whatever ISA my code is, I can only use part of the chip?
Not necessarily. All the cores could support the same ISA, but
be optimised differently. The following is something I suggested
a long time ago:
For example, half might be strictly in-order, with really slow
floating-point, graphics and other gizmos, but with support for
access to hardware devices, the specialised and privileged I/O
and other instructions and so on.
I wonder how much die area one would save by doing this? Is it really
significant? How about some of the cores eliminating the floating point
and
graphics instructions totally. These could execute any kernal thread and
the the compiler/linker could mark user programs that were OK to run on
the
"reduced instruction set" cores. Of course the OS would have to handle
the
scheduling a little more carefully, but not to big a deal. Many simple
|
Do the usual routine. Trap on unsupported instruction and instead of
emulating the instruction in software simply reschedule the process
to a core that can handle it. For extra points tag the binary in some
way so the OS knows what it's requirements are next time. :)
Cheers,
Rupert
--
Threading sequential code through the eye of a parallel needle
makes little sense. ;) |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Mon Dec 27, 2004 9:24 pm Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
Stephen Fuld wrote:
| Quote: | I am not going to comment on the idea of putting the kernel into silicon
except to say that makes changes harder. But my original proposal was NOT
for a "kernel only" core, but for a core which had no floating point nor
enhanced graphics instructions in order to save die space in a many cored
system. I felt that many, and for some applications, the vast majority of
threads, even non kernel ones, could run on such cores. Nick made the point
about many "non-tradtional" uses of floating point in what one might assume
were integer-only threads (which still surprises me!), thus believeing that
my idea would not be useful. Sander was the one who suggested segregating
workload to different cores based on the kernel/non-kernel distinction.
|
One example:
Until relatively recently (i.e. some years ago) ntp (which works with
unsigned 64-bit values for all timestamps) used nothing but 32-bit
unsigned math for all operations.
Converting all the FLL/PLL operations to fp made the code much simpler
and easier to maintain, so now only the offsets are calculated exactly,
then immediately converted to fp.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Stephen Fuld
Guest
|
| Posted:
Mon Dec 27, 2004 9:55 pm Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:cqpd0s$el1$1@osl016lin.hda.hydro.com...
| Quote: | Stephen Fuld wrote:
I am not going to comment on the idea of putting the kernel into silicon
except to say that makes changes harder. But my original proposal was
NOT for a "kernel only" core, but for a core which had no floating point
nor enhanced graphics instructions in order to save die space in a many
cored system. I felt that many, and for some applications, the vast
majority of threads, even non kernel ones, could run on such cores. Nick
made the point about many "non-tradtional" uses of floating point in what
one might assume were integer-only threads (which still surprises me!),
thus believeing that my idea would not be useful. Sander was the one who
suggested segregating workload to different cores based on the
kernel/non-kernel distinction.
One example:
Until relatively recently (i.e. some years ago) ntp (which works with
unsigned 64-bit values for all timestamps) used nothing but 32-bit
unsigned math for all operations.
Converting all the FLL/PLL operations to fp made the code much simpler and
easier to maintain, so now only the offsets are calculated exactly, then
immediately converted to fp.
|
Thanks, Terje. I am sensing something here, but it may not be right. It
seems that some of the uses of FP, including the one you pointed out, really
want someting else, but FP is closer to what they want than is integer,
hence it is easier/faster to "coerce" FP into what you need. If that is
true, there may be an opportunity to try to find a set of primitive
operations that better suit these needs than either integer or FP. So, two
questions, is my sense right; that there might be something better suited
for these types of situations than FP, and if so, what might these be? A
related question is to attempt to catalog these types of uses for FP to see
if there is any commonality among them.
One other thought. Perhaps this is related to Nick's oft repeated comment
about wanting some kind of FP primitives other than what is available, but
he hasn't specified what he wants in enough detail for me to understand
that.
--
- Stephen Fuld
e-mail address disguised to prevent spam |
|
| Back to top |
|
|
Rupert Pigott
Guest
|
| Posted:
Mon Dec 27, 2004 11:07 pm Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
Stephen Fuld wrote:
| Quote: |
"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:cqpd0s$el1$1@osl016lin.hda.hydro.com...
Stephen Fuld wrote:
I am not going to comment on the idea of putting the kernel into silicon
except to say that makes changes harder. But my original proposal was
NOT for a "kernel only" core, but for a core which had no floating point
nor enhanced graphics instructions in order to save die space in a many
cored system. I felt that many, and for some applications, the vast
majority of threads, even non kernel ones, could run on such cores.
Nick made the point about many "non-tradtional" uses of floating point
in what one might assume were integer-only threads (which still
surprises me!),
thus believeing that my idea would not be useful. Sander was the one
who suggested segregating workload to different cores based on the
kernel/non-kernel distinction.
One example:
Until relatively recently (i.e. some years ago) ntp (which works with
unsigned 64-bit values for all timestamps) used nothing but 32-bit
unsigned math for all operations.
Converting all the FLL/PLL operations to fp made the code much simpler
and easier to maintain, so now only the offsets are calculated exactly,
then immediately converted to fp.
Thanks, Terje. I am sensing something here, but it may not be right. It
seems that some of the uses of FP, including the one you pointed out,
really want someting else, but FP is closer to what they want than is
integer,
hence it is easier/faster to "coerce" FP into what you need. If that is
true, there may be an opportunity to try to find a set of primitive
operations that better suit these needs than either integer or FP. So,
two questions, is my sense right; that there might be something better
suited
for these types of situations than FP, and if so, what might these be? A
related question is to attempt to catalog these types of uses for FP to
see if there is any commonality among them.
|
How about using a language that doesn't force application programmers
to fit the code to the hardware ? All that 64/128 bit stuff can be
trivially hidden by a suitable language and compiler. ;)
Seen that FP hack more times than I care to mention and I've never
really liked it. I like code that clearly expresses what it means
too.. BUT the problem I have with the FP hack is that FP has very
different semantics from fixed point. :(
Cheers,
Rupert
--
Threading sequential code through the eye of a parallel needle
makes little sense. ;) |
|
| Back to top |
|
|
Guest
|
| Posted:
Tue Dec 28, 2004 12:16 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
Stephen Fuld wrote:
| Quote: | I am not going to comment on the idea of putting the kernel into
silicon
except to say that makes changes harder. But my original proposal
was NOT
for a "kernel only" core, but for a core which had no floating point
nor
enhanced graphics instructions in order to save die space in a many
cored
system. I felt that many, and for some applications, the vast
majority of
threads, even non kernel ones, could run on such cores. Nick made
the point
about many "non-tradtional" uses of floating point in what one might
assume
were integer-only threads (which still surprises me!), thus
believeing that
my idea would not be useful. Sander was the one who suggested
segregating
workload to different cores based on the kernel/non-kernel
distinction. |
relatively recently, i actually got a silicon-only chip fab'ed ...
everything is in cast in silicon and there was no provision for
changing any of the programming (w/o replacing the chip). there is
small amount of eeprom ... but for data only. note, however, it is a
relatively straight forward function w/o a lot of options.
http://www.garlic.com/~lynn/index.html#aads |
|
| Back to top |
|
|
Stephen Fuld
Guest
|
| Posted:
Tue Dec 28, 2004 1:33 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
"Rupert Pigott" <darkboong@try-removing-hotmail-this.com> wrote in message
news:41d04f54$0$15200$db0fefd9@news.zen.co.uk...
| Quote: | Stephen Fuld wrote:
"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:cqpd0s$el1$1@osl016lin.hda.hydro.com...
Stephen Fuld wrote:
I am not going to comment on the idea of putting the kernel into
silicon
except to say that makes changes harder. But my original proposal was
NOT for a "kernel only" core, but for a core which had no floating
point
nor enhanced graphics instructions in order to save die space in a many
cored system. I felt that many, and for some applications, the vast
majority of threads, even non kernel ones, could run on such cores.
Nick made the point about many "non-tradtional" uses of floating point
in what one might assume were integer-only threads (which still
surprises me!),
thus believeing that my idea would not be useful. Sander was the one
who suggested segregating workload to different cores based on the
kernel/non-kernel distinction.
One example:
Until relatively recently (i.e. some years ago) ntp (which works with
unsigned 64-bit values for all timestamps) used nothing but 32-bit
unsigned math for all operations.
Converting all the FLL/PLL operations to fp made the code much simpler
and easier to maintain, so now only the offsets are calculated exactly,
then immediately converted to fp.
Thanks, Terje. I am sensing something here, but it may not be right. It
seems that some of the uses of FP, including the one you pointed out,
really want someting else, but FP is closer to what they want than is
integer,
hence it is easier/faster to "coerce" FP into what you need. If that is
true, there may be an opportunity to try to find a set of primitive
operations that better suit these needs than either integer or FP. So,
two questions, is my sense right; that there might be something better
suited
for these types of situations than FP, and if so, what might these be? A
related question is to attempt to catalog these types of uses for FP to
see if there is any commonality among them.
How about using a language that doesn't force application programmers
to fit the code to the hardware ? All that 64/128 bit stuff can be
trivially hidden by a suitable language and compiler. ;)
|
Sure. COBOL did it almost 50 years ago! Seriously, in COBOL, you specify
the number of decimal digits you want (up to some fairly large maxumum) and
the compiler does the rest. Of course certain sizes get things done to them
more quickly. :-)
| Quote: | Seen that FP hack more times than I care to mention and I've never
really liked it. I like code that clearly expresses what it means
too.. BUT the problem I have with the FP hack is that FP has very
different semantics from fixed point. :(
|
OK, so rise to the challenge and try to come up with some primitives that
better express what you want to do. Is it just an issue of wanting more
bits in an integer than the width of a register? Or is there something
else?
--
- Stephen Fuld
e-mail address disguised to prevent spam |
|
| Back to top |
|
|
Dan Koren
Guest
|
| Posted:
Tue Dec 28, 2004 1:41 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
<lynn@garlic.com> wrote in message
news:1104174966.660542.177450@f14g2000cwb.googlegroups.com...
| Quote: |
relatively recently, i actually got a silicon-only chip fab'ed ...
everything is in cast in silicon and there was no provision for
changing any of the programming (w/o replacing the chip). there is
small amount of eeprom ... but for data only. note, however, it is a
relatively straight forward function w/o a lot of options.
|
Isn't this exactly what an OS is supposed to be? ;-)
dk
(donning asbestos suit) |
|
| Back to top |
|
|
John F. Carr
Guest
|
| Posted:
Tue Dec 28, 2004 1:45 am Post subject:
Re: Will multicore CPUs have identical cores? |
|
|
In article <f3xzd.1165466$Gx4.52293@bgtnsc04-news.ops.worldnet.att.net>,
Stephen Fuld <s.fuld@PleaseRemove.att.net> wrote:
| Quote: |
"Dan Koren" <dankoren@yahoo.com> wrote in message
news:41ce3e80$1@news.meer.net...
but if you're willing to
have dedicated silicon for the kernel, one might as
well put the kernel in silicon. Nowadays, compiling
C/C++ into silicon isn't that much harder than
compiling C/C++ into soft object files.
I am not going to comment on the idea of putting the kernel into silicon
except to say that makes changes harder. But my original proposal was NOT
for a "kernel only" core, but for a core which had no floating point nor
enhanced graphics instructions in order to save die space in a many cored
system.
|
How about keeping most of the ISA but removing the complex pipeline
control logic that dwarfs the ALU? This has two aspects. First, a
privileged-only CPU does not need to make generic code run fast.
Second, the designer can say "don't do that" instead of implementing
bypassing or interlocks for some instruction sequences (see: MIPS I,
Intel 860).
Independently, kernel FP could be simpler and slower, e.g. no
pipelining, denormals flush to zero, and NaNs don't behave per
IEEE spec. The FP unit would be an order of magnitude smaller.
--
John Carr (jfc@mit.edu) |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in