Interesting read about upcoming K9 processors

[Stephen Sprunk]

everything."

Now you've got it!

Could that be considered a layman's version of Hanlon's Razor?

Actually it all seems to tie back in to the fact that MS decided to
push all their future OSes back until they get WinXP SP2 out, and that
seems to be taking forever! Each time SP2 gets pushed back everything
else gets pushed back behind it.

This makes a certain amount of sense; why should MS release XP64 in Q4 when
they'll be releasing SP2 (for all platforms) a couple months later? More
released versions means more support and distribution costs.

S

 

[Ken Hagan]

M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
possible at the time they expected their code to be obsolete before
64-bit systems took over -- 4GB is enough for anybody, right? I'm
sure they didn't expect their newly-ported 32-bit code to require
porting again in less than a decade, given 16-bit x86 code had been
around for two decades.

It's not *that* surprising that 64-bit systems are now arriving on
desktops. (But then again, by now it's been more than a decade.)

Back in, ooo, 1990 or thereabouts, I can remember plotting a graph of
memory size in the average bargain bucket PC versus date. OK, they were
my guesses and taken only over a decade, not proper data, but the graph
cut through the 4GB line around 2005. I predicted then that my OS would
be 64-bit, even if none of my applications were. (smug)

 

[Annie Nonimus]

It's not *that* surprising that 64-bit systems are now arriving on
desktops. (But then again, by now it's been more than a decade.)

Back in, ooo, 1990 or thereabouts, I can remember plotting a graph of
memory size in the average bargain bucket PC versus date. OK, they were
my guesses and taken only over a decade, not proper data, but the graph
cut through the 4GB line around 2005. I predicted then that my OS would
be 64-bit, even if none of my applications were. (smug)

Sure hope you don't break your arm patting yourself on the back!

 

[Stephen Sprunk]

I'm sure as a first cut, not treating them specially is the right way to go.
But eventually everybody tries to optimize down to the bone.

From a NUMA-aware scheduler's perspective, what's different between 2-way
SMT and 2-way CMP?

AMD is even suggesting not treating Hypertransport as NUMA but as
simple SMP is quite acceptable, and this suggestion is likely to hold for
dual-cores too (probably even more so).

Once the bugs were worked out, Linux showed much better performance (for 2+
way Opeterons) when it was made NUMA-aware. Treating the system as simple
SMP is acceptable, but demonstrably not optimal.

S

 

[Yousuf Khan]

M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
possible at the time they expected their code to be obsolete before
64-bit systems took over -- 4GB is enough for anybody, right? I'm
sure they didn't expect their newly-ported 32-bit code to require
porting again in less than a decade, given 16-bit x86 code had been
around for two decades. And, given that most programmers don't stay
in the same job for a decade, why would one expect them to plan for
the future (other than style)?

The move from 16-bit to 32-bit Windows was doubly difficult, because of the
need to replace segment-based addressing with linear addressing. That is not
an issue with the 32-bit to 64-bit port. I think people are justifiably
disappointed in MS, because this one should've been smooth as silk. Their
kernel was ported quickly, but nothing else is being ported quickly.

I don't think it's entirely as a result of spaghetti code. I think it's also
as a result of some dufusy arbitrary decisions that MS made. For example,
they decided not support 16-bit protected mode apps in Win64, even though
the AMD64 architecture has no problems running either 16-bit or 32-bit
protected-mode apps in compatibility mode. They've also decided not to allow
the use of x87 FPU under 64-bit mode, relying solely on SSE, even though
AMD64 is perfectly fine with either or both; now I don't know if this is
actually going to be a problem to developers, but it does show that MS is
taking arbitrary decisions. Then it hasn't created a 32-bit to 64-bit device
driver thunking layer, which would've given device driver manufacturers an
additional amount of time to port full 64-bit drivers to Windows.

Yousuf Khan

 

[Yousuf Khan]

1) The usual tactics of .chips denizens who use character
assasination, innuendo and fallacy to present an argument instead of
actually using facts and evidence. Add to that the cries of "I been
wronged" while using uncomplimentary names and implied accusations,
and the pattern is complete.

<big snip>

Please do keep describing yourself perfectly Dean. And please to keep on
tilting at those windmills. Bye.

Yousuf Khan

 

[Seongbae Park]

I think it's also as a result of some dufusy arbitrary decisions that MS made.
For example, ....
They've also decided not to allow
the use of x87 FPU under 64-bit mode, relying solely on SSE, even though
AMD64 is perfectly fine with either or both; now I don't know if this is
actually going to be a problem to developers, but it does show that MS is
taking arbitrary decisions.

...

I think this particular decision is not without its merit,
so calling it arbitrary is too harsh.

It would make some people's life easier immediately
(e.g. compiler, math library, etc)
although I'll have to admit it is debatable how much easier.
In the longer term, they can drop the support in the ISA
to recover opcode space and avoid supporting cost in the chip.
It will take long time to be able to actually gain from this decision
but dropping them now when trasitioning to 64bit ABI
is much easier than trying to do it later.

For example, SPARC ABI should have outright *banned* the use of y register
(sdiv,udiv,rdy, etc) in the new 64bit (v9) or extended 32bit (v8plus),
but they just kept it for compatibility's sake.
They were declared "deprecated" but the new ABI didn't ban the use.
Since sdiv/udiv performed better than sdivx/udivx and was allowed in ABI,
compilers continue to use sdiv/udiv even in v8plus/v9.
And now it's much more difficult to remove.

All in all, I'm always in favor of dropping unnecessary instructions
from ABI - so that it can be dropped from the ISA later.
It's next to impossible to do this
without introducing major pain in the existing ABI,
so this 64bit transition of x86 is a good opportunity to drop
some mistakes of the past.

 

[Yousuf Khan]

From a NUMA-aware scheduler's perspective, what's different between
2-way SMT and 2-way CMP?

It's not really the 2-ways that we're talking about here. We're talking
about the enterprise and datacentre classes, which would range from 4-way to
64-way or more. I think any old memory-organization model would do for 2-way
systems.

Once the bugs were worked out, Linux showed much better performance
(for 2+ way Opeterons) when it was made NUMA-aware. Treating the
system as simple SMP is acceptable, but demonstrably not optimal.

True, but Linux has been around right from the beginning, and they are well
beyond the first-cut stage of their kernel development. They are at the
optimize right down to the bone stage now.

Yousuf Khan

 

[Paul Repacholi]

And then think about how customers would react if told that the ONLY
future platforms for HP-UX, VMS and NonStop had just been cancelled.
Overjoyed isn't the word I would use ....

I supose they could drag out the dead and try to revive the Alpha, or
ask someone else to for VMS. Non-Stop has been advanced so as to
<flashingred>not require a lock-step CPU any more</flashingred>. PHUX
can crawl away and smell in a corner, it has nothing to offer over any
other unix. Less in many cases in fact.

--
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.

 

[Nick Maclaren]

From a NUMA-aware scheduler's perspective, what's different between 2-way
SMT and 2-way CMP?

About ten times as much as the difference between two-way CMP and
dual CPUs on a board?

The point about CMP is that it is merely the latest stage in the
integration of multiple SMP CPUs. Many of us remember when each
such CPU was in a separate box and built out of multiple boards!
There is, however, little logical difference between them and two
CPUs on a die - the only question is the level at which they share
cache (including TLBs).

Eggers-style SMT is entirely different, and the two cores CAN'T be
scheduled as if they were separate CPUs. The timing issues are a
problem (think NTP), the Pentium 4 has the problem of a single set
of performance registers, but those pale into insignificance compared
with the problem of the mode of one CPU affecting another. I don't
know how serious this is for the Pentium 4, as the documents are not
trivially accessible, but there are a lot of place in the public
documents where I mentally raised a flag.

For example, consider the facility to switch between using both cores
and using a single double-speed one. This is not SOLELY decided by
the BIOS, and the first-level interrupt handler has to be aware of
the state and perhaps even control it. That, in turn, affects the
scheduler, because each core may generate an interrupt at any time.


Regards,
Nick Maclaren.

 

[Nick Maclaren]

I supose they could drag out the dead and try to revive the Alpha, or
ask someone else to for VMS. Non-Stop has been advanced so as to
<flashingred>not require a lock-step CPU any more</flashingred>. PHUX
can crawl away and smell in a corner, it has nothing to offer over any
other unix. Less in many cases in fact.

Case (a): Quite.

Case (b): It would be interesting to know if any sacrifice of the
reliability was needed.

Case (c): If true, that is sad. I last used it with HP-UX 9, and
that was a very nice Unix.


Regards,
Nick Maclaren.

 

[Andi Kleen]

From a NUMA-aware scheduler's perspective, what's different between 2-way
SMT and 2-way CMP?

The two cores in CMP are pretty independent. They have a shared
connection to the memory which causes some dependence, but that can be
ignored for scheduling because it is equivalent to the shared FSB in
most SMP systems and fair enough.

The threads in SMT slow each other down, which the scheduler may
want to take into account. Otherwise you get into situations where
low priority processes can slow down high priority processes.

Some SMT implementations like IBM's support setting priorities in
the hardware, but Intel's doesn't support that, so software has
to handle it.

Once the bugs were worked out, Linux showed much better performance (for 2+
way Opeterons) when it was made NUMA-aware. Treating the system as simple
SMP is acceptable, but demonstrably not optimal.

No, that's wrong. In fact we turned off the old NUMA scheduler support on
Opteron because it even made things worse. It was aimed at big NUMA
machines with slow interconnect, where low node balance rates
are good. But on a Opteron you want a fast NUMA balance rate,
it is best to treat it nearly like an SMP.

The new current Linux 2.6 kernel uses the new NUMA scheduler, but
it is still subject to more tuning and it may get turned off again.

-Andi

 

[kal]

as a result of some dufusy arbitrary decisions that MS made. For example,
they decided not support 16-bit protected mode apps in Win64, even though
the AMD64 architecture has no problems running either 16-bit or 32-bit
protected-mode apps in compatibility mode.

I am not sure this is accurate. The issue with win16 is that some of
it still depends on the DOS (for file system etc.) so it needs the
virtual x86 mode too which is not supported in AMD64. So it is really
a technical issue which may also have been solved but that's another
topic.

 

[George Macdonald]

We've now even dug up some old historical webpages (possibly written in
parchment or papyrus or something) from the early days of the commercial
Internet which states exactly why we thought Intel's plans were to go
towards IA-64. Yet, he still needs to argue. Some people are just beyond
quixotic!

