| Author |
Message |
keith
Guest
|
 Posted:
Sat Feb 12, 2005 7:55 am Post subject:
Re: Rambus for GPUs? (was: Cell Processor Uses Rambus ...) |
|
|
On Fri, 11 Feb 2005 17:40:25 -0500, daytripper wrote:
| Quote: | On Fri, 11 Feb 2005 01:31:06 -0500, Tony Hill <hilla_nospam_20@yahoo.ca
wrote:
On Thu, 10 Feb 2005 10:56:07 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:
Tony Hill <hilla_nospam_20@yahoo.ca> writes:
With the way that the PS2 processor and this new Cell processor work,
combined with the nature of the machine (ie to play games), bandwidth
is likely to be quite important while latency will be somewhat less
so. Remember that these processors are going to be doing a lot of
work traditionally associated with GPUs in a PC. Rambus' solutions,
both XDR now and RDRAM back when the PS2 was new, do offer VERY high
per-pin bandwidth and that's just the sort of thing that these
consoles need. The processors also have integrated memory controllers
which helps avoid some of the potential issues with Rambus in PCs. To
top it off, the memory chips are getting soldered right onto the
system board rather than hanging off multidrop sockets on the system
board.
Given all of that, Rambus would also make sense for graphics cards
(where all of the same things hold). Yet both Nvidia and ATI go with
DDR-SDRAM. Why? Is the savings by reducing pins less than the
premium for Rambus RAM? If so, wouldn't it also make sense for PS3 to
use DDR(2)-SDRAM?
I've wondered the very same thing myself. To me, from the outside at
least, it seems like it would make sense. Rambus memory has been used
in video cards before, but only in some very rare situations. I don't
even think there would be much of a cost difference for the memory
chips even, given that video cards use very high-end/high speed GDDR3
memory, quite a bit more expensive than the DDR memory used in desktop
PCs.
However nVidia has commented before that they have evaluated Rambus
memory on more than one occasion and found it to be unsuitable for
their application. It's always made me wonder if maybe they know
something that the rest of us don't? Or maybe their decision was only
partly based on technical reasons and partly on more political/legal
related ones? Or maybe it has to do with Rambus licensing fees for
the memory controller rather than for the memory itself?
In short, I really don't know what the answer is here.
In essensce, what's so different between the PS3 and graphics cards
that one goes with Rambus whereas the others go with DDR(2)?
Not much from where I'm standing.
Some times you get beau coup pins for "free". Like when you need a humongous
die and package to fit all the functional bells, whistles and go-fasters on
the chip...
|
....and sometimes faster pins are not so attractive. Sometimes those pins
are better used for power/ground.
--
Keith |
|
| Back to top |
|
 |
