A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » Processors » AMD x86-64 Processors
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Interesting read about upcoming K9 processors



 
 
Thread Tools Display Modes
  #71  
Old July 29th 04, 07:54 PM
Yousuf Khan
external usenet poster
 
Posts: n/a
Default

Bill Davidsen wrote:
People are still doing graduate thesis on NUMA, it's not clear that
more people will mean shorter time to solution. The first cut may
settle for being stable and running well where Ntask = Ncpu. Getting
it wrong means bigtime bad throughput, which is probably an issue,
since there are more mature Linux and Solaris (I'm told) models as
competition.

I think the rest of the steps are pretty well understood and can be
solved in reasonable time. Or course things like keeping the CPU
number in a byte will need work ;-)



I just remembered that pretty soon there will be dual-core Opterons too, so
that in itself will add another level of NUMA to take into account. Internal
chip-connect vs. Hypertransport connect vs. customized board-to-board
connect.

Yousuf Khan


  #72  
Old July 30th 04, 01:14 AM
Stephen Sprunk
external usenet poster
 
Posts: n/a
Default

"Russell Wallace" wrote in message
...
On Wed, 28 Jul 2004 07:45:16 -0500, chrisv
wrote:
"Dean Kent" wrote:
Linux isn't Windows, and therefore is a completely different argument.


Are you being sarcastic?


I don't know whether he's being sarcastic...

I'd be amazed if Win32 was not 64-bit clean
from day one. The industry was a lot more mature at that point, and
hopefully learned from the migration of 16- to 32-bit...


...but I hope you are! :P


NT was 64-bit clean, since the Alpha and MIPS ports seemed to make that a
requirement, as does the upcoming PPC port for Xbox2.

The biggest problems are getting all those 32-bit drivers converted to
64-bit, and getting 32-bit apps to work under a 64-bit OS, neither of which
was a problem for the prior ports (since they were 64-bit only).

Some "apps" like .NET were gratuitously dependent on the register size, and
those will need serious reworking, but the OS core was ported to AMD64 over
a year ago.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

  #73  
Old July 30th 04, 01:15 AM
Stephen Sprunk
external usenet poster
 
Posts: n/a
Default

"Dean Kent" wrote in message
m...
"Yousuf Khan" wrote in message
ers.com...

It would be supremely embarrassing to Microsoft if Sun gets Solaris for
Opteron out before Windows.


My money is on embarassement...


Given MS just announced all AMD64 platforms have slipped to 1Q05,
embarrassment is pretty much a given -- not to mention Linux has been
shipping for AMD64 for over a year.

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

  #74  
Old July 30th 04, 03:42 AM
Keith
external usenet poster
 
Posts: n/a
Default

On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:

"Russell Wallace" wrote in message
...


I'd be amazed if Win32 was not 64-bit clean
from day one. The industry was a lot more mature at that point, and
hopefully learned from the migration of 16- to 32-bit...


...but I hope you are! :P


NT was 64-bit clean, since the Alpha and MIPS ports seemed to make that a
requirement, as does the upcoming PPC port for Xbox2.


I don't know how you could come to any of these conclusions, given the
public information anyway.

The biggest problems are getting all those 32-bit drivers converted to
64-bit, and getting 32-bit apps to work under a 64-bit OS, neither of
which was a problem for the prior ports (since they were 64-bit only).


I agree with the others here. Force the issue by eliminating those who
won't convert. It seems Linux has done a reasonable job of supporting
AMD64 *without* all the resources M$ can bring to bare.

Some "apps" like .NET were gratuitously dependent on the register size,
and those will need serious reworking, but the OS core was ported to
AMD64 over a year ago.


Ah, so we have another conspiracy theory. So you're on the "incompetence"
side?

--
Keith
  #75  
Old July 30th 04, 06:23 AM
Dean Kent
external usenet poster
 
Posts: n/a
Default

"Keith" wrote in message
news

Ah, so we have another conspiracy theory. So you're on the "incompetence"
side?


Some things are designed to be easily portable (such as DB2, perhaps?),
while others are not. The incompetence does not have to be with today's
coders, but could be due to yesterday's designers...

Regards,
Dean


--
Keith



  #76  
Old July 30th 04, 12:50 PM
Tim Shoppa
external usenet poster
 
Posts: n/a
Default

"Ken Hagan" wrote in message ...
chrisv wrote:

Are you being sarcastic? I'd be amazed if Win32 was not 64-bit clean
from day one. The industry was a lot more mature at that point, and
hopefully learned from the migration of 16- to 32-bit...


Surely if Win32 were 64-bit clean, MS wouldn't have had to ship separate
Win64 headers, which they did, to the general horror of everyone who
expected a 64-bit "long".


Many of us have been working with 64-bit desktop CPU's, OS's, and C
compilers for over a decade now. Yeah, there are decisions to be made.
This was hardly the first time this particular decision was made that way.