I'd really like to find the original charts though -- multi-line graphs in
the typical Intel roadmap style -- which showed x86/IA32 petered out by
2005 in the PC space. They seem to be as extant as the success stories of
the notorious Intel i8089... though at least it did not have a coupla
billion $$ of "support" to prop it up.

Apparently he also thinks that insults in Latin phraseology cadged from his
favorite look-up table are somehow umm, dignified?... exempt from
contempt?

At least I have had some success here... by having the extreme honor of
being killfiled and I suggest that the rest of you do your best to get
equal status from the err, Kentster!... before he skulks back off to his
UnReal World". Good luck with it... I can tell ya - it ain't easy.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[George Macdonald]

I'm sure most or even all of us remember these things.

Some of the problem is in semantics: introduction, general
availability, wide use, replacement. I take "replacing" to
mean that IA32 is no longer available, and IA64 is used
in all cases including embeded devices.

Nope and it's been stated umpteen times: the err, "semantics" are the
existence of x86 vs. IA64, in the *Intel* view circa 1998, of the 2005 *PC*
space, desktop in particular, included. The roadmaps I know I saw
specifically nominated x86 for the typical STB space in the mass market at
its PC EOL cycle... in 2005. Hell the 8085 is still a healthy technical
solution in its space.

This is from an investment viewpoint: what I thought
Intel was saying about the evolution of the portions
of their product line that produced the most profit.

