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. |
|
|
Thread Tools | Display Modes |
#71
|
|||
|
|||
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
|
|||
|
|||
"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
|
|||
|
|||
"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
|
|||
|
|||
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
|
|||
|
|||
"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
|
|||
|
|||
"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
|
|||
|
|||
"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
|
|||
|
|||
"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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|
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 |