AMD to leave x86 behind?
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
AMD to leave x86 behind?
Goto page Previous  1, 2, 3, ... 20, 21, 22  Next
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture
Author Message
Casper H.S. Dik
Guest





Posted: Thu Oct 27, 2005 4:15 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

"hackbox.info" <hackbox.info@gmail.com> writes:

Quote:
And who will optimize? What was the name of AMD compiler again? what, no
compiler? .. great idea

The Sun compilers are seeing a lot of AMD64 specific work because of
Sun's investment in Opteron boxes.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Back to top
George Macdonald
Guest





Posted: Thu Oct 27, 2005 4:15 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

On 26 Oct 2005 08:17:17 -0700, "YKhan" <yjkhan@gmail.com> wrote:

Quote:
No real details here, just a "stay tuned" message, but that should be
enough to start wild speculations running.

"One strategic path that will knock you for a loop, and which I'll
detail soon, is AMD's coming escape from the confines of Intel's
x86 instruction set. To this point, AMD has resisted the temptation to
overhaul the x86, even though it sorely needs it. When Fab 36 cranks
up, AMD will overcome that fear. AMD64 processors will take on
performance, scalability, resource management, and availability-related
instruction set extensions that will be proprietary to AMD CPUs.
Don't freak out: AMD will keep its contract to be 100 percent
compatible with Intel-standard processors. But the idea of seeing
"optimized for AMD64" stamped on software boxes delights me. "
http://www.infoworld.com/article/05/10/26/44OPcurve_1.html?source=rss&url=http:/
/www.infoworld.com/article/05/10/26/44OPcurve_1.html

or, http://tinyurl.com/cvvwn

I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

I'd be interested as to how this plays with the AMD/Intel cross-license
agreement: at what point are new extensions not subject to free exchange
between the two?... and not subject to royalty payments by AMD to Intel?

--
Rgds, George Macdonald
Back to top
Tim McCaffrey
Guest





Posted: Thu Oct 27, 2005 4:59 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

In article <1130339837.841405.53060@g47g2000cwa.googlegroups.com>,
yjkhan@gmail.com says...
Quote:

No real details here, just a "stay tuned" message, but that should be
enough to start wild speculations running.

"One strategic path that will knock you for a loop, and which I'll
detail soon, is AMD's coming escape from the confines of Intel's
x86 instruction set. To this point, AMD has resisted the temptation to
overhaul the x86, even though it sorely needs it. When Fab 36 cranks
up, AMD will overcome that fear. AMD64 processors will take on
performance, scalability, resource management, and availability-related
instruction set extensions that will be proprietary to AMD CPUs.

[snip]