But the fact that I think these things is probably rather
uninteresting, since I cannot produce any actual
documents that say the specific things I think will be true ;-)

"Ay, there's the rub".

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Yousuf Khan]

I am not sure this is accurate. The issue with win16 is that some of
it still depends on the DOS (for file system etc.) so it needs the
virtual x86 mode too which is not supported in AMD64. So it is really
a technical issue which may also have been solved but that's another
topic.

I don't think that's been the case since Windows 3.1. That's the version of
Windows that brought the "32-bit file system", which replaced all calls to
DOS and BIOS with protected mode Windows ones. Even if the app made a direct
call to DOS or BIOS, the 32-bit FS would handle the call.

Yousuf Khan

 

[Yousuf Khan]

Apparently he also thinks that insults in Latin phraseology cadged
from his favorite look-up table are somehow umm, dignified?... exempt
from contempt?

At least I have had some success here... by having the extreme honor
of being killfiled and I suggest that the rest of you do your best to
get
equal status from the err, Kentster!... before he skulks back off to
his UnReal World". Good luck with it... I can tell ya - it ain't
easy.

It's too bad that his first act in coming back to the newsgroups is to try
to show that he's some kind of alpha male all over again, by picking fights.
And unfortunately he continuously picks fights over dead horses too.

Does it really matter if Intel didn't explicitly say that it was going to
kill x86? Of course, it's never going to say anything definitively about
something so far away, so there will always be plenty of wiggle room. Any
intelligent person can surmise that when the roadmap shows clear paths for
IA-64, but not so much for IA-32 that perhaps it was not expecting much to
happen beyond a certain point for that path. Intel's older roadmaps ended at
Foster and Northwood, but just kept going for Itanium. Saying, "we envision
we will continue making x86 processors into the future", is just a standard
"notwithstanding" clause.

