Future Itanic and Xeon to be socket-compatible
Stephen Sprunk
its Itanium 2 microprocessor, Intel Corp. plans to make future versions of
its Xeon and Itanium processors interchangeable at the socket level, the
company confirmed on Tuesday.
http://www.infoworld.com/article/04/04/06/HNclusterxeon_1.html
This move should significantly reduce the cost of Itanic systems by
leveraging the competition and economy of scale available in the x86 market.
Of course, Intel could totally botch it by trying to tie Xeons to the
Itanic's closed specs, but there's at least some hope they'll get it right
this time. Maybe they'll even use HyperTransport :-)
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
Rupert Pigott
> This move should significantly reduce the cost of Itanic systems by
> leveraging the competition and economy of scale available in the x86 market.
> Of course, Intel could totally botch it by trying to tie Xeons to the
> Itanic's closed specs, but there's at least some hope they'll get it right
> this time. Maybe they'll even use HyperTransport :-)
I remember this argument being put forward when K7s were announced
with Slot-A. AFAICT it never paid off for the Alpha, but it did seem
to have a positive effect on the K7's marketing. :)
If you accept the premise that a lot of apps are constrained by the
memory subsystem, and the memory is on the motherboard, you have to
ask the question : Where is the Itanic price/performance advantage
over the Xeon or Opteron going to come from ?
Sure it might be cheaper than a SPARC or POWER motherboard, but I
figure more than a few folks are going to say "Screw that, I'll get
a Xeon, and get a wider range of software to choose from for less".
I guess Intel could tilt things heavily with their pricing strategy
of Xeon and IA-64 parts though, but that won't help their bottom
line. The Opteron will probably take sales if they price Xeons higher
and if they price the IA-64 lower the margins will be horrible. :/
Cheers,
Rupert
Pete Zaitcev (OTID1)
> Stephen Sprunk wrote:
>
>> This move should significantly reduce the cost of Itanic systems by
>> leveraging the competition and economy of scale available in the x86
>> market. Of course, Intel could totally botch it by trying to tie Xeons
>> to the Itanic's closed specs, but there's at least some hope they'll get
>> it right this time. Maybe they'll even use HyperTransport :-)
>
> I remember this argument being put forward when K7s were announced with
> Slot-A. AFAICT it never paid off for the Alpha, but it did seem to have a
> positive effect on the K7's marketing. :)
Does anyone remember MIPS 4600 which was compatible with some
sort of x86 socket? Whatever happened to that one?
-- Pete
Stephen Sprunk
message news:10813617...@teapot.planet.gong...
> I remember [open standard bus] argument being put forward when K7s
> were announced with Slot-A. AFAICT it never paid off for the Alpha,
> but it did seem to have a positive effect on the K7's marketing. :)
The Alpha never grew to a market size where the effects of an open standard
took hold. The use of the EV7 bus in the K7 was arguably helpful in
bringing in chipset makers; at least one chipset vendor refused to license
the P4 FSB, though they eventually settled with Intel on that.
> If you accept the premise that a lot of apps are constrained by the
> memory subsystem, and the memory is on the motherboard, you have to
> ask the question : Where is the Itanic price/performance advantage
> over the Xeon or Opteron going to come from ?
>
> Sure it might be cheaper than a SPARC or POWER motherboard, but I
> figure more than a few folks are going to say "Screw that, I'll get
> a Xeon, and get a wider range of software to choose from for less".
That's certainly been a factor in the market to date, but the Itanic team
has bet all their chips on improved compilers raising IPC significantly
above what's possible with x86. If this doesn't happen, Itanic is dead any
way you slice it.
> I guess Intel could tilt things heavily with their pricing strategy
> of Xeon and IA-64 parts though, but that won't help their bottom
> line. The Opteron will probably take sales if they price Xeons higher
> and if they price the IA-64 lower the margins will be horrible. :/
I think Intel's idea was to bring down the price of Itanic motherboards, but
keep the chips at the same lofty prices. We'll see how successful that is.
Douglas Siebert
>> I guess Intel could tilt things heavily with their pricing strategy
>> of Xeon and IA-64 parts though, but that won't help their bottom
>> line. The Opteron will probably take sales if they price Xeons higher
>> and if they price the IA-64 lower the margins will be horrible. :/
>I think Intel's idea was to bring down the price of Itanic motherboards, but
>keep the chips at the same lofty prices. We'll see how successful that is.
Intel's got kind of a pricing problem there...
It costs a lot to develop both x86 and Itanium -- but Itanium is spreading
out this fixed cost over far fewer parts. Thanks to AMD, Itanium will
never hit even 1% of the x86 market, so that fixed cost component is 100x
larger for Itanium. Itanium also costs more to produce in terms of
variable costs, since the die is larger and higher reliability standards
imply more expensive testing.
Unfortunately for them, by lowering the prices they lower their gross
margin. If they ship 200-300k Itaniums this year (projections I've
heard) at $2000 ASP, cutting that ASP in half to Xeon levels starts
costing them real money in quantities large enough for Wall Street to
notice and adjust INTC stock price accordingly,
--
Douglas Siebert dsie...@excisethis.khamsin.net
When hiring, avoid unlucky people, they are a risk to the firm. Do this by
randomly tossing out 90% of the resumes you receive without looking at them.
Anton Ertl
>I remember this argument being put forward when K7s were announced
>with Slot-A.
You mean the EV6 bus. I don't think that there were ever Slot- or
Socket-compatible Alpha and AMD CPUs; Slot-A probably did not provide
enough power, and Socket-A is unusable for CPUs with external caches.
> AFAICT it never paid off for the Alpha
Not sure what you mean with pay off. There are certainly Alpha boards
around that use the same chipsets as Socket-A boards. E.g., our
UP1500 has an EV68 CPU, an AMD760 northbridge and an ALI 1543
southbridge. Moreover, I assume that AMD paid some money to
DEC/Compaq for EV6 bus know-how.
>but it did seem
>to have a positive effect on the K7's marketing. :)
I also guess that it had a positive effect on the K7 development cost
and time.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Nick Maclaren
In article <4ebd576d3c1e5ec6...@news.teranews.com>,
"Stephen Sprunk" <ste...@sprunk.org> writes:
|>
|> The Alpha never grew to a market size where the effects of an open standard
|> took hold. The use of the EV7 bus in the K7 was arguably helpful in
|> bringing in chipset makers; at least one chipset vendor refused to license
|> the P4 FSB, though they eventually settled with Intel on that.
It wasn't just the size. Despite the rose-tinted goggle effect
that makes this group regard the Alpha as the acme of RISC designs,
there were a lot of reasons why OEMs didn't like Alpha much.
|> That's certainly been a factor in the market to date, but the Itanic team
|> has bet all their chips on improved compilers raising IPC significantly
|> above what's possible with x86. If this doesn't happen, Itanic is dead any
|> way you slice it.
As I have been saying since about 1995, that was known to be
impossible since before the project was started. If Intel and HP
had also developed a programming language that was visually similar
to C but with at least as much optimisability as the non-deprecated
parts of Fortran 90, it might have been possible.
God alone knows whether that would have succeeded. Anyone who says
that they know for certain doesn't have a clue :-)
|> > I guess Intel could tilt things heavily with their pricing strategy
|> > of Xeon and IA-64 parts though, but that won't help their bottom
|> > line. The Opteron will probably take sales if they price Xeons higher
|> > and if they price the IA-64 lower the margins will be horrible. :/
|>
|> I think Intel's idea was to bring down the price of Itanic motherboards, but
|> keep the chips at the same lofty prices. We'll see how successful that is.
One interesting question is where they will stop. A common socket
is one thing, but common chipsets are what is wanted. And, to make
good use of common chipsets, the Itania and Xeons really need to
have semi-common memory and I/O logic. Given that a significant
cost of developing a server chip is in that area, that would seem
a good idea.
My guess is that we shall see a split between the server designs
(Itania and Xeons) and the fliptop and blade designs, with the
desktop designs being road-kill. Each of the two paths will have
common memory and I/O logic, chipsets and sockets.
Regards,
Nick Maclaren.
Rupert Pigott
> Rupert Pigott <r...@dark-try-removing-this-boong.demon.co.uk> writes:
>
>>I remember this argument being put forward when K7s were announced
>>with Slot-A.
>
>
> You mean the EV6 bus. I don't think that there were ever Slot- or
> Socket-compatible Alpha and AMD CPUs; Slot-A probably did not provide
> enough power, and Socket-A is unusable for CPUs with external caches.
>
>
>>AFAICT it never paid off for the Alpha
>
>
> Not sure what you mean with pay off. There are certainly Alpha boards
Well, it didn't raise shipments to the point where the bean counters
and PHBs figured that it was worth saving. Perhaps they really would
have killed Alpha anyway even if it did have a big percentage of the
server market, who knows ? Some might say who cares ? FWIW I do care
because I enjoyed working with the Alpha - even if others didn't. :)
Cheers,
Rupert
Nate D. Tuck
Douglas Siebert <dsie...@excisethis.khamsin.net> wrote:
>It costs a lot to develop both x86 and Itanium -- but Itanium is spreading
>out this fixed cost over far fewer parts. Thanks to AMD, Itanium will
>margin. If they ship 200-300k Itaniums this year (projections I've
>heard) at $2000 ASP, cutting that ASP in half to Xeon levels starts
Are you implying that Itanium costs >$1000 to produce? The R&D is already
spent money. Presumeably if they are cutting prices it is because they
think they can make more money that way.
I would be shocked if Intel was not making money over production costs even
at $1K/Itanium. Whether they have recouped their R&D is another question.
nate
Douglas Siebert
ASP == Average Selling Price. I'm not making any claims how much it costs
them to produce Itanium, anyone who knows that with any level of certainty
isn't allowed to say anything.
I was merely claiming that if they lower Itanium prices to Xeon levels,
Itanium will be much less profitable than Xeon because the development
costs, which are similar between the two (well within the same order of
magnitude, at least) are amortized over sales that are easily an order
of magnitude apart (three orders of magnitude if you consider all x86
chips and not just Xeon)
With Intel's shareholders accustomed to fat gross margins and big profits,
they might not like the dilution of those margins by product lines that
can't pull their weight.
Nick Maclaren
Not just R&D but marketing, slush funds and so on. At the lowest
estimate of the costs that seems plausible, I don't think that they
are even approaching cost recovery. My guess is that they haven't
reached 10% of it yet!
What will be really interesting will be to see whether and how the
IA-64 product line goes forward. There is a very boring upgrade
(i.e. more cache and little else) in the offing, lots of rumours of
a radical new design that will blow everyone's socks off by combining
EPIC, out-of-order and SMT, and the current rumours that Intel are
planning a major revision of their product lines in 2007.
Regards,
Nick Maclaren.
Paul Repacholi
> Rupert Pigott <r...@dark-try-removing-this-boong.demon.co.uk> writes:
>>I remember this argument being put forward when K7s were announced
>>with Slot-A.
> You mean the EV6 bus. I don't think that there were ever Slot- or
> Socket-compatible Alpha and AMD CPUs; Slot-A probably did not
> provide enough power, and Socket-A is unusable for CPUs with
> external caches.
Samsung did a board that could have an Alpha or an AMD. Just swap
processor cards and `bios' flash. The Alpha card had a power feed on
the card, plus the SROM. Socket A happened because lowest possible
price PC vendors wanted to get rid of the Bcache and its traces.
In theory, with the right bios code you could have plugged 4 AMDs
into an ES40 or ES45.
--
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.
Paul Repacholi
> "Rupert Pigott" <r...@dark-try-removing-this-boong.demon.co.uk> wrote in
> message news:10813617...@teapot.planet.gong...
>> I guess Intel could tilt things heavily with their pricing strategy
>> of Xeon and IA-64 parts though, but that won't help their bottom
>> line. The Opteron will probably take sales if they price Xeons
>> higher and if they price the IA-64 lower the margins will be
>> horrible. :/
> I think Intel's idea was to bring down the price of Itanic
> motherboards, but keep the chips at the same lofty prices. We'll
> see how successful that is.
I think intel are moving so when the itanic vanishes they will still
have some value in the servers etc that they will be otherwise left
with.
Stephen Sprunk
news:c530g6$4km$1...@narsil.avalon.net...
> "Stephen Sprunk" <ste...@sprunk.org> writes:
> >I think Intel's idea was to bring down the price of Itanic motherboards,
but
> >keep the chips at the same lofty prices. We'll see how successful that
is.
>
> Unfortunately for them, by lowering the prices they lower their gross
> margin. If they ship 200-300k Itaniums this year (projections I've
> heard) at $2000 ASP, cutting that ASP in half to Xeon levels starts
> costing them real money in quantities large enough for Wall Street to
> notice and adjust INTC stock price accordingly,
It seems you read what I said backwards. The probable goal is to keep
Itanic's ASP sky-high, but reduce the rest of the system cost to (hopefully)
increase volume.
Stephen Sprunk
news:c532j4$9v8$1...@pegasus.csx.cam.ac.uk...
>
> In article <4ebd576d3c1e5ec6...@news.teranews.com>,
> "Stephen Sprunk" <ste...@sprunk.org> writes:
> |> That's certainly been a factor in the market to date, but the Itanic
team
> |> has bet all their chips on improved compilers raising IPC significantly
> |> above what's possible with x86. If this doesn't happen, Itanic is dead
any
> |> way you slice it.
>
> As I have been saying since about 1995, that was known to be
> impossible since before the project was started. If Intel and HP
> had also developed a programming language that was visually similar
> to C but with at least as much optimisability as the non-deprecated
> parts of Fortran 90, it might have been possible.
>
> God alone knows whether that would have succeeded. Anyone who says
> that they know for certain doesn't have a clue :-)
Could you expand on that? It's "common knowledge" that we've reached the
effective limit of extracting parallelism from serial machine code, but is
it also common knowledge that parallel machine code has the same limit for
C? Why is it that Fortran can express better parallelism than C, given the
same effort at compiler optimization?
Nick Maclaren
Stephen Sprunk <ste...@sprunk.org> wrote:
>
>Could you expand on that? It's "common knowledge" that we've reached the
>effective limit of extracting parallelism from serial machine code, but is
>it also common knowledge that parallel machine code has the same limit for
>C? Why is it that Fortran can express better parallelism than C, given the
>same effort at compiler optimization?
Two factors. One is that Fortran is more restrictive than C, and so
the compiler can deduce a lack of aliasing in cases when it can't for
C, and derive related invariants. This is one aspect of the old
flexibility versus optimisability and reliability debate.
The other is the serious ambiguities in C90 that are vastly worse in
C99, and reported to be serious in ISO C++. Practical compilers HAVE
to assume that code will break the rules, because 90% of it does, and
so quite a lot of optimisations have to be downgraded. This is the
cause of lots of applications requiring low levels of optimisation.
Regards,
Nick Maclaren.
Stephen Sprunk
> In article <bea221d08bd85129...@news.teranews.com>,
> Stephen Sprunk <ste...@sprunk.org> wrote:
> >Could you expand on that? It's "common knowledge" that we've
> > reached the effective limit of extracting parallelism from serial
machine
> > code, but is it also common knowledge that parallel machine code has
> > the same limit for C? Why is it that Fortran can express better
> > parallelism than C, given the same effort at compiler optimization?
>
> Two factors. One is that Fortran is more restrictive than C, and so
> the compiler can deduce a lack of aliasing in cases when it can't for
> C, and derive related invariants. This is one aspect of the old
> flexibility versus optimisability and reliability debate.
I keep seeing aliasing come up over and over in comp.arch but I don't have a
grasp of how common it is for there to be _potential_ aliasing which ruins
optimization versus _actual_ aliasing during execution.
If the occurrence is low, couldn't the compiler generate two versions of the
code and select an optimized version at runtime if it can prove there is no
aliasing? EPIC might even execute both versions in parallel, predicated on
whether an alias occurs.
> The other is the serious ambiguities in C90 that are vastly worse in
> C99, and reported to be serious in ISO C++. Practical compilers HAVE
> to assume that code will break the rules, because 90% of it does, and
> so quite a lot of optimisations have to be downgraded. This is the
> cause of lots of applications requiring low levels of optimisation.
Can you give some non-trivial examples in either C90 or C99?
Nick Maclaren
Stephen Sprunk <ste...@sprunk.org> wrote:
>
>I keep seeing aliasing come up over and over in comp.arch but I don't have a
>grasp of how common it is for there to be _potential_ aliasing which ruins
>optimization versus _actual_ aliasing during execution.
Very.
>If the occurrence is low, couldn't the compiler generate two versions of the
>code and select an optimized version at runtime if it can prove there is no
>aliasing? EPIC might even execute both versions in parallel, predicated on
>whether an alias occurs.
Yes. And, when there are two possible forms of aliasing, that is four
codes. When there are three, that is eight. And so on.
>Can you give some non-trivial examples in either C90 or C99?
Eh? Yes. Don't you mean 'trivial but realistic'? Try:
void add (double *a, const double *b, const double *c, int n) {
int i;
for (i = 0; i < n; ++i) a[i] = b[i] +c[i];
}
a, b and c can overlap in any way and any combination. Preloading
is not allowed.
Regards,
Nick Maclaren.
Stephen Sprunk
> In article <cf2bda76ae7f849c...@news.teranews.com>,
> Stephen Sprunk <ste...@sprunk.org> wrote:
> >I keep seeing aliasing come up over and over in comp.arch but I don't
> >have a grasp of how common it is for there to be _potential_ aliasing
> >which ruins optimization versus _actual_ aliasing during execution.
>
> Very.
Okay, that puts the problem in a different perspective; I had been assuming
aliasing was rare but had to be accounted for "just in case".
> void add (double *a, const double *b, const double *c, int n) {
> int i;
> for (i = 0; i < n; ++i) a[i] = b[i] +c[i];
> }
>
> a, b and c can overlap in any way and any combination. Preloading
> is not allowed.
Okay, I don't use functions like that in a way that could cause actual
aliasing (because I don't trust the compiler), but I now understand that
doing so is legal and therefore optimization is difficult.
However, if "a" were declared as a restricted variable, wouldn't the
compiler be free to optimize with the assumption of no aliasing? That
obviously leaves the burden of preventing aliases on the programmer, but
IMHO that's a reasonable tradeoff for faster code.
Andrew Reilly
> Yes. And, when there are two possible forms of aliasing, that is four
> codes. When there are three, that is eight. And so on.
I'm guessing that its not so easy, otherwise it would be common-place.
I would have thought that the "no aliasing in practice" case would be
overwhelmingly the most common, and so a single test (combinatorially
complex, admittedly, but most code does not have _so_ many arguments) and
then two code versions: "no aliasing" and "some aliasing" would be
enough to get all the speed-up that you could want.
I do realize that there's a third option that is probably encountered in
quite a bit of code, which is the "operate in place" aliasing. I.e.,
arguments don't overlap with arbitrary offsets, but *do* overlap
completely. Most of the time you probably can't do better than the
pessimal case there anyway, unless you manually code up an in-place
variant of the routine.
Quite a lot of code must have no aliasing in practice, though, because
"assume no aliasing" compiler switches are common (ubiquitous?).
--
Andrew
Terje Mathisen
> I do realize that there's a third option that is probably encountered in
> quite a bit of code, which is the "operate in place" aliasing. I.e.,
> arguments don't overlap with arbitrary offsets, but *do* overlap
> completely. Most of the time you probably can't do better than the
> pessimal case there anyway, unless you manually code up an in-place
> variant of the routine.
The operate-in-place version is normally identical to no alias case when
generating code, since you can unroll/preload arbitrarily, without
causing any errors.
>
> Quite a lot of code must have no aliasing in practice, though, because
> "assume no aliasing" compiler switches are common (ubiquitous?).
Right, this is often due to what I mentioned in my previous comment,
because using three-operand functions to update one of the inputs is
_very_ common.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Sander Vesik
> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
> news:c595il$1m$1...@pegasus.csx.cam.ac.uk...
> > In article <bea221d08bd85129...@news.teranews.com>,
> > Stephen Sprunk <ste...@sprunk.org> wrote:
> > >Could you expand on that? It's "common knowledge" that we've
> > > reached the effective limit of extracting parallelism from serial
> machine
> > > code, but is it also common knowledge that parallel machine code has
> > > the same limit for C? Why is it that Fortran can express better
> > > parallelism than C, given the same effort at compiler optimization?
> >
> > Two factors. One is that Fortran is more restrictive than C, and so
> > the compiler can deduce a lack of aliasing in cases when it can't for
> > C, and derive related invariants. This is one aspect of the old
> > flexibility versus optimisability and reliability debate.
>
> I keep seeing aliasing come up over and over in comp.arch but I don't have a
> grasp of how common it is for there to be _potential_ aliasing which ruins
> optimization versus _actual_ aliasing during execution.
>
> If the occurrence is low, couldn't the compiler generate two versions of the
> code and select an optimized version at runtime if it can prove there is no
> aliasing? EPIC might even execute both versions in parallel, predicated on
> whether an alias occurs.
This is only really feasible in certain occasions and even so mostly for loops
where this falls under 'dynamic optimisation'.
>
> S
>
--
Sander
+++ Out of cheese error +++
Stefan Monnier
> spent money.
Is it? I thought it was money they are and will be spending on the
next generation of the Itanium line. You can't just discard it.
Stefan
glen herrmannsfeldt
(snip)
>>Unfortunately for them, by lowering the prices they lower their gross
>>margin. If they ship 200-300k Itaniums this year (projections I've
>>heard) at $2000 ASP, cutting that ASP in half to Xeon levels starts
>>costing them real money in quantities large enough for Wall Street to
>>notice and adjust INTC stock price accordingly,
> It seems you read what I said backwards. The probable goal is to keep
> Itanic's ASP sky-high, but reduce the rest of the system cost to (hopefully)
> increase volume.
On eBay there are various itanium items not selling.
Two itanium 733/133 processors, starting bid $50, no bids.
A Prolient DL950 dual 733, 1GB ram, CDROM, LS-120, everything except
a disk drive, no bids, starting bid of $498. It has a quad processor
board, so one could add the two above to it.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=56103&item=3091444574&rd=1
So, how do these compare to equivalently priced x86 machines?
-- glen
glen herrmannsfeldt
> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
> news:c59isl$9s9$1...@pegasus.csx.cam.ac.uk...
>>In article <cf2bda76ae7f849c...@news.teranews.com>,
>>Stephen Sprunk <ste...@sprunk.org> wrote:
>>>I keep seeing aliasing come up over and over in comp.arch but I don't
>>>have a grasp of how common it is for there to be _potential_ aliasing
>>>which ruins optimization versus _actual_ aliasing during execution.
(snip)
>>void add (double *a, const double *b, const double *c, int n) {
>> int i;
>> for (i = 0; i < n; ++i) a[i] = b[i] +c[i];
>>}
>>a, b and c can overlap in any way and any combination. Preloading
>>is not allowed.
> Okay, I don't use functions like that in a way that could cause actual
> aliasing (because I don't trust the compiler), but I now understand that
> doing so is legal and therefore optimization is difficult.
Note that Fortran specifically doesn't allow aliasing like this.
It isn't too unusual for it to come up on comp.lang.fortran.
> However, if "a" were declared as a restricted variable, wouldn't the
> compiler be free to optimize with the assumption of no aliasing? That
> obviously leaves the burden of preventing aliases on the programmer, but
> IMHO that's a reasonable tradeoff for faster code.
You could then write two versions of the subroutine, one that allowed
and one that didn't allow aliasing. Then the caller must be sure to
call the appropriate one.
-- glen
Nick Maclaren
In article <9066af5362309a3f...@news.teranews.com>,
"Stephen Sprunk" <ste...@sprunk.org> writes:
|>
|> Okay, I don't use functions like that in a way that could cause actual
|> aliasing (because I don't trust the compiler), but I now understand that
|> doing so is legal and therefore optimization is difficult.
You might be surprised. It can often occur without you realising it,
when the function you call in turn calls something else. Also, C has
more types of aliasing and similar problems than appears at first
sight.
|> However, if "a" were declared as a restricted variable, wouldn't the
|> compiler be free to optimize with the assumption of no aliasing? That
|> obviously leaves the burden of preventing aliases on the programmer, but
|> IMHO that's a reasonable tradeoff for faster code.
Yes, that is one part of it. But have you read its specification?
And now consider the problem of using restrict when you are passing
a complicated data structure (e.g. a 3-D graph) and operating on
that. Remember that any mistake will mean that you have introduced
a subtle and effectively undiagnosable bug into your code.
Regards,
Nick Maclaren.
Nick Maclaren
In article <pan.2004.04.11....@gurney.reilly.home>,
Andrew Reilly <and...@gurney.reilly.home> writes:
|> On Sat, 10 Apr 2004 19:45:25 +0000, Nick Maclaren wrote:
|> > Yes. And, when there are two possible forms of aliasing, that is four
|> > codes. When there are three, that is eight. And so on.
|>
|> I'm guessing that its not so easy, otherwise it would be common-place.
|> I would have thought that the "no aliasing in practice" case would be
|> overwhelmingly the most common, and so a single test (combinatorially
|> complex, admittedly, but most code does not have _so_ many arguments) and
|> then two code versions: "no aliasing" and "some aliasing" would be
|> enough to get all the speed-up that you could want.
In the case of simple functions, that is so. In the case of more
complex ones, it is less clear-cut. Again, it is the C language
that is the cause of much of the problem, not just what it specifies
but what it doesn't.
|> I do realize that there's a third option that is probably encountered in
|> quite a bit of code, which is the "operate in place" aliasing. I.e.,
|> arguments don't overlap with arbitrary offsets, but *do* overlap
|> completely. Most of the time you probably can't do better than the
|> pessimal case there anyway, unless you manually code up an in-place
|> variant of the routine.
Nice try, but no banana :-) Consider the following:
void fred (double array[], size_t length, double *maximum) {
size_t i;
double d = 0.0;
for (i = 0; i < length; ++i) if (d < array[i]) d = array[i];
*maximum = d;
}
Even in Fortran, it is quite common for such functions to be called
with maximum pointing into array. It will always work, you see.
Until you use a compiler with copy-value-and-return argument passing
for arrays (which have existed). In C, that can't be done - until
you add the restrict! Now think of a distributed memory parallel
implementation ....
|> Quite a lot of code must have no aliasing in practice, though, because
|> "assume no aliasing" compiler switches are common (ubiquitous?).
Common. And they break a hell of a lot of code, so are usually
implemented as "assume no PERVERSE aliasing" rather than "assume
NO aliasing".
Regards,
Nick Maclaren.
Sander Vesik
>
> Common. And they break a hell of a lot of code, so are usually
> implemented as "assume no PERVERSE aliasing" rather than "assume
> NO aliasing".
>
Is this the same as type based aliasing checks or slightly different?
>
> Regards,
> Nick Maclaren.
Nick Maclaren
In article <10818607...@haldjas.folklore.ee>,
Sander Vesik <san...@haldjas.folklore.ee> writes:
|> Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
|> >
|> > Common. And they break a hell of a lot of code, so are usually
|> > implemented as "assume no PERVERSE aliasing" rather than "assume
|> > NO aliasing".
|>
|> Is this the same as type based aliasing checks or slightly different?
There is an overlap, but no more. Nobody knows what the standard
allows or forbids for its type based aliasing, except that it isn't
helpful. Any language that allows a datum to have three incompatible
types, simultaneously, in two different ways is perverse.
The normal, safeish, rules are a combination of assuming that you
don't update (say) doubles as ints, and that character functions
(e.g. memcpy) operate on whole basic types. But they tend to be very
chary of assuming what the programmer does with structure members,
and to regard unions as implying chaos.
There are a lot of widespread operations that break C99's effective
type rules, and a huge number that fall into its ambiguous areas.
Regards,
Nick Maclaren.
Sander Vesik
>
> In article <10818607...@haldjas.folklore.ee>,
> Sander Vesik <san...@haldjas.folklore.ee> writes:
> |> Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> |> >
> |> > Common. And they break a hell of a lot of code, so are usually
> |> > implemented as "assume no PERVERSE aliasing" rather than "assume
> |> > NO aliasing".
> |>
> |> Is this the same as type based aliasing checks or slightly different?
>
> There is an overlap, but no more. Nobody knows what the standard
> allows or forbids for its type based aliasing, except that it isn't
> helpful. Any language that allows a datum to have three incompatible
> types, simultaneously, in two different ways is perverse.
ints, pointers and floats?
>
> The normal, safeish, rules are a combination of assuming that you
> don't update (say) doubles as ints, and that character functions
> (e.g. memcpy) operate on whole basic types. But they tend to be very
> chary of assuming what the programmer does with structure members,
> and to regard unions as implying chaos.
>
Oh. I didn't even think of those :(
> There are a lot of widespread operations that break C99's effective
> type rules, and a huge number that fall into its ambiguous areas.
>
>
> Regards,
> Nick Maclaren.
--
Nick Maclaren
Sander Vesik <san...@haldjas.folklore.ee> wrote:
>>
>> There is an overlap, but no more. Nobody knows what the standard
>> allows or forbids for its type based aliasing, except that it isn't
>> helpful. Any language that allows a datum to have three incompatible
>> types, simultaneously, in two different ways is perverse.
>
>ints, pointers and floats?
Or pretty well any three types you choose. There are the concepts
of allocation type, declaration type, lvalue type and effective
type. In all cases I have thought of, it is possible to have only
three incompatible types at the same time in a correct program,
but that can be done in two different ways.
Regards,
Nick Maclaren.