Tim.
  #77  
Old July 30th 04, 02:51 PM
Stephen Sprunk
external usenet poster
 
Posts: n/a
Default

"Yousuf Khan" wrote in message
gers.com...
I just remembered that pretty soon there will be dual-core Opterons too,

so
that in itself will add another level of NUMA to take into account.

Internal
chip-connect vs. Hypertransport connect vs. customized board-to-board
connect.


Does an OS really need to be aware of the difference between two cores on
the same chip?

Linux has a concept of a NUMA "node", where all of the processors in a node
are considered equivalent. It'll still try to schedule threads on the same
CPU they last ran on, but next it will try other CPUs in the same node
before giving up and sending it to any available node.

IIRC, the code already understands two-CPU nodes, because that is how
Intel's SMT chips are handled. Treating K8 CMP the same way sounds correct,
once AMD releases specs on how to recognize dual-core chips.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

  #78  
Old July 30th 04, 03:09 PM
Stephen Sprunk
external usenet poster
 
Posts: n/a
Default

"Keith" wrote in message
news
On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:
NT was 64-bit clean, since the Alpha and MIPS ports seemed to make that

a
requirement, as does the upcoming PPC port for Xbox2.


Oops, forgot to mention the Itanic port as well.

I don't know how you could come to any of these conclusions, given the
public information anyway.


Assuming MS is at least marginally competent, maintaining source that is
cleanly portable between 32-bit and 64-bit systems is required when they
have versions shipping for both sizes, and have (on and off) ever since NT
was created.

The biggest problems are getting all those 32-bit drivers converted to
64-bit, and getting 32-bit apps to work under a 64-bit OS, neither of
which was a problem for the prior ports (since they were 64-bit only).


I agree with the others here. Force the issue by eliminating those who
won't convert. It seems Linux has done a reasonable job of supporting
AMD64 *without* all the resources M$ can bring to bare.


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.

MS is in another boat; the NT kernel might be portable, but all the other OS
"stuff" and sundry apps may not be, and MS has never had more than one
platform with significant revenue that has forced them to adopt clean coding
practices.

Some "apps" like .NET were gratuitously dependent on the register size,
and those will need serious reworking, but the OS core was ported to
AMD64 over a year ago.


Ah, so we have another conspiracy theory. So you're on the "incompetence"
side?


I am a firm believer in Hanlon's Razor: never attribute to malice what can
be adequately explained by stupidity.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

  #79  
Old July 30th 04, 03:52 PM
Yousuf Khan
external usenet poster
 
Posts: n/a
Default

Stephen Sprunk wrote:
Does an OS really need to be aware of the difference between two
cores on the same chip?

Linux has a concept of a NUMA "node", where all of the processors in
a node are considered equivalent. It'll still try to schedule
threads on the same CPU they last ran on, but next it will try other
CPUs in the same node before giving up and sending it to any
available node.

IIRC, the code already understands two-CPU nodes, because that is how
Intel's SMT chips are handled. Treating K8 CMP the same way sounds
correct, once AMD releases specs on how to recognize dual-core chips.


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

Yousuf Khan


  #80  
Old July 30th 04, 04:03 PM
Ken Hagan
external usenet poster
 
Posts: n/a
Default

Regarding Microsoft's decision to keep "long" at 32-bits for Win64...


Tim Shoppa wrote:

Many of us have been working with 64-bit desktop CPU's, OS's, and C
compilers for over a decade now. Yeah, there are decisions to be
made.
This was hardly the first time this particular decision was made that
way.


Ah, then I've just benefitted from the venerable maxim that the fastest
way to learn anything is to post wrong information to Usenet. I was
under the impression that everyone else had jumped the other way on this
one.

I am also under the impression that sticking to 32 bits hasn't actually
helped MS achieve their aims of source portability, since the rules on
MSDN suggest *very* strongly to me that all client code has to be
re-written to use their silly typedefs (like INT_PTR and LONG_PTR) in
any case. Therefore, the only consequence of the 32-bit long has been to
make it impossible to write C89 or C++98 code for that platform.

Doubtless you or someone else will now disabuse me of that opinion as
well.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Harddisks: Seek, Read, Write, Read, Write, Slow ? Marc de Vries General 7 July 26th 04 02:57 AM
AMD Processors - HELP! Sseaott Overclocking AMD Processors 1 June 15th 04 09:13 AM
AMD Processors - HELP! Sseaott AMD x86-64 Processors 0 June 15th 04 03:33 AM
Please Read...A Must Read Trini4life2k2 General 1 March 8th 04 01:30 AM
Seagate SATA 120GB raw read errors Kierkecaat General 0 December 16th 03 03:52 PM


All times are GMT +1. The time now is 10:37 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.