Alex Colvin
Guest
|
| Posted:
Sat Feb 12, 2005 8:26 pm Post subject:
Re: Intel has no answer to the 'Cell' processor; will Apple |
|
|
| Quote: | http://www.intel.com/design/network/products/npfamily/docs/ixp2800_docs.htm#Datasheets
Similar concept. Very different purpose. The ixp2800 uses an ARM core
with no FPU where-as the Cell uses a POWER core with the full
instruction set and all the necessary execution units. The ixp2800
microengines are specialized units for data transfer, they move things
around, while the Cell coprocessors are specialized unis for FP vector
|
right. my thought was that a stripped-down embedded processor with a pile
of attached processors is not something new, and is not necessarily going
to change the face of computing.
also, the intel network processor is not amenable to programming in C, |
|
| Back to top |
|
|
Mattinglyfan
Guest
|
| Posted:
Sat Feb 12, 2005 9:29 pm Post subject:
Re: The CELL Microprocessor Further In-Depth |
|
|
"deKay" <andyk@lofi-gaming.org.uk> wrote in message
news:p47q01tvu7k9i6vsihobo4vd0kqo38hmlj@4ax.com...
| Quote: | Soni tempori elseu romani yeof helsforo nisson ol sefini ill des Fri, 11
Feb
2005 16:52:21 +0000 (UTC), sefini jorgo geanyet des mani yeof do
uk.games.video.playstation, yawatina tan reek esk David Wang
foo@bar.invalid
fornis do marikano es bono tan el:
[The rest of my article snipped]
Dear "NEXT BOX",
You managed to copy everything except the following copyright
statement. You are expressly forbidden to do what you did. Please
cease and desist. I will be contacting your ISP shortly.
Thank you for your attention to this matter.
You will have a small army of supporters, Mr Wang. May I suggest you take
it
further than just contacting his ISP? You'd be doing the whole of Usenet
a
great service if you got him banged up for this :)
|
Here here! Even though I doubt that it is from the real author.
|
|
| Back to top |
|
|
The little lost angel
Guest
|
| Posted:
Sun Feb 13, 2005 7:57 am Post subject:
Re: The CELL Microprocessor Further In-Depth |
|
|
On Sat, 12 Feb 2005 09:29:50 -0700, "Mattinglyfan"
<Estoscacahuates@comcast.net (deez nuts)> wrote:
| Quote: | You will have a small army of supporters, Mr Wang. May I suggest you take
it
further than just contacting his ISP? You'd be doing the whole of Usenet
a
great service if you got him banged up for this :)
Here here! Even though I doubt that it is from the real author.
|
I'm pretty sure, even without checking the site I suspect it's posted
on, that Mr Wang is the author. He's the "real world" author of more
than a handful of technical articles AFAIK.
--
L.Angel: I'm looking for web design work.
If you need basic to med complexity webpages at affordable rates, email me :)
Standard HTML, SHTML, MySQL + PHP or ASP, Javascript.
If you really want, FrontPage & DreamWeaver too.
But keep in mind you pay extra bandwidth for their bloated code |
|
| Back to top |
|
|
Tony Hill
Guest
|
| Posted:
Mon Feb 14, 2005 6:45 am Post subject:
Re: Cell Processor Uses Rambus High Speed Interface Solution |
|
|
On Fri, 11 Feb 2005 09:06:16 -0500, Bill Todd <billtodd@metrocast.net>
wrote:
| Quote: | Tony Hill wrote:
...
Even in SPEC CFP2000, kind of the ideal benchmark for this
super-bandwidth setup, the EV7 is still being beaten by current x86
processors. When looking at other tests it's even less impressive.
Yeah - really pathetic performance from a 1998 core two full process
generations out of date.
|
Uhh, yeah. That's why I wrote in the VERY next line of the message:
"Now again those results are not necessarily an indication that Rambus
is a failure because there are MANY other issues holding the EV7s
performance back (only some of which are technical)."
Besides, the Opteron uses largely the same core as the original
Athlon, released in 1999. It might have a few more changes than for
the EV6 vs. EV7, but as is the case with the Alphas the primary
differences between Athlon and Opteron are in I/O and the memory
subsystem.
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca |
|
| Back to top |
|
|
daytripper
Guest
|
| Posted:
Mon Feb 14, 2005 7:33 am Post subject:
Re: Rambus for GPUs? (was: Cell Processor Uses Rambus ...) |
|
|
On Sun, 13 Feb 2005 20:45:45 -0500, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:
| Quote: | On Fri, 11 Feb 2005 17:40:25 -0500, daytripper
day_trippr@REMOVEyahoo.com> wrote:
On Fri, 11 Feb 2005 01:31:06 -0500, Tony Hill <hilla_nospam_20@yahoo.ca
wrote:
In essensce, what's so different between the PS3 and graphics cards
that one goes with Rambus whereas the others go with DDR(2)?
Not much from where I'm standing.
Some times you get beau coup pins for "free". Like when you need a humongous
die and package to fit all the functional bells, whistles and go-fasters on
the chip...
True, but in an application with a virtually limitless appetite for
bandwidth, like a modern GPU, it still seems to me like getting the
most bandwidth/pin would be attractive. Just look at the memory chips
that they ARE using on top-end GPUs, GDDR3 memory running at 500MHz+!
That stuff does not come cheap, so obviously they've got a reason to
use them.
|
If there was an advantage to be had for a GPU to use something other than
GDDR3 you can be sure someone would be using it... |
|
| Back to top |
|
|
Maynard Handley
Guest
|
| Posted:
Tue Feb 15, 2005 4:52 am Post subject:
Re: Intel has no answer to the 'Cell' processor; will Apple |
|
|
In article <culoqc$jdh$1@pcls4.std.com>,
Alex Colvin <alexc@TheWorld.com> wrote:
| Quote: | http://www.intel.com/design/network/products/npfamily/docs/ixp2800_docs.htm
#Datasheets
Similar concept. Very different purpose. The ixp2800 uses an ARM core
with no FPU where-as the Cell uses a POWER core with the full
instruction set and all the necessary execution units. The ixp2800
microengines are specialized units for data transfer, they move things
around, while the Cell coprocessors are specialized unis for FP vector
right. my thought was that a stripped-down embedded processor with a pile
of attached processors is not something new, and is not necessarily going
to change the face of computing.
also, the intel network processor is not amenable to programming in C,
|
And this thing is? The mere fact that one can write some sort of
bastardized C + intrinsics code does not make it amenable to C.
People also seem to forget that masses of FP with a messy programming
model is not a recipe for taking over the world --- if it were DSPs as
coprocessors would be more common in workstations.
Maynard |
|
| Back to top |
|
|
Jeremy Williamson
Guest
|
| Posted:
Thu Feb 17, 2005 7:20 am Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
"keith" <krw@att.bizzzz> wrote in message
news:pan.2005.02.12.02.52.29.190726@att.bizzzz...
| Quote: | On Fri, 11 Feb 2005 16:29:23 -0500, myren, lord wrote:
NEXT BOX wrote:
I don't want to hype today *too* much, for fear of disappointment. but
in
less than 10 hours, there is *supposed* to be quiet a bit of
information
released on the Cell Processor Element, Cell APU and Cell PU. the basic
building blocks of Cell Processors and Cell Systems. As well as
information
on the software side, if i'm not mistaken.
I havent found much new information on Cell since the Sony regalia.
Did you really expect to? This is ISSCC, not an architecture forum.
--
Keith
|
Just back from HPCA, which had a Cell presentation and no new info. Most of
the slides were just repetitions of the ISSCC presentation. Microprocessor
Report looks to have a nice summary of what's know so far. Haven't finished
reading it yet though...
Jeremy |
|
| Back to top |
|
|
keith
Guest
|
| Posted:
Thu Feb 17, 2005 7:57 am Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
On Wed, 16 Feb 2005 18:20:36 -0800, Jeremy Williamson wrote:
| Quote: |
"keith" <krw@att.bizzzz> wrote in message
news:pan.2005.02.12.02.52.29.190726@att.bizzzz...
On Fri, 11 Feb 2005 16:29:23 -0500, myren, lord wrote:
NEXT BOX wrote:
I don't want to hype today *too* much, for fear of disappointment. but
in
less than 10 hours, there is *supposed* to be quiet a bit of
information
released on the Cell Processor Element, Cell APU and Cell PU. the basic
building blocks of Cell Processors and Cell Systems. As well as
information
on the software side, if i'm not mistaken.
I havent found much new information on Cell since the Sony regalia.
Did you really expect to? This is ISSCC, not an architecture forum.
--
Keith
Just back from HPCA, which had a Cell presentation and no new info. Most of
the slides were just repetitions of the ISSCC presentation. Microprocessor
Report looks to have a nice summary of what's know so far. Haven't finished
reading it yet though...
|
There's a lot more hype to wade through before you're going to have the
answers you want. They've not discussed the details of the architecture
yet. My educated guess is that there will be another hype-dump at the
Microprocessor Forum in October.
Some may even be surprised. ;-)
--
Keith |
|
| Back to top |
|
|
David Wang
Guest
|
| Posted:
Thu Feb 17, 2005 8:46 pm Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
In comp.arch Jeremy Williamson <jeremiah.d.williamson@nospamintel.com> wrote:
| Quote: | Just back from HPCA, which had a Cell presentation and no new info. Most of
the slides were just repetitions of the ISSCC presentation. Microprocessor
Report looks to have a nice summary of what's know so far. Haven't finished
reading it yet though...
|
I was hoping to talk to Peter Hofstee on the boat trip, but the whole panel
went out to dinner instead of the boat trip.
The 2 way glueless SMP thing was new, and a few more sentences were new
to me, but you're quite right, there were little that was "truly new" in
terms of stuff that wasn't talked about at ISSCC.
I am still trying to figure out whether the "64 TFlop rack" that Peter
talked about was a prototype rack filled with CELL processors, or was it
part of the generic challenges of architecture going forward, and the
rack could be anything, perhaps Bluegene L rather than CELL.
--
davewang202(at)yahoo(dot)com |
|
| Back to top |
|
|
David Wang
Guest
|
| Posted:
Fri Feb 18, 2005 2:59 am Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
In comp.arch Jeremy Williamson <jeremiah.d.williamson@nospamintel.com> wrote:
| Quote: | Would you want to be on a boat in that weather? Wonder if I can get a
partial refund... hmmm... ;)
|
It wasn't about the boat trip.
You have a bunch of senior architects trapped on a boat of 3 hours. You have
3 hours to sell them on your insane ideas, and they have nowhere to run.
(Some of the big names didn't show up though)
My friends and I were joking that if the boat was to have sunk, it would
set back the field of computer architecture for a few years.
| Quote: | 2 way glueless SMP? Ehhh... Which version of the SMP acronym are we using?
Cell is definitly not a shared memory processor. Ok, ok, sorry I'm just
bitching about reuse of basic acronyms. Yes, I know its for symmetric
multiprocessing... I'd expect them to be glueless or the whole Cell idea
would fall on it's behind.
|
Well, Peter showed that you can do 2 way glueless and also showed that
you can do more than 2 ay with a switch. I asked him if he could do a
glueless ring, and he said no, it has to be a coherent switch for N > 2.
| Quote: | 64 TFlop rack? Don't recall that. Yeah, probably just a rack of CELLs...
|
Everyone else thinks that it was just a Blue Gene rack. I thought it
was CELL based.
| Quote: | I was in the back of the room so couldn't hear him all that well. Not
exactly a great public speaker... of course, that's not what they pay him
for...
|
Yes, the variable-distance-between-mouth-and-microphone issue in
conjunction with the variable speed in flipping through the slides
and some mumbling made the talk hard to follow.
I was thinking that I should have pulled the Japanese Journalist
trick and just started taking pictures of the slides.
--
davewang202(at)yahoo(dot)com |
|
| Back to top |
|
|
Jeremy Williamson
Guest
|
| Posted:
Fri Feb 18, 2005 4:29 am Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
"keith" <krw@att.bizzzz> wrote in message
news:pan.2005.02.17.03.04.24.705578@att.bizzzz...
| Quote: | On Wed, 16 Feb 2005 18:20:36 -0800, Jeremy Williamson wrote:
"keith" <krw@att.bizzzz> wrote in message
news:pan.2005.02.12.02.52.29.190726@att.bizzzz...
On Fri, 11 Feb 2005 16:29:23 -0500, myren, lord wrote:
NEXT BOX wrote:
I don't want to hype today *too* much, for fear of disappointment.
but
in
less than 10 hours, there is *supposed* to be quiet a bit of
information
released on the Cell Processor Element, Cell APU and Cell PU. the
basic
building blocks of Cell Processors and Cell Systems. As well as
information
on the software side, if i'm not mistaken.
I havent found much new information on Cell since the Sony regalia.
Did you really expect to? This is ISSCC, not an architecture forum.
--
Keith
Just back from HPCA, which had a Cell presentation and no new info.
Most of
the slides were just repetitions of the ISSCC presentation.
Microprocessor
Report looks to have a nice summary of what's know so far. Haven't
finished
reading it yet though...
There's a lot more hype to wade through before you're going to have the
answers you want. They've not discussed the details of the architecture
yet. My educated guess is that there will be another hype-dump at the
Microprocessor Forum in October.
Some may even be surprised. ;-)
--
Keith
|
E3 will be before that.
Jeremy |
|
| Back to top |
|
|
Jeremy Williamson
Guest
|
| Posted:
Fri Feb 18, 2005 6:50 am Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
"David Wang" <foo@bar.invalid> wrote in message
news:cv2vqd$rb1$1@grapevine.wam.umd.edu...
| Quote: | In comp.arch Jeremy Williamson <jeremiah.d.williamson@nospamintel.com
wrote:
Just back from HPCA, which had a Cell presentation and no new info.
Most of
the slides were just repetitions of the ISSCC presentation.
Microprocessor
Report looks to have a nice summary of what's know so far. Haven't
finished
reading it yet though...
I was hoping to talk to Peter Hofstee on the boat trip, but the whole
panel
went out to dinner instead of the boat trip.
The 2 way glueless SMP thing was new, and a few more sentences were new
to me, but you're quite right, there were little that was "truly new" in
terms of stuff that wasn't talked about at ISSCC.
I am still trying to figure out whether the "64 TFlop rack" that Peter
talked about was a prototype rack filled with CELL processors, or was it
part of the generic challenges of architecture going forward, and the
rack could be anything, perhaps Bluegene L rather than CELL.
--
davewang202(at)yahoo(dot)com
|
Would you want to be on a boat in that weather? Wonder if I can get a
partial refund... hmmm... ;)
2 way glueless SMP? Ehhh... Which version of the SMP acronym are we using?
Cell is definitly not a shared memory processor. Ok, ok, sorry I'm just
bitching about reuse of basic acronyms. Yes, I know its for symmetric
multiprocessing... I'd expect them to be glueless or the whole Cell idea
would fall on it's behind.
64 TFlop rack? Don't recall that. Yeah, probably just a rack of CELLs...
I was in the back of the room so couldn't hear him all that well. Not
exactly a great public speaker... of course, that's not what they pay him
for...
Jeremy |
|
| Back to top |
|
|
David Wang
Guest
|
| Posted:
Fri Feb 18, 2005 7:52 pm Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
In comp.arch Maynard Handley <name99@name99.org> wrote:
| Quote: | Let's have some common sense here.
If the only fora in which IBM/Sony/Toshiba have anything to say about
Cell are HW conferences, the product simply is not very interesting to
anyone but a very specialized minority.
As I have tried to point out over and over again, the fact that this
thing offers a whole bunch of FMACs is completely ho-hum; what matters
is that programming the thing is very different to programming a
traditional CPU. Not only do you have the multi-processing aspect, a
hard-enough problem that is still not really well-solved; but in
addition you have this bizarre constraint of having to fit each unit of
material you plan to work with (code+data+lookup tables+anything else)
into 256KiB, plus having to interface with the main CPU to have it kick
new code into each SPU. Welcome to parallel programming using overlays,
and writing large chunks of the code in pseudo-assembly.
(All this, of course, doesn't even touch issues like how usefully to
virtualize the SPUs so that you can play nicely on a workstation rather
than such lame ideas as having the first app reserve them all and no
subsequent app get to use them.)
If IBM/Sony/Toshiba don't have some VERY fancy technology to show off at
language and OS conferences regarding all this (and I mean FANCY
technology --- we got a C compiler to produce code for the completely
uninteresting case of a problem that fits into <256KiB on one SPU does
not cut it, not even close), then who cares about the product --- it's
about as interesting as learning what engine powers the MPEG encoders
for some broadcast network's HDTV processing.
|
Seriously, I'm not sure what your response has to do with my post.
I *think* that most people that read comp.arch already possess some
common sense about what the CELL processor is, and what it's trying
to do.
The success/failure of CELL to expand outside of the domain of a game
console depends not on how many FMACs or how many BIPS or GFLOPS it can
deliver, but on the yet unknown and yet unproven software stack.
Perhaps I should have prefaced all of my comments with the 3 line
disclaimer, and perhaps I assumed to much, but I believe that this
was a point already understood by those intelligent enough to discuss
the matter.
So far, STI has basically taken the EE and added some capabilities
that you definitely don't need in a game console. It seems clear that
STI has ambitions to extend the processor to different domains.
That is all that can be inferred thus far from the various HW details
released thus far. Now, whether STI can deliver a near-magical software
stack, or just a empty HW framework waiting for someone else to deliver
the software stack, that is yet unknown to those of us in the public
domain.
If the point of your post is that the key to CELL is software,
then you'll get no argument from me. If the point of your post is
that the CELL processor is an idiotic idea because you don't see
that such a processor can replace PPC970xx series of processors or
POWERxx processors or x86 or IPF in workstations or servers running
OLTP workloads, then I would take issues with that. IMHO, the CELL
processor doesn't need to be in everything and become the generic
replacement for x86/IPF/POWERxx/everything_else for it to be a
success.
I would argue that at this point in time, if there are people
running around proposing CELL based workstations and commercial
servers, then they are rather premature, and I'm not here to
support the hype without seeing details of the software stack.
My interest in CELL is purely academic. That is, someone built
a piece of hardware that is sufficiently different from other
pieces of hardware that we normally stare at, so from that
perspective, it's "interesting".
Now, do I buy into the hype from Sony's various patents about
"CELL everywhere"? No.
Am I simply gushing about the large numbers of FMACs? No.
Would I be interested in seeing details about the software
stack if/when STI releases details of it later in the year?
yes.
I will agree that quite a bit of this CELL thing is hype, but
as it has been pointed out before, the "best" technical
solutions don't always "win". The computer industry is often
driven by perception. Perception then drives reality, and
oftentimes the hype drives things into reality, becoming
self fulfilling prophesies. That's what the marketing folks
try to do. It's their job. Unfortauntely, at this point, no
one can really write anything about the CELL processor without
becoming part of the hype in feeding the frenzy. However,
I hope that I've tried to stay out of the hyps aspect of things,
and just described the hardware as objectively as possible,
knowing all the while that for the CELL processor in particular
it's not the hardware that will determine its ultimate success,
but software.
| Quote: | In article <cv3ln1$6lv$1@grapevine.wam.umd.edu>,
David Wang <foo@bar.invalid> wrote:
In comp.arch Jeremy Williamson <jeremiah.d.williamson@nospamintel.com> wrote:
Would you want to be on a boat in that weather? Wonder if I can get a
partial refund... hmmm... ;)
It wasn't about the boat trip.
You have a bunch of senior architects trapped on a boat of 3 hours. You have
3 hours to sell them on your insane ideas, and they have nowhere to run.
(Some of the big names didn't show up though)
My friends and I were joking that if the boat was to have sunk, it would
set back the field of computer architecture for a few years.
2 way glueless SMP? Ehhh... Which version of the SMP acronym are we using?
Cell is definitly not a shared memory processor. Ok, ok, sorry I'm just
bitching about reuse of basic acronyms. Yes, I know its for symmetric
multiprocessing... I'd expect them to be glueless or the whole Cell idea
would fall on it's behind.
Well, Peter showed that you can do 2 way glueless and also showed that
you can do more than 2 ay with a switch. I asked him if he could do a
glueless ring, and he said no, it has to be a coherent switch for N > 2.
64 TFlop rack? Don't recall that. Yeah, probably just a rack of CELLs...
Everyone else thinks that it was just a Blue Gene rack. I thought it
was CELL based.
I was in the back of the room so couldn't hear him all that well. Not
exactly a great public speaker... of course, that's not what they pay him
for...
Yes, the variable-distance-between-mouth-and-microphone issue in
conjunction with the variable speed in flipping through the slides
and some mumbling made the talk hard to follow.
I was thinking that I should have pulled the Japanese Journalist
trick and just started taking pictures of the slides.
|
--
davewang202(at)yahoo(dot)com |
|
| Back to top |
|
|
Maynard Handley
Guest
|
| Posted:
Fri Feb 18, 2005 11:56 pm Post subject:
Re: CELL INFO: Less than 10 hours away? |
|
|
Let's have some common sense here.
If the only fora in which IBM/Sony/Toshiba have anything to say about
Cell are HW conferences, the product simply is not very interesting to
anyone but a very specialized minority.
As I have tried to point out over and over again, the fact that this
thing offers a whole bunch of FMACs is completely ho-hum; what matters
is that programming the thing is very different to programming a
traditional CPU. Not only do you have the multi-processing aspect, a
hard-enough problem that is still not really well-solved; but in
addition you have this bizarre constraint of having to fit each unit of
material you plan to work with (code+data+lookup tables+anything else)
into 256KiB, plus having to interface with the main CPU to have it kick
new code into each SPU. Welcome to parallel programming using overlays,
and writing large chunks of the code in pseudo-assembly.
(All this, of course, doesn't even touch issues like how usefully to
virtualize the SPUs so that you can play nicely on a workstation rather
than such lame ideas as having the first app reserve them all and no
subsequent app get to use them.)
If IBM/Sony/Toshiba don't have some VERY fancy technology to show off at
language and OS conferences regarding all this (and I mean FANCY
technology --- we got a C compiler to produce code for the completely
uninteresting case of a problem that fits into <256KiB on one SPU does
not cut it, not even close), then who cares about the product --- it's
about as interesting as learning what engine powers the MPEG encoders
for some broadcast network's HDTV processing.
Maynard
In article <cv3ln1$6lv$1@grapevine.wam.umd.edu>,
David Wang <foo@bar.invalid> wrote:
| Quote: | In comp.arch Jeremy Williamson <jeremiah.d.williamson@nospamintel.com> wrote:
Would you want to be on a boat in that weather? Wonder if I can get a
partial refund... hmmm... ;)
It wasn't about the boat trip.
You have a bunch of senior architects trapped on a boat of 3 hours. You have
3 hours to sell them on your insane ideas, and they have nowhere to run.
(Some of the big names didn't show up though)
My friends and I were joking that if the boat was to have sunk, it would
set back the field of computer architecture for a few years.
2 way glueless SMP? Ehhh... Which version of the SMP acronym are we using?
Cell is definitly not a shared memory processor. Ok, ok, sorry I'm just
bitching about reuse of basic acronyms. Yes, I know its for symmetric
multiprocessing... I'd expect them to be glueless or the whole Cell idea
would fall on it's behind.
Well, Peter showed that you can do 2 way glueless and also showed that
you can do more than 2 ay with a switch. I asked him if he could do a
glueless ring, and he said no, it has to be a coherent switch for N > 2.
64 TFlop rack? Don't recall that. Yeah, probably just a rack of CELLs...
Everyone else thinks that it was just a Blue Gene rack. I thought it
was CELL based.
I was in the back of the room so couldn't hear him all that well. Not
exactly a great public speaker... of course, that's not what they pay him
for...
Yes, the variable-distance-between-mouth-and-microphone issue in
conjunction with the variable speed in flipping through the slides
and some mumbling made the talk hard to follow.
I was thinking that I should have pulled the Japanese Journalist
trick and just started taking pictures of the slides.
--
davewang202(at)yahoo(dot)com |
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in