SGI finally on its last legs?
CASTalk.com Forum Index CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web castalk.com
SGI finally on its last legs?
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture
Author Message
Hugh Fisher
Guest





Posted: Wed Sep 14, 2005 6:19 am    Post subject: Re: SGI finally on its last legs? Reply with quote

Alex Johnson wrote:
Quote:
Choose your words more carefully. Itanium was not a technical flop.
Well, the original was, but SGI did not abandon MIPS until Itanium II
was declared the world's most powerful microprocessor for numerically
intensive applications (ie, scientific computing, SGI's primary
client base) after knocking the previous title holder, Power 4, from
that spot in mid-02.

MIPS might not have been officially abandoned by SGI, but it was
definitely pining for the fjords. And there didn't seem to be
any plan B at SGI if the Itanium didn't ship on time, so the
MIPS product line was almost stationary for several years.

Del Cecchi wrote:

Quote:
You are right, I should have said "MIGHT BE a technical flop", (in that
it wouldn't meet the needs of a wide customer set) or "MIGHT BE a
(plain) flop", meaning mostly in a business sense. I guess the jury is
still out on the issue of Itanium's long term future. At least in my
view, not that I have any special knowledge.

From a business sense I don't think Itanium can be considered
a flop at all. It wiped out PA-RISC, MIPS, and Alpha as
competitors in desktop/server computing, which Intel might
consider a worthwhile investment even if Itanium had been
cancelled altogether in 2000.

cheers,
Hugh Fisher
Back to top
Dan Koren
Guest





Posted: Wed Sep 14, 2005 6:36 am    Post subject: Re: SGI finally on its last legs? Reply with quote

<already5chosen@yahoo.com> wrote in message
news:1126653261.980433.24150@o13g2000cwo.googlegroups.com...
Quote:

Dan Koren wrote:
already5chosen@yahoo.com> wrote in message
news:1126628242.886463.291650@g43g2000cwa.googlegroups.com...

Dan Koren wrote:
"Dan Koren" <dankoren@yahoo.com> wrote in message
news:43249e75$1@news.meer.net...

\"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:4324934a$1@news.meer.net...
In article <43241db8.4481061@news.usenetzone.com>,
John Savard <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote:

Multicore, as opposed to multi-chip,
offers only one technical benefit -
faster access to a shared cache.

Er, no, a shared cache is actually
more cycles in the uncontended case.
^^^^^^^^^^^
---------------------+++++++++++


Why? Do you think there is some
inherent reason, or it is just
an artifact of current designs?


Obviously to support two cores or
processors efficiently, a cache
would have to be dual- or multi-
ported. Beyond which I cannot
see any obstacles.

No, memory arrays in shared cache
don't have to be multiported.

They don't have to, but it would
certainly help performance.

Don't be so sure.
You need to arbitrate between writes from one agent and reads/writes to
the same location from all other agents regardless of number of ports.
Since value propagation through dual-ported memory takes several
cycles, arbitration machine wouldn't be particularly simple.
Also, since multiported memory cells are bigger (+2T for each
additional port), the whole array becomes less dense. It means - longer
wires. As you probably heard, nowadays long wires considered harmful.
So at the end of the day you have both bigger die and the same or
slower speed.



You are assuming a certain design and implementation.

And I didn't say that *every* memory cell must be
dual- or multi-ported. I said the cache should be
dual-ported. Big difference.


dk
Back to top
Jan Vorbrüggen
Guest





Posted: Wed Sep 14, 2005 8:15 am    Post subject: Re: SGI finally on its last legs? Reply with quote

Quote:
Most codes will fit in the Icache. Why do you mention memory bandwidth
alongside Icache bandwidth?

Those in a major target market of Itanium - databased et al. - most
definitely kill any instruction cache in existence. What was Supnik's
number - 500.000 instructions per transaction with practically no loops?

Jan
Back to top
Grumble
Guest





Posted: Wed Sep 14, 2005 8:15 am    Post subject: Re: SGI finally on its last legs? Reply with quote

Vince wrote:
Quote:
Itanium instructions take about 2 times the memory of AMD64
instructions, and 2 times the memory bandwidth, and 2 times the
instruction cache, and 2 times the instruction cache bandwidth.
Can't imagine Itanium ever matching AMD price/performance.

Most codes will fit in the Icache. Why do you mention memory bandwidth
alongside Icache bandwidth?

What you said is mostly true, however, keep in mind that IA-64 is a
three-operand ISA while IA-32 is a two-operand ISA.

IA-64: C = A + B
IA-32: A = A + B

If you still need the old value of A, you'll have to copy it to another
register.
Back to top
Guest






Posted: Wed Sep 14, 2005 2:06 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

Dan Koren wrote:
Quote:
already5chosen@yahoo.com> wrote in message
news:1126653261.980433.24150@o13g2000cwo.googlegroups.com...

Dan Koren wrote:
already5chosen@yahoo.com> wrote in message
news:1126628242.886463.291650@g43g2000cwa.googlegroups.com...

Dan Koren wrote:
"Dan Koren" <dankoren@yahoo.com> wrote in message
news:43249e75$1@news.meer.net...

\"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:4324934a$1@news.meer.net...
In article <43241db8.4481061@news.usenetzone.com>,
John Savard <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote:

Multicore, as opposed to multi-chip,
offers only one technical benefit -
faster access to a shared cache.

Er, no, a shared cache is actually
more cycles in the uncontended case.
^^^^^^^^^^^
---------------------+++++++++++


Why? Do you think there is some
inherent reason, or it is just
an artifact of current designs?


Obviously to support two cores or
processors efficiently, a cache
would have to be dual- or multi-
ported. Beyond which I cannot
see any obstacles.

No, memory arrays in shared cache
don't have to be multiported.

They don't have to, but it would
certainly help performance.

Don't be so sure.
You need to arbitrate between writes from one agent and reads/writes to
the same location from all other agents regardless of number of ports.
Since value propagation through dual-ported memory takes several
cycles, arbitration machine wouldn't be particularly simple.
Also, since multiported memory cells are bigger (+2T for each
additional port), the whole array becomes less dense. It means - longer
wires. As you probably heard, nowadays long wires considered harmful.
So at the end of the day you have both bigger die and the same or
slower speed.



You are assuming a certain design and implementation.

And I didn't say that *every* memory cell must be
dual- or multi-ported. I said the cache should be
dual-ported. Big difference.


Sorry, Dan, your post makes no sense.
Cache data arrays represent wast majority of on-die memory cells in the
general-purpose MPU.
I am starting to suspect that you have no idea about inner working of
the modern hardware.
Back to top
Dan Koren
Guest





Posted: Thu Sep 15, 2005 8:15 am    Post subject: Re: SGI finally on its last legs? Reply with quote

<already5chosen@yahoo.com> wrote in message
news:1126685223.401588.134120@f14g2000cwb.googlegroups.com...
Quote:

Dan Koren wrote:
already5chosen@yahoo.com> wrote in message
news:1126653261.980433.24150@o13g2000cwo.googlegroups.com...

Dan Koren wrote:
already5chosen@yahoo.com> wrote in message
news:1126628242.886463.291650@g43g2000cwa.googlegroups.com...

Dan Koren wrote:
"Dan Koren" <dankoren@yahoo.com> wrote in message
news:43249e75$1@news.meer.net...

\"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:4324934a$1@news.meer.net...
In article <43241db8.4481061@news.usenetzone.com>,
John Savard <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote:

Multicore, as opposed to multi-chip,
offers only one technical benefit -
faster access to a shared cache.

Er, no, a shared cache is actually
more cycles in the uncontended case.
^^^^^^^^^^^
---------------------+++++++++++


Why? Do you think there is some
inherent reason, or it is just
an artifact of current designs?


Obviously to support two cores or
processors efficiently, a cache
would have to be dual- or multi-
ported. Beyond which I cannot
see any obstacles.

No, memory arrays in shared cache
don't have to be multiported.

They don't have to, but it would
certainly help performance.

Don't be so sure.
You need to arbitrate between writes from one agent and reads/writes to
the same location from all other agents regardless of number of ports.
Since value propagation through dual-ported memory takes several
cycles, arbitration machine wouldn't be particularly simple.
Also, since multiported memory cells are bigger (+2T for each
additional port), the whole array becomes less dense. It means - longer
wires. As you probably heard, nowadays long wires considered harmful.
So at the end of the day you have both bigger die and the same or
slower speed.



You are assuming a certain design and implementation.

And I didn't say that *every* memory cell must be
dual- or multi-ported. I said the cache should be
dual-ported. Big difference.


Sorry, Dan, your post makes no sense.
Cache data arrays represent wast majority of on-die
memory cells in the general-purpose MPU. I am starting
to suspect that you have no idea about inner working of
the modern hardware.


Same here.



dk
Back to top
Ricardo Bugalho
Guest





Posted: Thu Sep 15, 2005 3:11 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

On Wed, 14 Sep 2005 09:15:30 +0200, Jan Vorbrüggen wrote:

Quote:
Most codes will fit in the Icache. Why do you mention memory bandwidth
alongside Icache bandwidth?

Those in a major target market of Itanium - databased et al. - most
definitely kill any instruction cache in existence. What was Supnik's
number - 500.000 instructions per transaction with practically no loops?

I'm too lazy to pick up the reference, but Intel said it's about 1 MB
instruction working set for TCP-C. Hence, the 1 MB L2 I$ in the next
Itanium.
Back to top
Guest






Posted: Fri Sep 16, 2005 8:57 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

Alex Johnson <compuwiz@psualum.com> writes:

Quote:
Del Cecchi wrote:

My guess is that he had decided to transition to Intel for business
reasons, and the notion that Itanium would be a technical flop
never occurred to him. Besides, what choice did he have?

Choose your words more carefully. Itanium was not a technical
flop. Well, the original was, but SGI did not abandon MIPS until
Itanium II was declared the world's most powerful microprocessor for
numerically intensive applications (ie, scientific computing, SGI's
primary client base) after knocking the previous title holder, Power
4, from that spot in mid-02.

Check your history: SGI dumped MIPS in, AIR, 96/97 or so, then later
had to scramble to get new ones to fill in the chasm. SGI where the
first to the cool-aide.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Back to top
Guest






Posted: Fri Sep 16, 2005 9:00 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

Quote:
Most codes will fit in the Icache. Why do you mention memory bandwidth
alongside Icache bandwidth?

Those in a major target market of Itanium - databased et al. - most
definitely kill any instruction cache in existence. What was
Supnik's number - 500.000 instructions per transaction with
practically no loops?

It is in the Turbo-Laser papers if anyone is interested.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Back to top
Yousuf Khan
Guest





Posted: Sun Sep 18, 2005 6:00 am    Post subject: Re: SGI finally on its last legs? Reply with quote

Hugh Fisher wrote:
Quote:
From a business sense I don't think Itanium can be considered
a flop at all. It wiped out PA-RISC, MIPS, and Alpha as
competitors in desktop/server computing, which Intel might
consider a worthwhile investment even if Itanium had been
cancelled altogether in 2000.

Yet, all of those "wiped out" architectures still massively outsell
Itanium to this day. PA & Alpha will stop mainly because HP, their
owner, says they'll stop being sold. MIPS is still strong in the
embedded market.

Yousuf Khan
Back to top
Del Cecchi
Guest





Posted: Sun Sep 18, 2005 10:49 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:y_2Xe.4666$6Z1.1234428@news20.bellglobal.com...
Quote:
Hugh Fisher wrote:
From a business sense I don't think Itanium can be considered
a flop at all. It wiped out PA-RISC, MIPS, and Alpha as
competitors in desktop/server computing, which Intel might
consider a worthwhile investment even if Itanium had been
cancelled altogether in 2000.

Yet, all of those "wiped out" architectures still massively outsell
Itanium to this day. PA & Alpha will stop mainly because HP, their
owner, says they'll stop being sold. MIPS is still strong in the
embedded market.

Yousuf Khan

You really have to think of "embedded mips" as different from "server
mips" architecture, and the same is true of PowerPC.
Back to top
Alex Johnson
Guest





Posted: Mon Sep 19, 2005 4:15 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

prep@prep.synonet.com wrote:
Quote:
Check your history: SGI dumped MIPS in, AIR, 96/97 or so, then later
had to scramble to get new ones to fill in the chasm. SGI where the
first to the cool-aide.


Am I hearing you right? You are saying SGI stopped using MIPS
microprocessors in 96/97? They didn't offer an Itanium machine until
01/02. So what you are saying is that SGI didn't sell a single computer
for about 5 years.

Alex
Back to top
Bill Davidsen
Guest





Posted: Mon Sep 19, 2005 4:15 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

vince@offshore.ai wrote:
Quote:
That doesn't seem like a big gap to me,


Opterons just got about 10% faster in the last couple days. Sun/AMD
announced some 120 watt Opterons that are like 10% faster. So the
floating point gap is noise at this point. Opteron's integer lead is
bigger though.

The other thing is that when you put 4 Opterons together you get very
nearly 4 times the performance with no glue chips. This is not so with
Itanium. So the Opteron price/performance lead is even better once we
are talking about real systems and not just 1 CPU.

Are these both the same config? You're not comparing one shared memory

config to one NUMA are you?

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com
Back to top
Bill Todd
Guest





Posted: Mon Sep 19, 2005 10:19 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

Alex Johnson wrote:
Quote:
prep@prep.synonet.com wrote:

Check your history: SGI dumped MIPS in, AIR, 96/97 or so, then later
had to scramble to get new ones to fill in the chasm. SGI where the
first to the cool-aide.


Am I hearing you right?

Yes, just not listening very well.

You are saying SGI stopped using MIPS
Quote:
microprocessors in 96/97?

No, he's saying that SGI made it clear that MIPS was not the long-term
future focus of the company by dumping further significant *development*
efforts back then.

They didn't offer an Itanium machine until
Quote:
01/02. So what you are saying is that SGI didn't sell a single computer
for about 5 years.

Don't try so hard to be an idiot.

- bill
Back to top
Colonel Forbin
Guest





Posted: Mon Sep 19, 2005 10:33 pm    Post subject: Re: SGI finally on its last legs? Reply with quote

In article <%cBXe.305$4u4.139@newssvr19.news.prodigy.com>,
Bill Davidsen <davidsen@deathstar.prodigy.com> wrote:
Quote:

The other thing is that when you put 4 Opterons together you get very
nearly 4 times the performance with no glue chips. This is not so with
Itanium. So the Opteron price/performance lead is even better once we
are talking about real systems and not just 1 CPU.

Are these both the same config? You're not comparing one shared memory
config to one NUMA are you?

NUMA *is* shared memory. So is UMA. Technically unless all levels
of cache are shared, all shared memory systems are NUMA.

Also, SMP can be UMA or NUMA, and SMP refers to multitasking on multiple
CPUs, not memory access latency.

With respect to the poster you are criticizing, last I heard Opterons
require some kind of chipset support to operate at all, so nitpicking
over "glue" for SMP is a red herring.

I'm no fan of Itanic and I regret that SGI seems to have bet their farm
on it, but let's at least be fair.

I'm not convinced that either VLIW or an ugly CISC emulated on a RISC
core are inherently architecturally elegant, but they seem to be what
we're stuck with at present, and they pay the utility bills.

As Dan Koren is fond of pointing out, SGI has made a number of strategic
blunders over the years, not the least of which was selling the CS6400
IP to Sun.

Considering Sun's idiotic blunders in software support for high end 3D
graphics (SPARC-2GT, anyone?) it's rather stunning that SGI regarded
Sun as competition in their core markets.

Given the way the SGI aggression against Sun turned out, it will be
interesting to see how Microsoft's "Sundown" ends up. If it's
anything like SGI's CS6400 debacle, Steve Ballmer could end up
reporting to Scooter.
Back to top
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




VoIP Electronics Powered by phpBB