In IA32, task switching is supported at the hardware level with the TSS (task state segment). When a context switch occurs, the registers and whatnot are automatically copies to the TSS, and a new task's TSS is copied in. Point being, *all* of the registers are changed after a task switch. End result, additional registers are actually a burden for task switching rather than a benefit.
Unless I'm misunderstanding your point.:-)
I'm pretty sure that the hardware task management stuff has changed drastically under AMD64, and if someone can clarify this it would be useful info...
I agree with most of your post, but just my $0.02 on the last bit:
IMHO the difference between DOS/Win3.1 and *ix/X is vast. Win3.1 attempted to act as the operating environment, not just a windowing system -- the Win16 API had most of the same basic functions as Win32 does today (including File-oriented functions, Network-oriented functions, etc.). X, on the other hand, is *only* a windowing system.
Ironically, I personally think that's a shortcoming of X in some ways. IMHO a new windowing environment needs to be designed that combines at least Graphics/Windowing API, Printing API, Sound API, and probably one or two things I can't think of at the moment. Oh, and it needs to be as configurable by newbies as Windows is (eg. no frigging xorg.conf bull:-).
I imagine we [the Open Source crowd] could build something better than X11 with today's technology if we decided to put our collective intelligence behind it. Hell, it could probably even be X11 backward-compatible.:-)
There are two areas I can think of where this matters greatly -- one is calling conventions as you point out, and the other is register allocation when dealing with code in general (sorry for the imprecise description of the latter, I'm not a compiler guy:-).
In other words, if I have eight 32-bit counter variables used heavily in a short block of code, The AMD64 version should be able to stick them all in regsters and use them. If it's using the IA32 register allocation algorithm though, they'd end up getting swapped around a lot in four or fewer registers.
I'm not saying that MSVC has the latter problem (and in fact I can't imagine that it would), but that's more what I was asking about.:-)
For example, if the application did a lot of integer math, and it was programmed to use 32 bit ints, merely recompiling won't make it use 64 bit ints. In theory, merely being able to use 64 bit ints could double the performance of your application right there (because rather than doing two 32 bit operations, it could do just one 64 bit operation), but that's only if your application knows how to do it.
If you're using gcc's "long long" extension to achieve 64-bitness in 32-bit environments, then recompiling will indeed make your code take advantage of real 64-bitness.
Oh, and longs will automatically become 64-bit as well, so you get a bonus there. Unless you're using them in structures that you're storing directly to disk, in which case you've got work to do.:-)
This pointless message brought to you by my boredom. And now off to bother vendors.
That's largely due to the fact that when the 32-bit OS shift happened, most people already had 32-bit processors in their systems.
I'd expect much the same thing to happen here. Microsoft will wait for proliferation of AMD64/EM64T chips before they make a strong push to 64-bit Windows. I'm actually surprised they've released it at all, personally...
Gentoo would be 100x better if it had more extensive "build profiles." I'd love to say something like "emerge gnome-system" and have it up and build a full system for me with one command -- inclusive of a decent default USE= setting.
In the mean time, I suffer with 2005.1 and constantly adding packages that should really have been included as dependencies in the gnome meta-package (hal and dbus, anyone?). But it *is* more stable than anything else around, IMHO.
And it is *WAY* faster on AMD64 (although going to a dual-core X2 4200+ from a single-core 3500+ didn't seem to smooth the desktop response at all, which I was surprised at -- but compiles are way nicer now:-).
Actually, any 64-bit compiler will automatically use the additional registers. Any compiler that doesn't is just plain stupid. If MSVC doesn't generate good 64-bit code, then use gcc or even icc.
Anyone care to comment on MSVC's capabilities in the 64-bit arena?
...pulling the cord on the serveur while doing a stress test and see what happens...
Been there, done that, many times. I work in Real Environments(tm), where things like this do occasionally happen (and people do end up getting fired for it). The only time I have *ever* had MySQL+InnoDB fail to recover is one instance where there was a hardware issue (specifically, the vendor massively under-specced the power supply on one of our DB hardware platforms).
As for your silly comments about what I might ask myself, again I will repeat: I'm a professional systems architect. I don't ask myself those sorts of questions, as I've seen probably more failure modes than you can imagine. I also am not afraid of spending money to buy Oracle licenses if the project warrants it -- but more often than not, it's overkill.
I'll still use MySQL in a lot of cases. Not all of them (eg. I wouldn't use it in a financial services situation, it's not *that* good), but a lot of them.
As for the dude suggesting WAMP: I'm just shaking my head. If you're gonna use Windows, use technologies that were designed for use with Windows. AMP is not it. Thanks for playing.
Actually, yes, I've stressed the hell out of MySQL (on the order of hundreds of concurrent connections and thousands of TPS, with a highly complex, poorly designed schema at that).
MyISAM tables might suck, I wouldn't know. Using InnoDB as a back-end, however, things tend to work quite well. Oh, and it does things a lot more reasonably than any of the other table types (eg. it has referential integrity, decent tx logs, etc.).
That said, I still wouldn't classify it as a true "Enterprise-ready" solution. Their replication solution, for example, tends to suck. For a departmental database, though, I'd use it without a second thought.
Being monstrous horrible people is far from limited to Americans. If the metric is what we do for the poor and undereducated, then ALL people are monstrous, horrible people.:P
Eh, I just pulled a title off the top of my head, but historical accounts can still be literature (hence the reason it was read in English rather than History....?). Substitute just about anything in there, however, if you don't like that one (Lord of the Flies, anyone?).:-) None of the crap that we read in high school was particularly good.
I will agree that "entertaining" does not necessarily equal "literature". But let me ask you this: do you really think it needs to be "hard" or "boring" or "old" to be literature? I'm an avid reader, and I found most of the stuff we read in high school to be quite old and boring.
It's no wonder so many people have a hard time with reading these days. They weren't taught to enjoy it. But that's another rant for another time.
JKR's books are carefully planned and masterfully written. Any book whose popularity can span age groups like these do is worth looking at. Like it or not, these books will be considered classics, and will likely still be read by children all over fifty years from now.
(Interestingly, the first definition that Google will give you is 'creative writing of recognized artistic value'. Since art is subjective, I'd say that most of the world disagrees with you, and that's fine. The stuff your high school English teacher calls 'literature' is something that I would term 'historic literature'.)
MESI and friends are cache coherency protocols, not processor synchronization protocols -- big difference. LOCK is just as relevant as it ever was for handling atomic operations on multi-processor systems (and is even relevant in a dual core single-socket system).
From include/asm-i386/system.h, for example, the function __cmpxchg uses the lock prefix all over the place. So does anything else that needs atomicity. If you think you can build an OS without it, I dare ya.:-)
Also note that the only CPU dedicated memory (outside of the register file) in a multi-processor system is the caches for each processor. So each AMD processor does have a dedicated link to its own caches, the bandwidth to that cache is reserved for that processor. But caches are relatively small, and switching tasks on a single core will flush out the cache about as much as moving to the other core anyway.
Your original post attempted to make the case that interprocessor HT communications were irrelevant. They're not. And yes, AMD multiprocessor systems connect local memory to each individual processor. Go have a look at the diagrams and spec sheets for a good quad-proc Opteron board if you don't believe me.
The diagram shown in the article you link is a for a dual core processor, not a multi-processor system. The only reason why the dual core design doesn't use HT between the two internal cores is because faster methods are available when you're dealing solely in silicon. The reason for two internal cores sharing the same memory bus is likely a simple package restriction -- these things are pin-compatible with single-core chips, after all.
I'd bet good money that within five or six years we'll start to see multi-core chips with a memory controller per core and individual memory busses exposed outside the package. On-die NUMA. Yummy.
Putting the GPU on the HT bus would be interesting. It would have the negative side effect of causing the GPU to go through the CPU when it needs to access memory. That is because the memory controller is in the CPU on AMD systems. But it would seem that when accessing VRAM, the HT bus speed could be useful.
The negative effect you speak of doesn't really exist. HT is capable of allowing two devices to talk to each other (such as a memory controller and a GPU) without bothering anything else on the bus. It might end up on the same piece of silicon wafer that the CPU lives on, but it'll never disturb or interfere with the CPU any more than an external memory controller would.
Interestingly, the more likely scenario would be dual-ported VRAM that sits on the HT bus, not the GPU itself. Done correctly, both the CPU and the GPU would effectively have full-speed access to the video memory without nasty side effects.
I'd love to see the faces of extreme gamers when that one happened... *calls up nVidia marketing to suggest it* (hint: always go through sales or marketing. Engineering has no real power!).
Interprocessor HT comms? Processors don't talk to each other. Think of the instruction on the processor that accesses the other processor? Can't think of one? There isn't one. Processors only interact through memory. Memory is accessed through the FSB, not HT, even on AMD chips. Thus I don't need interprocessor HT. The chips can snoop each others memory busses just fine.
Look for the LOCK prefix (if memory serves) in x86 assembler. Yes, those CPU's do talk to each other. That said, it's not the point of HyperTransport.
HT is not about the processors talking to each other, it's about the architecture being NUMA in nature. Each processor has its own locally-connected chunk of memory. A smart OS then keeps processes running on the processor closest to the required memory for that process.
This latter item, however, doesn't always work out -- which is where HT comes in. Being able to access another processor's memory at high speeds is critical to performance in a NUMA system. The HT busses don't only link processors to memory, they link processors to other processors, and thus THEIR associated memory.
The FSB is an Intel concept really, don't believe it even exists in AMD64 architecture designs.
Anyway, the net effect of NUMA is that each CPU has its own, full, DEDICATED memory bandwidth to locally attached memory. In the current Intel FSB-style multi-core architectures, the CPUs must fight for bandwidth on a single bus to access that same memory. NUMA as implemented by AMD is vastly faster than Intel's current approach (which is the real win of AMD64 in memory-intensive applications).
I'm guessing Intel will eventually go that route -- it's just a matter of when.
As for GPUs, I'm waiting for nVidia to release a chipset that sticks the GPU directly on the HyperTransport bus. THAT would rock.
I'm not quite sure how I missed windows (not being snippy, just would like a bit of elaboration there).
The theory that I'm putting forth, summed up, is that the costs of Windows development, end-user support, etc. etc. might make the net profit from Windows fairly insignificant. If that's the case (and I can't tell if it is from their financial statements since they don't break it down that way), then they could win big by controlling the applications through purposely conceding control of the OS envrionment. IOW, let the OSS folks do their OS work for them for the most part.
I'm probably totally off-base since I haven't really studied Microsoft's business, but it's an interesting thought to me nonetheless. And you're right, it's a bit off-topic:-)
For FY05, Microsoft reported 30.75% of their revenues as being from "Windows Client", which includes Windows XP, Windows 2000, and Windows Embedded. I'm guessing there's a fair amount of Windows Embedded business, given all the WinPhones out there.
Strategically, it could make a WHOLE lot of sense for M$ to drop Windows as an operating system in the long term, assuming they believe that Linux is a true threat on the desktop in that same long term. If they make their other software and solutions available (all of which would probably end up benefitting in stability and security from a transition to Linux) on Linux, they still have a hell of a business, and suddenly Linux is no longer a threat.
Of course, there's the spectre of OpenOffice, mysql, apache, and so forth, but that's for another time...
Could it be? I wouldn't put it past 'em. Talk about "embrace and extend"...:-)
--S (providing your hair-raisingly frightening thought for the day)
...how would the Linux community react if Microsoft decided to throw the entirety of their Windows budget behind WINE, let the OS be open source, go entirely Linux, and focus on providing things like Microsoft Office on Linux?
I may be completely wrong here, but I am under the current impression that Microsoft Office, SQL Server, and other such things are responsible for the majority of MS's bottom line. Now I need to go look at their reports to find out if that' true.:-)
nitpick: It was a solar system and a planet. At least, in the current time. The singularity will take a while to destroy the rest of one of those solar systems...:-)
(Speaking of which, why was there no time dilation? Odd, given that Other Black-Hole Episode, eh?)
Slashdot Mirror
I just wish that C(++) would finally ditch the vague type names and go with, say (w)char, (un)signed(8|16|32|64) and so on...
--S
Two words for ya: support contract. :-)
--S
In IA32, task switching is supported at the hardware level with the TSS (task state segment). When a context switch occurs, the registers and whatnot are automatically copies to the TSS, and a new task's TSS is copied in. Point being, *all* of the registers are changed after a task switch. End result, additional registers are actually a burden for task switching rather than a benefit.
:-)
Unless I'm misunderstanding your point.
I'm pretty sure that the hardware task management stuff has changed drastically under AMD64, and if someone can clarify this it would be useful info...
--S
I agree with most of your post, but just my $0.02 on the last bit:
:-).
:-)
IMHO the difference between DOS/Win3.1 and *ix/X is vast. Win3.1 attempted to act as the operating environment, not just a windowing system -- the Win16 API had most of the same basic functions as Win32 does today (including File-oriented functions, Network-oriented functions, etc.). X, on the other hand, is *only* a windowing system.
Ironically, I personally think that's a shortcoming of X in some ways. IMHO a new windowing environment needs to be designed that combines at least Graphics/Windowing API, Printing API, Sound API, and probably one or two things I can't think of at the moment. Oh, and it needs to be as configurable by newbies as Windows is (eg. no frigging xorg.conf bull
I imagine we [the Open Source crowd] could build something better than X11 with today's technology if we decided to put our collective intelligence behind it. Hell, it could probably even be X11 backward-compatible.
But I digress...
--S
There are two areas I can think of where this matters greatly -- one is calling conventions as you point out, and the other is register allocation when dealing with code in general (sorry for the imprecise description of the latter, I'm not a compiler guy :-).
:-)
In other words, if I have eight 32-bit counter variables used heavily in a short block of code, The AMD64 version should be able to stick them all in regsters and use them. If it's using the IA32 register allocation algorithm though, they'd end up getting swapped around a lot in four or fewer registers.
I'm not saying that MSVC has the latter problem (and in fact I can't imagine that it would), but that's more what I was asking about.
--S
If you're using gcc's "long long" extension to achieve 64-bitness in 32-bit environments, then recompiling will indeed make your code take advantage of real 64-bitness.
Oh, and longs will automatically become 64-bit as well, so you get a bonus there. Unless you're using them in structures that you're storing directly to disk, in which case you've got work to do.
This pointless message brought to you by my boredom. And now off to bother vendors.
--S
That's largely due to the fact that when the 32-bit OS shift happened, most people already had 32-bit processors in their systems.
I'd expect much the same thing to happen here. Microsoft will wait for proliferation of AMD64/EM64T chips before they make a strong push to 64-bit Windows. I'm actually surprised they've released it at all, personally...
--S
How would you propose telling the difference between a an embedded string and a pointer? I can think of a couple of ways, but they're not pretty. :-)
--S
Gentoo would be 100x better if it had more extensive "build profiles." I'd love to say something like "emerge gnome-system" and have it up and build a full system for me with one command -- inclusive of a decent default USE= setting.
:-).
In the mean time, I suffer with 2005.1 and constantly adding packages that should really have been included as dependencies in the gnome meta-package (hal and dbus, anyone?). But it *is* more stable than anything else around, IMHO.
And it is *WAY* faster on AMD64 (although going to a dual-core X2 4200+ from a single-core 3500+ didn't seem to smooth the desktop response at all, which I was surprised at -- but compiles are way nicer now
--S
Actually, any 64-bit compiler will automatically use the additional registers. Any compiler that doesn't is just plain stupid. If MSVC doesn't generate good 64-bit code, then use gcc or even icc.
Anyone care to comment on MSVC's capabilities in the 64-bit arena?
--S
Been there, done that, many times. I work in Real Environments(tm), where things like this do occasionally happen (and people do end up getting fired for it). The only time I have *ever* had MySQL+InnoDB fail to recover is one instance where there was a hardware issue (specifically, the vendor massively under-specced the power supply on one of our DB hardware platforms).
As for your silly comments about what I might ask myself, again I will repeat: I'm a professional systems architect. I don't ask myself those sorts of questions, as I've seen probably more failure modes than you can imagine. I also am not afraid of spending money to buy Oracle licenses if the project warrants it -- but more often than not, it's overkill.
I'll still use MySQL in a lot of cases. Not all of them (eg. I wouldn't use it in a financial services situation, it's not *that* good), but a lot of them.
As for the dude suggesting WAMP: I'm just shaking my head. If you're gonna use Windows, use technologies that were designed for use with Windows. AMP is not it. Thanks for playing.
--S
Actually, yes, I've stressed the hell out of MySQL (on the order of hundreds of concurrent connections and thousands of TPS, with a highly complex, poorly designed schema at that).
MyISAM tables might suck, I wouldn't know. Using InnoDB as a back-end, however, things tend to work quite well. Oh, and it does things a lot more reasonably than any of the other table types (eg. it has referential integrity, decent tx logs, etc.).
That said, I still wouldn't classify it as a true "Enterprise-ready" solution. Their replication solution, for example, tends to suck. For a departmental database, though, I'd use it without a second thought.
--S
I think your last statement there was in error.
:P
Being monstrous horrible people is far from limited to Americans. If the metric is what we do for the poor and undereducated, then ALL people are monstrous, horrible people.
--S
Eh, I just pulled a title off the top of my head, but historical accounts can still be literature (hence the reason it was read in English rather than History....?). Substitute just about anything in there, however, if you don't like that one (Lord of the Flies, anyone?). :-) None of the crap that we read in high school was particularly good.
I will agree that "entertaining" does not necessarily equal "literature". But let me ask you this: do you really think it needs to be "hard" or "boring" or "old" to be literature? I'm an avid reader, and I found most of the stuff we read in high school to be quite old and boring.
It's no wonder so many people have a hard time with reading these days. They weren't taught to enjoy it. But that's another rant for another time.
JKR's books are carefully planned and masterfully written. Any book whose popularity can span age groups like these do is worth looking at. Like it or not, these books will be considered classics, and will likely still be read by children all over fifty years from now.
(Interestingly, the first definition that Google will give you is 'creative writing of recognized artistic value'. Since art is subjective, I'd say that most of the world disagrees with you, and that's fine. The stuff your high school English teacher calls 'literature' is something that I would term 'historic literature'.)
--S
They're a helluva lot better than half the "literature" I read in high school... I mean, c'mon, Grapes of frickin' Wrath? Hello?
If you think they're childrens' books, you're mistaken. Go read 'em. I've got a closet standing by so you don't have to openly say you like 'em.
--S
From include/asm-i386/system.h, for example, the function __cmpxchg uses the lock prefix all over the place. So does anything else that needs atomicity. If you think you can build an OS without it, I dare ya.
Your original post attempted to make the case that interprocessor HT communications were irrelevant. They're not. And yes, AMD multiprocessor systems connect local memory to each individual processor. Go have a look at the diagrams and spec sheets for a good quad-proc Opteron board if you don't believe me.
Or just check out this link: http://www.devx.com/amd/Article/21979
Or this one for a diagram: http://www.netuxsolutions.com/pdf/Opteron2Pwkstn_
The diagram shown in the article you link is a for a dual core processor, not a multi-processor system. The only reason why the dual core design doesn't use HT between the two internal cores is because faster methods are available when you're dealing solely in silicon. The reason for two internal cores sharing the same memory bus is likely a simple package restriction -- these things are pin-compatible with single-core chips, after all.
I'd bet good money that within five or six years we'll start to see multi-core chips with a memory controller per core and individual memory busses exposed outside the package. On-die NUMA. Yummy.
The negative effect you speak of doesn't really exist. HT is capable of allowing two devices to talk to each other (such as a memory controller and a GPU) without bothering anything else on the bus. It might end up on the same piece of silicon wafer that the CPU lives on, but it'll never disturb or interfere with the CPU any more than an external memory controller would.
Interestingly, the more likely scenario would be dual-ported VRAM that sits on the HT bus, not the GPU itself. Done correctly, both the CPU and the GPU would effectively have full-speed access to the video memory without nasty side effects.
I'd love to see the faces of extreme gamers when that one happened... *calls up nVidia marketing to suggest it* (hint: always go through sales or marketing. Engineering has no real power!).
--S
Maximum performance is what metrics like MIPS and FLOPS are for... They've been around a while.
--S
Look for the LOCK prefix (if memory serves) in x86 assembler. Yes, those CPU's do talk to each other. That said, it's not the point of HyperTransport.
HT is not about the processors talking to each other, it's about the architecture being NUMA in nature. Each processor has its own locally-connected chunk of memory. A smart OS then keeps processes running on the processor closest to the required memory for that process.
This latter item, however, doesn't always work out -- which is where HT comes in. Being able to access another processor's memory at high speeds is critical to performance in a NUMA system. The HT busses don't only link processors to memory, they link processors to other processors, and thus THEIR associated memory.
The FSB is an Intel concept really, don't believe it even exists in AMD64 architecture designs.
Anyway, the net effect of NUMA is that each CPU has its own, full, DEDICATED memory bandwidth to locally attached memory. In the current Intel FSB-style multi-core architectures, the CPUs must fight for bandwidth on a single bus to access that same memory. NUMA as implemented by AMD is vastly faster than Intel's current approach (which is the real win of AMD64 in memory-intensive applications).
I'm guessing Intel will eventually go that route -- it's just a matter of when.
As for GPUs, I'm waiting for nVidia to release a chipset that sticks the GPU directly on the HyperTransport bus. THAT would rock.
--S
But that's not a slashdot-ism, it's actually true, so it doesn't count. :-)
--S
I'm not quite sure how I missed windows (not being snippy, just would like a bit of elaboration there).
:-)
The theory that I'm putting forth, summed up, is that the costs of Windows development, end-user support, etc. etc. might make the net profit from Windows fairly insignificant. If that's the case (and I can't tell if it is from their financial statements since they don't break it down that way), then they could win big by controlling the applications through purposely conceding control of the OS envrionment. IOW, let the OSS folks do their OS work for them for the most part.
I'm probably totally off-base since I haven't really studied Microsoft's business, but it's an interesting thought to me nonetheless. And you're right, it's a bit off-topic
--S
[ Additional Info ]
:-)
For FY05, Microsoft reported 30.75% of their revenues as being from "Windows Client", which includes Windows XP, Windows 2000, and Windows Embedded. I'm guessing there's a fair amount of Windows Embedded business, given all the WinPhones out there.
Strategically, it could make a WHOLE lot of sense for M$ to drop Windows as an operating system in the long term, assuming they believe that Linux is a true threat on the desktop in that same long term. If they make their other software and solutions available (all of which would probably end up benefitting in stability and security from a transition to Linux) on Linux, they still have a hell of a business, and suddenly Linux is no longer a threat.
Of course, there's the spectre of OpenOffice, mysql, apache, and so forth, but that's for another time...
Could it be? I wouldn't put it past 'em. Talk about "embrace and extend"...
--S (providing your hair-raisingly frightening thought for the day)
...how would the Linux community react if Microsoft decided to throw the entirety of their Windows budget behind WINE, let the OS be open source, go entirely Linux, and focus on providing things like Microsoft Office on Linux?
:-)
I may be completely wrong here, but I am under the current impression that Microsoft Office, SQL Server, and other such things are responsible for the majority of MS's bottom line. Now I need to go look at their reports to find out if that' true.
--S
If you feel the need to qualify something as 'not-penis-related', then it's probably penis related. :-)
PIC run up to around 40MHz I think... Therefore it should really be a PIC overclocked to 97MHz and steeped in liquid nitrogen.
--S
nitpick: It was a solar system and a planet. At least, in the current time. The singularity will take a while to destroy the rest of one of those solar systems... :-)
(Speaking of which, why was there no time dilation? Odd, given that Other Black-Hole Episode, eh?)