Performance doesn't necessarily mean FP performance. For instance, the
x86 interrupt model really needs a re-think (especially since x86-64
doesn't really support the segmentation model). Something like
the ARM's register sets would be nice.

Instructions that load/store/copy memory that control how much
cache pollution is done and/or communicate to the bridges and
I/O devices how much data is being loaded/stored could improve
efficiency on the I/O (PCI) and memory busses.

Scalability could be addressed by, for instance, adding registers
that an external device or another processor could store to
(mailbox registers or FIFOs). This could reduce memory contention.

etc. etc.

This stuff isn't new, embedded I/O processors, such as Intel's StrongArm
IO processors (80331, etc), have provided similar mechanisms for years.

- Tim

NOT speaking for Unisys.
Back to top
Jim Brooks
Guest





Posted: Sat Oct 29, 2005 4:15 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

On Wed, 26 Oct 2005 08:17:17 -0700, YKhan wrote:

Quote:
No real details here, just a "stay tuned" message, but that should be
enough to start wild speculations running.

"One strategic path that will knock you for a loop, and which I'll
detail soon, is AMD's coming escape from the confines of Intel's
x86 instruction set. To this point, AMD has resisted the temptation to
overhaul the x86, even though it sorely needs it. When Fab 36 cranks
up, AMD will overcome that fear. AMD64 processors will take on
performance, scalability, resource management, and availability-related
instruction set extensions that will be proprietary to AMD CPUs.
Don't freak out: AMD will keep its contract to be 100 percent
compatible with Intel-standard processors. But the idea of seeing
"optimized for AMD64" stamped on software boxes delights me. "
http://www.infoworld.com/article/05/10/26/44OPcurve_1.html?source=rss&url=http:/
/www.infoworld.com/article/05/10/26/44OPcurve_1.html

or, http://tinyurl.com/cvvwn


A sharp barb the subject "AMD to leave x86 behind?" is.
Very good.
A rising star among us trolls Khan is becoming.


Quote:
I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

Yousuf Khan


SIMD FP is a bad idea. Think of it as CISC FP.

Dunno about AMD's SSE implementation.
But Intel P6 treats SIMD FP as CISC FP in some sense.
P6 decomposes a 4-way PADD into two 2-way PADDs
and sends the pair down Port 0 and 1
(or sequentially to one port if the other is busy).

Most 3D apps calculate (X,Y,Z) rather than (X,Y,Z,W).
So a FPU with 3 pipes, not 4, is more appropriate.
And don't tell me I must "swizzle" my vertex arrays.
Back to top
Mark Hahn
Guest





Posted: Sat Oct 29, 2005 8:45 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
They (x86 boys) want to roll into IBM territory (Hypervisor in Power5
boxes).

nonsense. virtualization was popular in the mainframe world precisely
because mainframes were a huge investment. of course it made sense to
virtualize them, purely in order to make time-slicing more seamless.

killer micros changed all that - a very fast cpu now costs 3 digits,
not 7, and virtualizing it doesn't make much sense, at least not
virtualizing it much. yes, there will probably always be mainframe
recidivists who want to be able to partition a nice 256-core NUMA box
into piddly little chunks for each department (which could have been
bought as separate machines for 99% less cost). but that kind of inane
PHBism will always exist.
Back to top
Mark Hahn
Guest





Posted: Sat Oct 29, 2005 9:21 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
And who will optimize? What was the name of AMD compiler again? what, no
compiler? .. great idea
AMD pouring money to GCC guys would be a different story. Thats where AMD
is becoming bigger now, in small linux server boxes.

AFAIKT, compiler optimization doesn't matter that much to mainstream
servers. it's not as if apache is compute-bound, for instance.
in my part of the AMD-loving server market (HPC), compilers _do_
matter, but there are multiple good compilers available. if all our
users had only C/C++ code, we'd consider using nothing but GCC.

Quote:
AMD has been demonstrating a penchant for earthy thinking recently. So

I'd like to see them do a fused-mul-add using xmm registers. I don't know
that it would make that much difference in real code, but it would certainly
help Top500 scores.

Quote:
it wouldn't surprise me if the instructions it comes up with are
designed for practical housekeeping rather than performance glory.
Especially in the server realm. Perhaps instructions to explicitly
share memory and cache contents between processors/cores? Instructions

I'm not quite sure what that means. the address space is inherently
shared, so...

Quote:
for optimizing multiple Hypertransport links. This is apparently as a
result of requests by Sun Microsystems for future feature directions of
Opterons. Of course, none of this would be relevant to stone-age Intel
processors -- they don't have anything like this.

well, if AMD added something like directory-based cache coherence onchip,
it would make a HUGE difference, at least for larger SMP's. it's a bit
hard to tell how relevant that would be for the majority of the market,
though, since SMP's above, say 4 sockets are an extremely rarified market.

in a sense, the trend toward multi-core chips fights the need for smarter
coherency protocols, since quite fast machines can be built with fewer
sockets (and therefore fewer hops during the coherence broadcast.)

then again, I've always wondered why AMD didn't just produce, say,
an 8-port HT "bridge" that contained a smart crossbar inside.

how about some form of SMT for AMD?
Back to top
YKhan
Guest





Posted: Sun Oct 30, 2005 6:38 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Mark Hahn wrote:
Quote:
it wouldn't surprise me if the instructions it comes up with are
designed for practical housekeeping rather than performance glory.
Especially in the server realm. Perhaps instructions to explicitly
share memory and cache contents between processors/cores? Instructions

I'm not quite sure what that means. the address space is inherently
shared, so...

Not really, remember AMD's architecture is in actual fact a NUMA, even
though it would want everyone to forget that and treat it like an SMP.
So some memory is local to one processor, and some is local to another.
If it added instructions to explicitly prefetch data from another
processor then it would probably have a gain in performance.

Quote:

for optimizing multiple Hypertransport links. This is apparently as a
result of requests by Sun Microsystems for future feature directions of
Opterons. Of course, none of this would be relevant to stone-age Intel
processors -- they don't have anything like this.

well, if AMD added something like directory-based cache coherence onchip,
it would make a HUGE difference, at least for larger SMP's. it's a bit
hard to tell how relevant that would be for the majority of the market,
though, since SMP's above, say 4 sockets are an extremely rarified market.

in a sense, the trend toward multi-core chips fights the need for smarter
coherency protocols, since quite fast machines can be built with fewer
sockets (and therefore fewer hops during the coherence broadcast.)

then again, I've always wondered why AMD didn't just produce, say,
an 8-port HT "bridge" that contained a smart crossbar inside.

I guess there wasn't as much demand for it. But also remember that
adding a crossbar would result in a minimum of two hops for all
processor-to-processor interactions. The crossbar itself would be one
of the hops. Under present conditions, Opterons can traverse across any
processors in a four-way system in one hop. In an eight-way system most
are one hop away, while a few are two hops away. In a crossbar
eight-way, all processors are two hops away no matter what.

Quote:
how about some form of SMT for AMD?

I don't know that might come too, but it can't be done as easily as
Hyperthreading. Hyperthreading relied on the Pentium 4's inherent
inefficiency to run a lot of threads simultaneously.
Back to top
Rob Stow
Guest





Posted: Mon Oct 31, 2005 1:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
Under present conditions, Opterons can traverse across any
processors in a four-way system in one hop.

No. Each Opty 8xx has three HT links. If all are used for
interprocessor communications - which would be required for a
one-hop scenario in a 4P box - then none are left over for links
to the outside world.

A typical 4P Opty scheme is like this, dashed lines = HT links:

CPU2---CPU3
| |
| |
| |
CPU0---CPU1
| |
| |
Chipset Chipset

Hence, there are two hops between the CPU1 and CPU2 and two hops
between CPU0 and CPU3.


Quote:
In an eight-way system most
are one hop away, while a few are two hops away.

No again. This would be the ideal 8P Opty 8xx scheme:

CPU6-----------------CPU7
| \ / |
| \ / |
| CPU4------CPU5 |
| | | |
| | | |
| CPU2------CPU4 |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset


Hence, there are 11 one-hops, 12 two-hops, and 5 three-hops.



Quote:
In a crossbar
eight-way, all processors are two hops away no matter what.

Horus will get you part of the way there. However, Horus only
allows 4 CPUs per Horus chip, so in an 8P system the four CPUs on
one Horus would be two hops away from each other, but would be
three hops away from the four CPUs on the next Horus.

Hence with Horus the mix would be 0 one-hops, 12 two-hops, and 16
three-hops. However, even then an 8P dual-core box with Horus is
still supposed to be slightly better than an 8P non-Horus box, as
claimed here:
http://www.aceshardware.com/read_news.jsp?id=80000550

There is supposedly going to be a 16 processor/32 cores Horus
demo in November at some shindig in Seattle, but I can't remember
where I read that.
Back to top
David Kanter
Guest





Posted: Mon Oct 31, 2005 1:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
well, if AMD added something like directory-based cache coherence onchip,
it would make a HUGE difference, at least for larger SMP's. it's a bit
hard to tell how relevant that would be for the majority of the market,
though, since SMP's above, say 4 sockets are an extremely rarified market.

in a sense, the trend toward multi-core chips fights the need for smarter
coherency protocols, since quite fast machines can be built with fewer
sockets (and therefore fewer hops during the coherence broadcast.)

then again, I've always wondered why AMD didn't just produce, say,
an 8-port HT "bridge" that contained a smart crossbar inside.

I guess there wasn't as much demand for it. But also remember that
adding a crossbar would result in a minimum of two hops for all
processor-to-processor interactions. The crossbar itself would be one
of the hops. Under present conditions, Opterons can traverse across any
processors in a four-way system in one hop. In an eight-way system most
are one hop away, while a few are two hops away. In a crossbar
eight-way, all processors are two hops away no matter what.

I agree with you here, shockingly enough. Especially, since if you
want more compute power, you just slap in dual core MPUs.

Quote:
how about some form of SMT for AMD?

I don't know that might come too, but it can't be done as easily as
Hyperthreading. Hyperthreading relied on the Pentium 4's inherent
inefficiency to run a lot of threads simultaneously.

If you think that any modern MPU is efficient, you are smoking crack.
They all have plenty of unused cycles left on the table (except when
running linpack).

David

David
Back to top
David Hopwood
Guest





Posted: Mon Oct 31, 2005 1:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Rob Stow wrote:
Quote:
In an eight-way system most
are one hop away, while a few are two hops away.

No again. This would be the ideal 8P Opty 8xx scheme:

CPU6-----------------CPU7
| \ / |
| \ / |
| CPU4------CPU5 |
| | | |
| | | |
| CPU2------CPU[3] |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset


Hence, there are 11 one-hops, 12 two-hops, and 5 three-hops.

That's not optimal:

CPU6--------------CPU7
| \_____ ____/ |
| \ / |
| X |
| / \ |
| CPU4---CPU5 |
| | | |
| | | |
| CPU2---CPU3 |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset

11 one-hops, 16 two-hops, and 1 three-hop.

--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Back to top
Oliver S.
Guest





Posted: Mon Oct 31, 2005 9:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
For instance, the x86 interrupt model really needs a re-think ...

-v
Back to top
Stephen Fuld
Guest





Posted: Mon Oct 31, 2005 9:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message
news:Q1e9f.20034$m%6.9255@fe3.news.blueyonder.co.uk...
Quote:
Rob Stow wrote:
In an eight-way system most
are one hop away, while a few are two hops away.

No again. This would be the ideal 8P Opty 8xx scheme:

CPU6-----------------CPU7
| \ / |
| \ / |
| CPU4------CPU5 |
| | | |
| | | |
| CPU2------CPU[3] |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset


Hence, there are 11 one-hops, 12 two-hops, and 5 three-hops.

That's not optimal:

CPU6--------------CPU7
| \_____ ____/ |
| \ / |
| X |
| / \ |
| CPU4---CPU5 |
| | | |
| | | |
| CPU2---CPU3 |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset

11 one-hops, 16 two-hops, and 1 three-hop.

Is there some technical reason behind the limitation to three HT links or
was it a marketing decision? If the latter, then it doesn't seem like it
would be a big deal, if larger systems seems to be a bigger market, to add
another link (or even two). The HT links must be a pretty small amount of
silicon and a small number of pins. Does that make sense?

--
- Stephen Fuld
e-mail address disguised to prevent spam
Back to top
Oliver S.
Guest





Posted: Mon Oct 31, 2005 9:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
And let's say it'll have 32 FP registers instead of just 16 like SSE does.

Of course 32 registers would be better than 16, but I think we're well
behind a critical point with 16 fp-registers. I think these large regis-
ter-sets we see today on newer architectures exist rather because they
are easy to implement in a cpu than because of their necessity; in dif-
ferent words: the benefit of 32 or more registers isn't very high in
most cases, but their cost in terms of the chip-design is rather low
when your register-file shouldn't become too large.
Back to top
Oliver S.
Guest





Posted: Mon Oct 31, 2005 9:15 am    Post subject: Re: AMD to leave x86 behind? Reply with quote

Quote:
If it added instructions to explicitly prefetch data from another
processor then it would probably have a gain in performance.

These instructions wouldn't work better than the prefetching-instructions
currently implemented. I think it would be cleverer to copy hw-scouting
from Sun's upcoming CPUs. HW-scouting is simple to implement if you're
going to have a SMT-core anyway.

Quote:
I guess there wasn't as much demand for it.

Of course not, but AMD might get into that market in the future.
Back to top
Jeremy Linton
Guest





Posted: Mon Oct 31, 2005 11:39 pm    Post subject: Re: AMD to leave x86 behind? Reply with quote

Mark Hahn wrote:
Quote:
then again, I've always wondered why AMD didn't just produce, say,
an 8-port HT "bridge" that contained a smart crossbar inside.
I guess they are waiting to see how horus turns out...

http://www.hypertransport.org/docs/tech/horus_external_white_paper_final.pdf
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, ... 20, 21, 22  Next
Page 2 of 22

 
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