Yousuf Khan

 

[Dean Kent]

It's too bad that his first act in coming back to the newsgroups is to try
to show that he's some kind of alpha male all over again, by picking fights.
And unfortunately he continuously picks fights over dead horses too.

Again - the tactic is to use name calling, character assasination and
innuendo. I didn't pick a fight, I took an opposing opinion which some
people attacked and got personal over. If you don't like my opinions, tough
shit. I'm sure there are plenty of others. I seem to be having a nice
conversation with a number of others on the issue - so perhaps the problem
isn't mine after all.

What surprises me is that you, and Keith, actually subscribe to George's
schoolyard tactics of bullying, baiting and name calling - all the while
claiming that he is the one being attacked. Personally, I am disappointed
and you should be ashamed of yourselves. Yeah, go ahead and yuck it up,
pat yourselves on the back and snicker. You *have* become a group of thugs
pouncing on anyone who dares to oppose your cherished opinions. I'm glad I
don't read your newsgroup anymore - it got far too annoying to see it
degrade. Too bad you have to pollute another I am in.

Does it really matter if Intel didn't explicitly say that it was going to
kill x86? Of course, it's never going to say anything definitively about
something so far away, so there will always be plenty of wiggle room. Any
intelligent person can surmise that when the roadmap shows clear paths for
IA-64, but not so much for IA-32 that perhaps it was not expecting much to
happen beyond a certain point for that path. Intel's older roadmaps ended at
Foster and Northwood, but just kept going for Itanium. Saying, "we envision
we will continue making x86 processors into the future", is just a standard
"notwithstanding" clause.

The statements were made about Intel wanting to eliminate IA-32, and they
continue to be made. I simply asked the questions rather than drinking the
Kool-Aid, and posted my reasons why I think the statements were false. What
I got in response was a bunch of fallacious nonsense about disappearing
roadmaps, recollections and conspiracy theories. When I didn't accept
those as proof, it got personal. Sounds like a personal problem to me that
others can't deal with a difference of opinion. Your problem, not mine.

Regards,
Dean

 

[Sander Vesik]

Then you really don't have a clue about this market. These logos and
the ability to claim compatability mean *everything* to the market. When
was the last time you saw a HPaQ/Dell/IBM/whatever (non-whitebox) that
didn't have a "designed for Win" logo.

ummm.. probably a long time ago. seriously.

 

[Casper H.S. Dik]

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.

It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries. MS Windows for AMD64 has an even greater need to support all
those 32 bit app. Solaris for AMD64 will follow the same route as
Solaris for 64-bit SPARC: dual boot, and the ability to run unchanged 32
bit binaries in the 64 bit environment.

Casper