However, what happens when the operating system does a context switch or some other exception occurs? The latency from saving the processor context is going to go way up as you have to save far more data to memory and then load the same large amount of data in for the new context.
There is no "context-switch" delay. The processor takes exactly the same amount of time doing a context-switch at 64-bits than at 32-bits. Remember that the processor has to do a certain number of clocks per second, and it cannot "fall behind" or get delayed.
Now, if your programmers decide that they want to work on 64bit wide data instead of the 32bit they used to on the old system, you suddenly find that your processor is having to move double the amount of data around there system.. You have to hope that any increases in memory bandwidth the engineers included are enough to cater for this.
If you read the article, you will have noticed that Opteron has an integrated memory controller. In this case, it means the controller was moving data at 2.0Ghz. This adds up to significant increases in performance in the benchmarks, as could be seen by the article.
I think the main thing I'm trying to say is that 64bit computing isn't necessarily faster than 32 bit computing. Indeed, because some of the overheads can be double or quaduple, it can be a performance hit.
Absolutely true. It can be slower (just take a look at Itanium:-), but it shouldn't! Did you even read the article? In most of the benchmarks, the Opteron was even faster than dual-Xeons (although I'm not sure the benchmarks were fully using the additional processor) I didn't see a "performance hit" anywhere in the benchmarks.
This will all but signal the end of IA64, it will at that point probably only be used for HPaq's large servers.
Yamhill was rumored since 2000. The rumors appear to be true, but Intel has been denying it ever since.
The problem is that they committed themselves to Itanium for 64-bits. And, in doing that, they also committed SGI, HP, IBM and a number of other vendors. These vendors will NOT be happy if Itanium is obsoleted later on. HP alone has probably invested more than $1 billion in porting their HP/UX and Tru64 software to Itanium architecture, and there are even some customers that have made the full switch. (I'm not talking small shops here, I'm talking huge corporations which replaced their main servers with Itanium hardware).
I believe that, eventually, Intel will release a Yamhill-type of chip, but not after they get battered to death by the press and technical community out there for not releasing an equivalent-to-Opteron processor. But that will probably not be at least until the end of 2004 or beginning of 2005. So AMD has at least a full year for itself to gather momentum. Which I believe it will.
The above seems to imply that game benchmark results will be better at 64-bit.
With a little tweaking and register optimization, they will be better. You have double-sized registers, and much more general purpose registers. In tight inner loops, being able to complete a loop in 10 vrs 20 clocks makes a hell of a difference.
Now, if those games needed access to many gigabytes of game data, that would be an entirely correct assumption.
We are getting to that point. I believe Doom 3's textures are approaching the gigabyte size, and you need many of those at the same time on memory to be able to correctly display a level. Of course, even if it was not necessary, being able to load up ALL textures to memory will make the game so much more playable. In general, if the RAM is there, gaming companies will find a way to use it to make the game better/faster.
Marcos
Re:Intel's response
on
AMD64 Preview
·
· Score: 4, Interesting
Of course, you can buy a dual-Opteron or even a quad-Opteron TODAY if you want, or you can wait until late this year to buy a Prescott system, which is not 64-bits nor multi-processing.
By the way, did you know Prescott, along with its mobile version Dothan, was delayed because it was dissipating almost 103 watts? For the record, Opteron is dissipating about 60 watts.
- Itanium, Intel's 64-bit chip, uses a totally different architecture (EPIC) from the current Pentium x86 line of chips. This architecture is NOT compatible with x86, so that effectively you need a recompile for existing software work on Itanium. There is an EMULATION mode for x86 in Itanium, which is absolutely unusable according to various sources on the Net. You will DEFINITELY not want to run a game on it. Finally, prices for a low-end 1.0Ghz Itanium chip start at approx $800.
- AMD's Opteron/Athlon64 chips are compatible with everything you are running right now at 32 bits. You can install a complete 32-bit operating system in it, and everything will run just as today, albeit a little bit faster. There is no need for an "emulator". And, of course, you can already use Linux at full-64 bits, available from SuSe, RedHat and Mandrake. Also, Microsoft will release a 64-bit version of XP at the end of the year.
You're right mostly. However, you're taking this totally out of context, the way most Wall Street financial analysts do.
There are usually two sides to a company: The financial side (revenue, income, eps, cash flow, etc) and the market situation side (who are its competitors, how is the market as a whole doing, are there any new products in the pipeline, who is running the company, etc).
In AMD's case, yes, its true the financial situation per se is somewhat problematic, to put it lightly. However, you're totally missing out on two key issues here:
- Opteron and Athlon 64 (64 bits for the masses) - Cooperation (even if unintended) by Microsoft by releasing a x86-64 specific version of their Windows 2003 Server. Upgrade cycle time again folks!
My average weighted price is below $10 anyway, so it would not be very difficult to cross that line in a mid-year or year-end rally, because of the Opteron/Athlon64/Sun/Microsoft.:)
Being an investor in AMD, I'm really happy about the path Intel has chosen to take. My almost 1000 shares of AMD stock will finally be over the water again!!!:)
Intel is committing hara-kiri in my opinion here (thats suicide for honor in Japanese). Similar events return to my memory, and history has proved all these were utterly wrong... (Its sad to acknowledge that I REMEMBER when some of these things happened!:(
- Intel 286 vs 386 (IBM: A 286 is enough for most people...) - IBM Microchannel vs ISA (The same thing) - 'A good programmer should be able to do anything with 1K of memory'. I don't remember the author, but probably someone from IBM in the 60s or 70s.
I totally agree with you..... I only think they shouldn't start behaving like Intel, delaying their products by years..... Hammer was initially slated to come out first half of 2002.:(
What you're saying is true..... AMD only has to get double their current market share (about 40% of the market) to start raking in the millions... and it's wildly undervalued, in my opinion.
I might look into this Abiomed company..... sounds interesting.... I might be a customer in the not-too-distant future!:)
That's very interesting..... AMD is currently about 50% of my portfolio...... NVDA has another 25% or so. I'm thinking on adding to my NVDA and AMD positions, since they're so beaten down..... I'm betting on Hammer becoming a real blockbuster for AMD, so I'm staying put with my shares...:)
Anybody here have stock in AMD? I've been long on the company for like two years now, but it never seems to finally launch the Hammer!!! I was hoping for a christmas release, but that's not gonna happen now...... my stocks will get beaten tomorrow!!!:(
I don't know about you, but I'm deeply indebted to Mr. Gore for his contribution to the world in creating the Internet. Even though I can't vote, since I'm not a US citizen, I couldn't let this opportunity to thank him profusely for what he has done go by.
How about sending the house a well written piece showing the opinion of the slashdot community? It should at least make all of us heard out there, and they should start taking notice... slashdot is no longer an obscure web site.
My recommendation: Get all the higher moderated posts, thread them into a coherent paper, and ask for slashdot community approval before sending it. That ought to get them to think twice about what they are REALLY trying to do.
The illegal material is NOT on slashdot servers... and according to a recent ruling, slashdot has every right to link to those pages, even if they contain "illegal" stuff... I say just let Microsoft deal with it... if they really want to let through with it, then let them sue whoever the owners of the other servers are.
Now, there's an interesting question. Are women as sex-driven as men are? Personally, I don't think so... (maybe the fact I don't know that many women intimately doesn't make me a good judge here). I think that, at least in percentage, a lot more men will go clicking away on some porno ad, than girls. That's not to say women aren't attracted to that sort of thing... they are, but in lesser numbers.
I don't think the fact there's more and more women on the net will ever bring up 2 million porno sites for women... usually, they're not looking for that kind of stuff (at least, I don't think so). The number of porno sites aimed at women would surely grow, but no to the extent porno sites for men have.
Linux, the kernel, will not fork in the foreseeable future, since Linus is maintaining his status as mantainer of the kernel source. And, anyone who doesn't have THE kernel maintained by Linus isn't really Linux.
However, the different distributions, such as RedHat, Caldera, Slackware, have already forked, and have been forked for at least some three years, if I remember correctly. The distributions will have to get in-line with some standard, such as the Linux Standard Base (LSB), so that compatibility among distributions is guaranteed, but that is another entire matter.
This is not to say that compatibility among distributions of packages or applications should not be important. It IS very important. However, Linux, the kernel, is not forking anytime soon. The different distributions, usually based on some GNU/Linux combination, have already forked, and a long time ago at that, so what's the big deal?
I think its an interesting solution, after all your other options have been exhausted... I mean, its not the latest and greatest, but it may just work when nothing else does.
I have a couple of doubts on the subject, though. TCP/IP is inherently a low-latency protocol... (by low-latency, I mean less than 5 minutes). In the case of email, were looking at, potentially, latencies of up to 15 min or more. How would the TCP/IP client or server application handle those? You would have to manually readjust the timeouts in the software before trying out this stuff. I see it as very interesting, though.
I was also thinking... this way of tunneling depends entirely on the mail servers... which sometimes, in some businesses at least, are very, VERY overloaded... adding more to the latency... in contrast, a tunneling solution would almost certainly have a server dedicated to it... making it much faster... oh well, just thinking on the subject.
Determining geographic location is totally out of the question. There are two ways this could be implemented, both of which don't work:
1. You could implement a whois searching mechanism, which, according to the data you registered along with your domain name, would give the address and names of the registrar. However, these fields usually contain intermediary data, not the final user one. It would work for the majority of dialup-ISP users, but not for the directly connected ones.
2. You could try to determine which IPs come from which geographic location, according to initial partitioning of the IP space. It may work in the States, if at all. However, most other countries had to use a fake US business name to start using Internet, since in the beginning foreign country rules weren't totally sorted out. That way, in our little third-world-country, we have ISPs with IPs from Puerto Rico, United States, and other countries, not necessarily our own.
And finally, it really isn't too hard to spoof your own IP into a US one...:)
You hit the nail on the head there... guess I hadn't given enough thought about what really a distribution for an embedded system means.
However, I have to disagree on one thing. If you're doing an embedded system, then you should be doing your OWN distro... not use Motorola's... since an embedded system can have from 10Kb anywhere up to 128Mb flash memory... Motorola should only give the necessary guidelines to build an embedded Linux system... provide GPL'ed drivers, and leave the rest to them.
Just one small question... how many people out there (I mean mass market... newbies) would take those TurboLinux disks that came with their new network cards, repartition and reformat their hard disk just so they can install Linux?
Yeah, I thought so....
On the other hand, this form of mass-distribution (ala AOL floppy disks) should have some impact on TurboLinuxs market share, if not on Linux as a whole.
I know this may be moderated down, supposedly because it's "redundant", but it's something that has to be known.
All right, Motorola does their own distro... is it Debian, or RedHat based? Or none of those? What will happen if you want to work with embedded controllers, using Motorola chips, but don't want to use their own distro? Will you lose technical support?
IMHO, I think hardware manufacturers should just test distros that work correctly with their hardware, issue a hardware driver patch to the kernel so Alan and his gang can merge it into the general kernel, and be done with it. That way, in case anyone is using another XYZ distro and wants to work with Motorola embedded chips, Motorola simply says "Just patch the kernel... the patch is available right here!" And, if they don't know how to do that, they shouldn't be programming an embedded controller, for christ sakes!
Hardware manufacturers should NOT create their own distros... I repeat... Hardware manufacturers should NOT create their own distros... just release a kernel patch, binary driver module, or whatever is best for them. It's the best solution for them (they don't have to manage their own distro), and for everybody else (just download the patch, patch the kernel, recompile it, reboot, and wala! You're done)
If I hurt somebody's feelings, sorry... had to calm down my temper.:)
Of course... I meant the first power-efficient method for producing hydrogen, not one that uses up double the amount of energy the produced hydrogen can generate.
Slashdot Mirror
There is already a Mandrake, SuSe and RedHat versions recompiled for running at full 64 bits under AMD64. Debian should not be too-far off.
However, what happens when the operating system does a context switch or some other exception occurs? The latency from saving the processor context is going to go way up as you have to save far more data to memory and then load the same large amount of data in for the new context.
:-), but it shouldn't! Did you even read the article? In most of the benchmarks, the Opteron was even faster than dual-Xeons (although I'm not sure the benchmarks were fully using the additional processor) I didn't see a "performance hit" anywhere in the benchmarks.
There is no "context-switch" delay. The processor takes exactly the same amount of time doing a context-switch at 64-bits than at 32-bits. Remember that the processor has to do a certain number of clocks per second, and it cannot "fall behind" or get delayed.
Now, if your programmers decide that they want to work on 64bit wide data instead of the 32bit they used to on the old system, you suddenly find that your processor is having to move double the amount of data around there system.. You have to hope that any increases in memory bandwidth the engineers included are enough to cater for this.
If you read the article, you will have noticed that Opteron has an integrated memory controller. In this case, it means the controller was moving data at 2.0Ghz. This adds up to significant increases in performance in the benchmarks, as could be seen by the article.
I think the main thing I'm trying to say is that 64bit computing isn't necessarily faster than 32 bit computing. Indeed, because some of the overheads can be double or quaduple, it can be a performance hit.
Absolutely true. It can be slower (just take a look at Itanium
This will all but signal the end of IA64, it will at that point probably only be used for HPaq's large servers.
Yamhill was rumored since 2000. The rumors appear to be true, but Intel has been denying it ever since.
The problem is that they committed themselves to Itanium for 64-bits. And, in doing that, they also committed SGI, HP, IBM and a number of other vendors. These vendors will NOT be happy if Itanium is obsoleted later on. HP alone has probably invested more than $1 billion in porting their HP/UX and Tru64 software to Itanium architecture, and there are even some customers that have made the full switch. (I'm not talking small shops here, I'm talking huge corporations which replaced their main servers with Itanium hardware).
I believe that, eventually, Intel will release a Yamhill-type of chip, but not after they get battered to death by the press and technical community out there for not releasing an equivalent-to-Opteron processor. But that will probably not be at least until the end of 2004 or beginning of 2005. So AMD has at least a full year for itself to gather momentum. Which I believe it will.
The above seems to imply that game benchmark results will be better at 64-bit.
With a little tweaking and register optimization, they will be better. You have double-sized registers, and much more general purpose registers. In tight inner loops, being able to complete a loop in 10 vrs 20 clocks makes a hell of a difference.
Now, if those games needed access to many gigabytes of game data, that would be an entirely correct assumption.
We are getting to that point. I believe Doom 3's textures are approaching the gigabyte size, and you need many of those at the same time on memory to be able to correctly display a level. Of course, even if it was not necessary, being able to load up ALL textures to memory will make the game so much more playable. In general, if the RAM is there, gaming companies will find a way to use it to make the game better/faster.
Marcos
Of course, you can buy a dual-Opteron or even a quad-Opteron TODAY if you want, or you can wait until late this year to buy a Prescott system, which is not 64-bits nor multi-processing.
By the way, did you know Prescott, along with its mobile version Dothan, was delayed because it was dissipating almost 103 watts? For the record, Opteron is dissipating about 60 watts.
Marcos
Just to set some things straight:
- Itanium, Intel's 64-bit chip, uses a totally different architecture (EPIC) from the current Pentium x86 line of chips. This architecture is NOT compatible with x86, so that effectively you need a recompile for existing software work on Itanium. There is an EMULATION mode for x86 in Itanium, which is absolutely unusable according to various sources on the Net. You will DEFINITELY not want to run a game on it. Finally, prices for a low-end 1.0Ghz Itanium chip start at approx $800.
- AMD's Opteron/Athlon64 chips are compatible with everything you are running right now at 32 bits. You can install a complete 32-bit operating system in it, and everything will run just as today, albeit a little bit faster. There is no need for an "emulator". And, of course, you can already use Linux at full-64 bits, available from SuSe, RedHat and Mandrake. Also, Microsoft will release a 64-bit version of XP at the end of the year.
Marcos
I'm planning on reading it over the weekend. Looks like I'll be able to learn a LOT about NASA in the process.
Marcos
You're right mostly. However, you're taking this totally out of context, the way most Wall Street financial analysts do.
:)
There are usually two sides to a company: The financial side (revenue, income, eps, cash flow, etc) and the market situation side (who are its competitors, how is the market as a whole doing, are there any new products in the pipeline, who is running the company, etc).
In AMD's case, yes, its true the financial situation per se is somewhat problematic, to put it lightly. However, you're totally missing out on two key issues here:
- Opteron and Athlon 64 (64 bits for the masses)
- Cooperation (even if unintended) by Microsoft by releasing a x86-64 specific version of their Windows 2003 Server. Upgrade cycle time again folks!
My average weighted price is below $10 anyway, so it would not be very difficult to cross that line in a mid-year or year-end rally, because of the Opteron/Athlon64/Sun/Microsoft.
mjuarez
Being an investor in AMD, I'm really happy about the path Intel has chosen to take. My almost 1000 shares of AMD stock will finally be over the water again!!! :)
:(
Intel is committing hara-kiri in my opinion here (thats suicide for honor in Japanese). Similar events return to my memory, and history has proved all these were utterly wrong... (Its sad to acknowledge that I REMEMBER when some of these things happened!
- Intel 286 vs 386 (IBM: A 286 is enough for most people...)
- IBM Microchannel vs ISA (The same thing)
- 'A good programmer should be able to do anything with 1K of memory'. I don't remember the author, but probably someone from IBM in the 60s or 70s.
Time flies...
I totally agree with you..... I only think they shouldn't start behaving like Intel, delaying their products by years..... Hammer was initially slated to come out first half of 2002. :(
:)
What you're saying is true..... AMD only has to get double their current market share (about 40% of the market) to start raking in the millions...
and it's wildly undervalued, in my opinion.
I might look into this Abiomed company..... sounds interesting.... I might be a customer in the not-too-distant future!
That's very interesting..... AMD is currently about 50% of my portfolio...... NVDA has another 25% or so. I'm thinking on adding to my NVDA and AMD positions, since they're so beaten down..... I'm betting on Hammer becoming a real blockbuster for AMD, so I'm staying put with my shares... :)
Anybody here have stock in AMD? I've been long on the company for like two years now, but it never seems to finally launch the Hammer!!! I was hoping for a christmas release, but that's not gonna happen now...... my stocks will get beaten tomorrow!!! :(
I don't know about you, but I'm deeply indebted to Mr. Gore for his contribution to the world in creating the Internet. Even though I can't vote, since I'm not a US citizen, I couldn't let this opportunity to thank him profusely for what he has done go by.
:)
Excuse me for the "mouth attitude"... just didn't think an anime movie deserved a slashdot headline... :)
Who the hell is princess Mononoke???
How about sending the house a well written piece showing the opinion of the slashdot community? It should at least make all of us heard out there, and they should start taking notice... slashdot is no longer an obscure web site.
My recommendation: Get all the higher moderated posts, thread them into a coherent paper, and ask for slashdot community approval before sending it.
That ought to get them to think twice about what they are REALLY trying to do.
The illegal material is NOT on slashdot servers... and according to a recent ruling, slashdot has every right to link to those pages, even if they contain "illegal" stuff... I say just let Microsoft deal with it... if they really want to let through with it, then let them sue whoever the owners of the other servers are.
:)
We, Slashdot, need not worry.
2 million sites with pictures of naked guys?
Now, there's an interesting question. Are women as sex-driven as men are? Personally, I don't think so... (maybe the fact I don't know that many women intimately doesn't make me a good judge here). I think that, at least in percentage, a lot more men will go clicking away on some porno ad, than girls. That's not to say women aren't attracted to that sort of thing... they are, but in lesser numbers.
I don't think the fact there's more and more women on the net will ever bring up 2 million porno sites for women... usually, they're not looking for that kind of stuff (at least, I don't think so). The number of porno sites aimed at women would surely grow, but no to the extent porno sites for men have.
Linux, the kernel, will not fork in the foreseeable future, since Linus is maintaining his
status as mantainer of the kernel source. And, anyone who doesn't have THE kernel maintained by Linus isn't really Linux.
However, the different distributions, such as RedHat, Caldera, Slackware, have already forked, and have been forked for at least some three years, if I remember correctly. The distributions will have to get in-line with some standard, such as the Linux Standard Base (LSB), so that compatibility among distributions is guaranteed, but that is another entire matter.
This is not to say that compatibility among distributions of packages or applications should not be important. It IS very important. However, Linux, the kernel, is not forking anytime soon. The different distributions, usually based on some
GNU/Linux combination, have already forked, and a long time ago at that, so what's the big deal?
I think its an interesting solution, after all your other options have been exhausted... I mean, its not the latest and greatest, but it may just work when nothing else does.
I have a couple of doubts on the subject, though. TCP/IP is inherently a low-latency protocol... (by low-latency, I mean less than 5 minutes). In the case of email, were looking at, potentially, latencies of up to 15 min or more. How would the TCP/IP client or server application handle those? You would have to manually readjust the timeouts in the software before trying out this stuff. I see it as very interesting, though.
I was also thinking... this way of tunneling depends entirely on the mail servers... which sometimes, in some businesses at least, are very, VERY overloaded... adding more to the latency... in contrast, a tunneling solution would almost certainly have a server dedicated to it... making it much faster... oh well, just thinking on the subject.
Determining geographic location is totally out of the question. There are two ways this could be implemented, both of which don't work:
:)
1. You could implement a whois searching mechanism, which, according to the data you registered along with your domain name, would give the address and names of the registrar. However, these fields usually contain intermediary data, not the final user one. It would work for the majority of dialup-ISP users, but not for the directly connected ones.
2. You could try to determine which IPs come from which geographic location, according to initial partitioning of the IP space. It may work in the States, if at all. However, most other countries had to use a fake US business name to start using Internet, since in the beginning foreign country rules weren't totally sorted out. That way, in our little third-world-country, we have ISPs with IPs from Puerto Rico, United States, and other countries, not necessarily our own.
And finally, it really isn't too hard to spoof your own IP into a US one...
You hit the nail on the head there... guess I hadn't given enough thought about what really a distribution for an embedded system means.
However, I have to disagree on one thing. If you're doing an embedded system, then you should be doing your OWN distro... not use Motorola's... since an embedded system can have from 10Kb anywhere up to 128Mb flash memory... Motorola should only give the necessary guidelines to build an embedded Linux system... provide GPL'ed drivers, and leave the rest to them.
Just one small question... how many people out there (I mean mass market... newbies) would take those TurboLinux disks that came with their new network cards, repartition and reformat their hard disk just so they can install Linux?
Yeah, I thought so....
On the other hand, this form of mass-distribution (ala AOL floppy disks) should have some impact on TurboLinuxs market share, if not on Linux as a whole.
I know this may be moderated down, supposedly
:)
because it's "redundant", but it's something that has to be known.
All right, Motorola does their own distro...
is it Debian, or RedHat based? Or none of those?
What will happen if you want to work with embedded controllers, using Motorola chips, but don't want to use their own distro? Will you lose technical support?
IMHO, I think hardware manufacturers should just test distros that work correctly with their hardware, issue a hardware driver patch to the kernel so Alan and his gang can merge it into the general kernel, and be done with it. That way, in case anyone is using another XYZ distro and wants to work with Motorola embedded chips, Motorola simply says "Just patch the kernel... the patch is available right here!" And, if they don't know how to do that, they shouldn't be programming an embedded controller, for christ sakes!
Hardware manufacturers should NOT create their own distros... I repeat... Hardware manufacturers should NOT create their own distros... just release a kernel patch, binary driver module, or
whatever is best for them. It's the best solution
for them (they don't have to manage their own distro), and for everybody else (just download the patch, patch the kernel, recompile it, reboot, and wala! You're done)
If I hurt somebody's feelings, sorry... had to calm down my temper.
Of course... I meant the first power-efficient method for producing hydrogen, not one that uses up double the amount of energy the produced hydrogen can generate.