AMD64 is an instruction set, or more specifially, it is a 64-bit extension to the IA-32 instruction set (which, in itself, was an extension of the 16-bit x86 instruction set, and so on). AMD64 often goes by the name x86-64, which is the original name for the instruction set early on in the development cycle.
The AMD Opteron is a processor that uses the AMD64 instruction set. It is designed for workstations and servers and can be used in a glueless SMP setup for up to 8 processors (>8 processors is possible but requires extra core logic chips to connect them together). It runs at clock speeds of 1.6GHz up to 2.2GHz (current top speed), has 1MB of L2 cache and 128-bit wide memory controller integrated onto the die, as well as 3 hypertransport links for interprocessor communication and I/O. It is marketed under model numbers such as 140, 246, 848, etc, with the first number indicating the maximum number of processors usuable in an SMP system (1xx chips for uniprocessor systems, 2xx for duals and 8xx for up to 8-way systems) and the second two numbers showing relative performance. Personally I am quite fond of this particular numbering scheme for the processors.
The AMD Athlon64 is another processor that supports the AMD64 instruction set. It is designed for desktops and mobile systems, so it will not work in multiprocessor configurations. Currently it runs at 2.0 or 2.2GHz with 2.4GHz chips on the horizon. They have either 1MB or 512KB of L2 cache, depending on the model, either a 64-bit or 128-bit memory controller (again, depending on the model), and are sold using two main model numbe schemes. The first is for the stock-Athlon64, which are sold as 3000+, 3200+, 3400+, etc. These numbers show a rough approximation of their performance as compared to an Intel P4 running at the 3.0GHz, 3.2GHz and 3.4GHz (AMD may not say this officially, but it's fairly obvious that this is the intention of the model numbers). I don't like this model number scheme too much, but on the other hand I don't find it any better or worse than the totally useless clock speed (MHz or GHz) rating that is traditionally used to sell chips. The second model scheme is for the Athlon64 FX line of chips, a chip targeted at the high-end "enthusiast" market (read: bratty kid gamers with too much of their parents money on their hands). These chips are sold as the Athlon64 FX 51 and the upcoming Athlon64 FX 53, with the numbers merely referencing the relative performance of the chips.
Hope that clears a thing or two up. For more information, RTFA!
Probably only if/when Intel brings out dual processor P4 systems. The market for dual-processor Athlon64 chips, when dual-Opteron's already exist, is pretty much zero. Sure, I'd like one and you would like one, but honestly 99% of the people buying computers won't even consider a dual-processor setup and those that do are mostly looking at the high-end (ie Opteron or Xeon).
So, unless Intel makes dual-capable P4's a checklist item, AMD isn't likely to support it. Of course, the light at the end of the tunnel here is that AMD is seriously considering dual-core processors for the successor to the Opteron/Athlon64. Still 2 years away (and that's assuming AMD sticks to their schedule, which isn't too likely), but could make for a nice buy when that time comes.
What in the hell are you talking about?! The 64-bitness of these chips doesn't change upgradability in any way, shape or form!
It's not like you can take any old Pentium 4 motherboard and drop the latest and greatest processor into it. The first P4 boards were socket 423, then came the socket 478 boards that only supported 400MT/s bus speeds, than the 533MT/s bus speed boards. None of these are capable of supporting the current 800MT/s bus speed P4s, even if they share the same socket, and they certainly aren't going to support the LGA775 P4's that Intel will be introducing in the next 3-6 months.
If you want to buy a new processor you almost always need to buy a new motherboard and new memory to go along with it, particularly if you're talking about upgrading more than a year after the initial purchase. The Athlon64 doesn't change this one bit. Current Socket 754 boards will be supported for about another year with upcoming chips, socket 940 boards will be supported for at least that long with Opteron chips (which are the same price as the Athlon64 FX), and the first batch of Socket 939 boards probably won't support new chips produced more than a year into the future anyway.
Err, the whole point of "Centrino" is marketing, pure and simple.
The term "Centrino" is a 100% pure marketing term. There is absolutely ZERO technology connected to it, it just means that you are using an Intel Pentium M processor with a an Intel motherboard chipset and an Intel wifi chip.
The trick behind all this though is that if you combine those three elements then Intel will give you MUCHO-$$$ for marketing purposes. Last year Intel gave out $300 million to the likes of Toshiba and Dell to market their Centrino laptops I would not be at all surprised if it turned out that it was CHEAPER to add in an Intel WiFi chip than to have no wifi chip at all once you factor in the advertising bonuses. So that $12 Broadcom chip could well be $14 or $15 more expensive than an Intel one.
You mean, like the Opteron? Or the UltraSparc III? Heck, why not just go whole hog and get a HUGE bus like the IBM Power4 has.
Of course, the real key is not how wide the bus is but how much data you can pump through it. As a result, the Opteron and the Pentium 4 have the same data rate to main memory (6.4GB/s) despite the fact that the Opteron has a 128-bit wide bus (but running at 400MT/s) while the P4 has a 64-bit wide bus (running at 800MT/s).
you would require the entire runtime environment and associated DLL's to be available in 64bit mode like DirectX, etc.
That's exactly how Linux for AMD64 does things, it has two separate copies of all the libraries. This is also how Sun did things with Solaris, as seen in the article.
However, Microsoft is taking a different approach. In their 64-bit Windows, they have ONLY 64-bit libraries. The 32-bit code goes through a thunking layer to translate 32-bit library calls to 64-bit ones. There are, of course, some advantages and disadvantages to either method.
The problem is that it's rather difficult to harness the energy you get by burning hydrocarbons. Sure you get lots of energy, but most of it is lost as heat. Internal combustion engines only manage to convert about 1/4 of the total energy produced by burning the hydrocarbons into useful energy. You could probably do better than that when burning fossil fuels in a power plant, but that's another story altogether.
As for you're comments about compressing hydrogen, you obviously didn't read the article and have no clue as to what I was talking about. The article specifically states that they were able to travel 3x further using this process of splitting out the hydrogen from standard diesel fuel. 1 gallon of diesel fuel in a standard tank vs. 1 gallon of diesel fuel in a fuel-cell tank with a membrane to split out the hydrogen.
And what about the natural gas thing? Natural gas is generally stored as a liquid by keeping the temperature low and pressure up. Doing the same thing is just not practical with hydrogen, which would require EXTREMELY low temperatures and high pressures. Sure, it's possible, but not all that practical at this time. You're talking about a VERY LARGE upgrade to the infrastructure.
Extract hydrogen from hydrocarbons and you no longer have the hydrocarbons for use as fuel, so cracking oil costs roughly as much energy as cracking water.
No, no it doesn't take as much energy. When you separate out the hydrogen you get a net gain of energy. Hydrocarbons are at a fairly high energy state, that's why they do things like burn. Water, on the other hand, is at a VERY low energy state, which is why it doesn't do much of anything.
As for burning all the fossil fuels in plants to separate hydrogen from water, you are ignoring one very important problem, getting the hydrogen from the power plants (or processing plants, or wherever) into your car. Hydrogen is a very-lighter-than-air gas, so it needs to be compressed a whole lot to get any meaningful quantity of it moved. Lugging around and storing a bunch of highly pressurized gas is MUCH more difficult than doing the same thing with liquids. Combine that with the total lack of any sort of infrastructure for transporting hydrogen vs. the multi-billion dollar infrastructure in place for transporting gasoline, and you're plan is a real losing proposition.
Besides, why burn hydrocarbons in a power plant if you can get 3x more energy out of them by separating out the hydrogen and using them to power a fuel sell? That was the whole thrust of the article!
Hmm, I might just be rehashing some of the things you've already heard, but...
Here's a short list of some of the main problems with x86:
1. Too few general purpose registers and some restrictions on how they can be used.
2. Stack-based FPU can be a real pain in the ass and you spend a lot of time and effort shuffling data around.
3. Some people don't like x86 assembly.
4. x86 decoders are very complicated and generally kind of messy.
Now, for #1, first off there are lots of renamed registers. Rather than moving data in and out of regular registers, the processors instead move them from the regular visible registers into the hidden rename registers and back again (kinda oversimplied explination there, but that's more or less how it works). This eliminates the penalty of moving the data to and from cache all the time, but you still need to handle extra load and store instructions that wouldn't be necessary if you had more real registers. There are also some restrictions on what registers can be used for which instructions, so they aren't truely "general purpose" registers.
AMD64 (aka x86-64) helps here in two ways. First they double the number of GPRs from 8 to 16, and secondly it eliminates the restrictions on what registers can be used for different instructions.
For #2, the stack-base x87 FPU is a bit of a problem, and there isn't really anything that can be done to easily fix it. So instead it's been replaced. SSE may have started as just a vector engine, but SSE2 is really a full-fledge FPU replacement. For AMD64 FPU code AMD is recommending that everyone use SSE2 exclusively.
For #3, x86 assembly? Well that isn't nearly the problem that it used to be simply because so few people do assembly anymore. Generally speaking processor optimizations have become sufficiently complex and compilers sufficiently smart that you usually don't buy much in terms of performance when you code in assembly. Also some people really do like x86 assembly, so I guess it's just what you get used to (I personally am not a big fan of it).
The x86 decoders, #4 on my list, are always going to be tricky, but Intel has a rather nifty solution in their trace cache. Rather than saving pre-decoded instruction like is normally done with an L1 I-cache, Intel instead stores post-decoded instructions in their trace cache. They still need a decoder, but since 90%+ of their instructions are coming from the trace cache they can use a much simpler/cheaper decoder.
As for the other stuff. RISC and CISC, in my mind, are pretty darn close to the same thing these days. Sure you've got more instructions with CISC chips and more visible registers with RISC chips, but with the decline in assembly programing and renamed registers, these are quickly disapearing as differences. Both chips end up decoding instructions internally anyway and you end up with very similar execuation paths in the end. Basically on the inside they are the same, just dressed up differently.
Lets see here. Alpha only real processor? Alpha was nice, they did a bang-up job designing it and than DEC managed to do a bang-up job driving the company into the ground and taking the processor with it. Interestingly, the Alpha was designed from the ground-up to clock to high speeds. They took the idea that high clock speeds were the way to go to get performance, yet now if you read this thread people are complaining about Intel doing the same thing.
Itanium is the Itanic? Well now that one is a complex issue and perhaps best left for another thread. Suffice it to say though that the Itanium line of processors have yet to find the right market niche in which to live, despite a LARGE sum of money that Intel has invested. In my mind the issue is that Intel is pushing a chip to a problem that demands a system as a solution. No matter how good the chip is, Intel still needs the infrastructure there to support it. They need HP and SGI to provide the systems and support and they nee
Have a look at the list of applications that make up SPEC CINT2000 sometime. I think you'll find that many of those applications ARE what people use in their every day computing.. err, at least if they run *nix. The tests include compiling with GCC, compression with GZip and BZip2 and running Perl. There is also a database test and a couple Place and Route tests, perhaps not normal workloads but certainly things that some people buy faster computers for.
CFP2000 tests are not nearly as common, they are mostly scientific computing tests. Some fluid dynamics stuff, neural net simulations and equation solving libraries of various types, though Mesa (software OpenGL) does get thrown in there.
VIA's chips offer some nice performance on a per-watt metric. Same power consumption as Transmeta but higher performance. They are also DIRT-CHEAP, which is something that Transmeta hasn't caught on to yet and the reason why VIA continues to gain market share while Transmeta continues to lose market share.
As for AMD, they have a few chips. First off there is the AthlonXP-M chips, the best of which have only just slightly higher power consumption (less than 10% higher) and slightly lower performance than the Pentium M, but they sell for a lot less. They also have their Alchemy line of MIPS chips which compete with Intel's StrongARM/XScale chips, albeit not all that successfully (performance and power consumption of the two are very similar, but ARM seems to be really beating out MIPS in most markets).
The Geode is a brand new addition, really just an old Cyrix design that has been sold and resold. It's pretty much unchanged from the old MediaGX that it started it's life as 6+ years ago. It remains to be seen what AMD will do with it. Hopefully they have a few tricks up their sleave.
AMD's mobile chips are nice, not quite as fast as the Pentium M and slightly higher power consumption (they're pretty close though), but cheaper. However.. umm.. "weighs about 2 pounds less"? 2 pounds less than what exactly? Dell's Inspiron 300m notebook with a Pentium M/Centrino setup weighs only 3.0 pounds, 1.3 pounds less than the notebook you linked to. On the other hand, the Inspiron 8600, using the very same Pentium M processor, weighs in at a hefty 6.9lbs.
The processor has basically ZERO connection with the weight of the notebook. The battery, the chassis and the screen all factor in here, but the processor? Those things are only a few grams!
As you correctly guess, the Prescott is a VERY major redesign of the P4 core. This article has pictures of both a Prescott and a Northwood die, and they are VERY different (side note: I'm not sure I buy his whole Prescott = 64-bit thing, but the article does have some useful data about the two chips).
In any case, while the power consumption numbers are all over the place, we do have some firm die-size numbers for the Prescott. If you look at Sandpile's P4 page, you can see that the Prescott is listed as having a 112mm^2 die (90nm node) with ~125M transistors. For comparison, the Northwood has a 131mm^2 die (130nm node) with 55M transistors.
A large chunk of the extra transistor budget is going towards the extra cache (the extra 512KB of L2 cache is a good 30M transistors all on it's own), and cache transistors pack in tightly, so the die size/# of transistors ratio ends up being a bit lower than you might expect from just a straight process shrink.
The Prescott doubles the size of the L1 data cache (from 8K to 16K), increases the size of the trace cache (from 12K uops to 16k uops if my memory serves me correctly), doubled the size of the L2 cache (from 512K to 1024K), eliminates the integer multiply penalties and probably implements a barrel shifter.
It also makes improvements to the TLB and the load and store buffers, it beefs up the SMT (aka "hyperthreading") performances and adds a few extra SSE instructions. Ohh, and it has more rename registers and can have more instructiosn in flight at any given time.
All of the above changes are designed to INCREASE the per-clock performance of the processor. Most of these won't make a big difference, but the bigger caches definitely will help, and help a lot in many applications. A longer branch misprediction penalty will hurt performance a bit, and there are likely a few other changes made that can hurt performance every now and then.
In short, whether the chip is faster or slower will depend a lot on the exact application being used. My guess, after looking at all the data I can find on the chip, is that the Prescott will be about 5% faster, clock for clock, than the Northwood. This is, of course, just a guess. We'll have to wait for another two or three weeks to find out just how it performs.
WTF? Please, just have a look at some IA-64 assembly code! It's NOT pretty, especially if you want it to go fast. You've got to do the whole explicitly parallel thing, manually pack together independent instruction according to what pipelines you want to run them in.
Itanium is NOT a RISC machine like Sparc, not in the least. Sparc is much more closely related to x86 than it is to IA-64. The Itanium is a VLIW chip, or EPIC in Intel-speak. It's a whole different animal altogether.
FWIW, here's a brief article where Intel talks about implementing a bubble-sort in IA-64 assembly vs. the original C. In particular, they start with the code that the Intel C compiler generates and optimizes it. Their final, optimized version of the algorithm is on page 5, and it's anything but easy.
The Opteron increased the number of total stages but didn't increase the branch misprediction penalty.
There's no word yet on whether or not the branch misprediction penalty has changed on the "Prescott" vs. the "Northwood" P4. The "Northwood" has a 28-stage pipeline with a 20-stage branch misprediction penalty. This "30+" stage pipeline of the "Prescott" could refer to either number.
First off, the P4 has about the best branch predictor in the business. The only processor that had a better branch predictor was AMD's K6 (and the NexGen chip from which the design originated).
As for the "slowness" of the P4 vs. the PIII, in many applications the P4 is actually FASTER, clock for clock, than the P3. This was even true back in the days of the "Willamette" P4, and especially true for the "Northwood" P4. Plus the P4 core clocked nearly twice as faster on an identical fab process (2.0GHz vs. 1.13GHz, the top speeds produced for both cores at a 180nm node), so who cares about clock for clock! Dollar for dollar the P4 was WAY faster.
And the broad is better than deep because the CPU is doing many things at once? First off, the CPU can only handle ONE task at any given time unless you support SMT. Intel supports SMT ("hyperthreading in Intel-speak), AMD does not at this time. But more to the point, both broad and deep give you certain advantages and disadvantages with regards to keeping your execution units full, but both requirements end up being pretty similar in the end, ie you need instructions that do not depend on the results of previous instructions.
Now in your third paragraph things start getting really sketchy. First off, AMD's highest market share numbers ever were back in the late 386/early 486 days when they hit 30%. With the K6-2 AMD managed up to about 20% market share. Now they're sitting at about 15-17%, depending on who you ask, and they've been there for a while. The Q4 reports from Intel and AMD tend to suggest that Intel actually gained market share from AMD over the past 3 months, that AMD's average selling price went up a lot more (so theit total revenue is increased more than Intel's).
Of course, the part about AMD's 24-bit FPU must be when the crack really kicking in for the original poster. The K6, like EVERY OTHER FRIGGING X87 FPU EVER PRODUCED, had an 80-bit floating point unit! The K6-III did not make any changes to the FPU (though the K6-2 made a very minor change to how it handled the FXCH instruction, which mainly helped performance in Quake). These chips also did not have any serious compatibility problems, though there were the standard few errata that you get with any modern x86 processor (whether made by Intel, AMD, VIA or anyone else). I can only remember one errata in the K6 line of chips that ever really caused problems, and that was fixed pretty early on with a new stepping to the original K6. There were also timing loop bugs that caused some problems, but that was the result of dumb-ass software, the hardware performed exactly as expected.
The idea of a longer pipeline is that it makes it easier to clock the chip to higher speeds. This is obviously successful for the P4. The highest Intel was able to push the P6 core of the Pentium 3, when using a 180nm manufacturing process, was 1.13GHz. Even then they had to recall their first attempts at 1.13GHz chips and it took them nearly a year to get them working.
On the exact same 180nm manufacturing process Intel was able to crank out 2.0GHz P4s with no trouble at all.
As for 3 times the performance, have you checked out the SPEC numbers? Intel's 1.0B GHz PIII processor managed 457 CINT2000 and 310 CFP2000, while the P4 3.0C GHz managed 1265 CINT and 1229 CFP. So the P4 is actually 2.77 times faster at integer code and 4.08 times faster at floating point code when compared to the PIII. Ok, maybe not a 100% fair test since different compilers were used, but even if you used the newest compilers for the old PIII's you would still get more than a 3 times speed up in floating point code for a 3GHz P4 vs. a 1GHz PIII.
Ironically enough, that's quite accurate for processors!
A 6-stage pipeline with terrible branch prediction and all sorts of holes in it isn't going to do any good at all, while a 30 stage pipeline with great branch prediction (and the P4 does have great branch prediction) and few bubbles or holes (improved SMT, aka hyperthreading, is supposed to help here) will do wonders.
Of course, the real question is now how long the total pipeline is, but the branch mispredict penalty. It should be noted that the "Northwood" P4 has a 28-stage pipeline, but only a 20-stage mispredict penalty. If the "Prescott" has a 30-stage pipeline with a 22-stage mispredict penalty, it isn't exactly a huge change.
A 100% efficient solar panel gives you about 500-1000KW/km^2 during the day, and nothing at night. In North America we consume about 2KW of energy on average throughout the day.
So, let's take a near best-case scenario of putting solar panels on the equator, getting full-intensity (ie noon hour) sun for 12 hours a day, we're still talking about only being able to provide power to 500 people per km^2. For the United State's 270 million people, that works out to 540,000km^2, or about halfway between the size of California and Texas.
Of course, if we were to use real numbers, even with 100% effective solar panels you would need an area MUCH larger than the size of Texas to support out current energy needs.
Note that this isn't even starting to consider the HUGE extra burder to the power grid if we were to try and power all our cars by it like you're suggesting. Our total energy consumption is up around 7 or 8KW/person when you add in non-electrical energy sources (mainly internal combustion engines for vehicles, heating, etc.).
Since there are no wells of molecular hydrogen anywhere on the planet, hydrogen will *always* be only a storage medium, *never* a direct energy source
Err, well unless you count nuclear fussion. I suppose that's a little ways off though!
But the extraction-from-hydrocarbon method has got to go.
Have you got any other suggestions? There are only two widely available sources of hydrogen. The first is water, which is all well and good except that you only ever get out less energy than you put in (ie it's purely an energy transport mechanism, you still need a power plant to provide the electricity in the first place). The second widely available source of hydrogen is in hydrocarbons.
Of course, there are some advantages to getting power from hydrocarbons the fuel cell way instead of internal combustion engines. First off, the real big problem with current energy production is that burning hydrocarbons produces all kinds of sulpher dioxide, nitrogen monoxide/dioxide, etc. By separating out the hydrogen using a membrane you shouldn't get nearly as many of these emissions. Also, if the claim of 3x the efficiency is accurate than it would be a BIG bonus, though most numbers I've heard place the efficiency as being much lower. Finally, a fuel cell powered car would probably work better with regenerative breaking than what you get in current hybrid cars, since you would now just have an all-electrical system instead of a gas motor and an electrical motor. At the very least it should make things easier/cheaper than hybrids.
The nice thing about hydrogen is that you can make it from many different energy-producing processes and ship it fairly easily
Err, actually it's not all that easy to ship hydrogen. It's a gas, and a VERY light gas at that. You really need to compress it a whole lot before you can get any meaningful quantity. You also then have the problem of shipping a lot of highly compressed and highly combustable gas. In short, it's not easy at all. Storing is extremely troublesome for the same reasons. Shipping and storing fossil fuels is MUCH easier.
The wind, wave, and solar power installations that some think will save the world can easily drive an electrolytic converter, for example, and the only byproduct is oxygen
I love wind, solar, wave, etc. energy as much as the enxt guy, but lets face it, they aren't anywhere near capable of providing us with our CURRENT energy needs, let alone the SIGNIFICANTLY higher energy needs if we started doing electrolytic converters for all of our cars!
Err, we may not know "everything" about sound, but it's been a VERY well understood concept for quite some time. As compared to basically every other aspect of physics it's extremely well understood. Sure, there are plenty of tricky issues, particularly things like the accoustics of a room, but even those are concepts that humans have been perfecting for 300+ years.
Sure, we'll learn a few new things here and there, but the chances of any sort of really fundamental change in our understanding of sound happening in the next 100 years is pretty darn slim.
The Soundstorm chip is expected to become a standalone part, though it looks like they're primarily targetting on-board audio rather than add-in cards. I suspect that it will be just a single chip with little other than audio and a hypertransport connection to the outside world.
As for the whole Abit/nVidia falling out story, I don't know where the heck The Inquirer got that news (or was it The Register, the other techno-tabloid). It came just days before Abit announced plans for several nForce-based products, including Athlon64 boards.
As for me, I've found the nForce platform to be by far the easiest to deal with. Simply beating VIA isn't exactly impressing me, I sometimes feel that trained monkeys could produce better drivers than VIA. However I've found the nForce drivers to actually work well consistantly. That's something that I can't say about any other company, including Intel (Intel usually gets there eventually, but their first revision or two for a new chipset are often VERY bad).
Slashdot Mirror
AMD64 is an instruction set, or more specifially, it is a 64-bit extension to the IA-32 instruction set (which, in itself, was an extension of the 16-bit x86 instruction set, and so on). AMD64 often goes by the name x86-64, which is the original name for the instruction set early on in the development cycle.
The AMD Opteron is a processor that uses the AMD64 instruction set. It is designed for workstations and servers and can be used in a glueless SMP setup for up to 8 processors (>8 processors is possible but requires extra core logic chips to connect them together). It runs at clock speeds of 1.6GHz up to 2.2GHz (current top speed), has 1MB of L2 cache and 128-bit wide memory controller integrated onto the die, as well as 3 hypertransport links for interprocessor communication and I/O. It is marketed under model numbers such as 140, 246, 848, etc, with the first number indicating the maximum number of processors usuable in an SMP system (1xx chips for uniprocessor systems, 2xx for duals and 8xx for up to 8-way systems) and the second two numbers showing relative performance. Personally I am quite fond of this particular numbering scheme for the processors.
The AMD Athlon64 is another processor that supports the AMD64 instruction set. It is designed for desktops and mobile systems, so it will not work in multiprocessor configurations. Currently it runs at 2.0 or 2.2GHz with 2.4GHz chips on the horizon. They have either 1MB or 512KB of L2 cache, depending on the model, either a 64-bit or 128-bit memory controller (again, depending on the model), and are sold using two main model numbe schemes. The first is for the stock-Athlon64, which are sold as 3000+, 3200+, 3400+, etc. These numbers show a rough approximation of their performance as compared to an Intel P4 running at the 3.0GHz, 3.2GHz and 3.4GHz (AMD may not say this officially, but it's fairly obvious that this is the intention of the model numbers). I don't like this model number scheme too much, but on the other hand I don't find it any better or worse than the totally useless clock speed (MHz or GHz) rating that is traditionally used to sell chips. The second model scheme is for the Athlon64 FX line of chips, a chip targeted at the high-end "enthusiast" market (read: bratty kid gamers with too much of their parents money on their hands). These chips are sold as the Athlon64 FX 51 and the upcoming Athlon64 FX 53, with the numbers merely referencing the relative performance of the chips.
Hope that clears a thing or two up. For more information, RTFA!
Will we ever have dual athlon64 goodness?
Probably only if/when Intel brings out dual processor P4 systems. The market for dual-processor Athlon64 chips, when dual-Opteron's already exist, is pretty much zero. Sure, I'd like one and you would like one, but honestly 99% of the people buying computers won't even consider a dual-processor setup and those that do are mostly looking at the high-end (ie Opteron or Xeon).
So, unless Intel makes dual-capable P4's a checklist item, AMD isn't likely to support it. Of course, the light at the end of the tunnel here is that AMD is seriously considering dual-core processors for the successor to the Opteron/Athlon64. Still 2 years away (and that's assuming AMD sticks to their schedule, which isn't too likely), but could make for a nice buy when that time comes.
What in the hell are you talking about?! The 64-bitness of these chips doesn't change upgradability in any way, shape or form!
It's not like you can take any old Pentium 4 motherboard and drop the latest and greatest processor into it. The first P4 boards were socket 423, then came the socket 478 boards that only supported 400MT/s bus speeds, than the 533MT/s bus speed boards. None of these are capable of supporting the current 800MT/s bus speed P4s, even if they share the same socket, and they certainly aren't going to support the LGA775 P4's that Intel will be introducing in the next 3-6 months.
If you want to buy a new processor you almost always need to buy a new motherboard and new memory to go along with it, particularly if you're talking about upgrading more than a year after the initial purchase. The Athlon64 doesn't change this one bit. Current Socket 754 boards will be supported for about another year with upcoming chips, socket 940 boards will be supported for at least that long with Opteron chips (which are the same price as the Athlon64 FX), and the first batch of Socket 939 boards probably won't support new chips produced more than a year into the future anyway.
Err, the whole point of "Centrino" is marketing, pure and simple.
The term "Centrino" is a 100% pure marketing term. There is absolutely ZERO technology connected to it, it just means that you are using an Intel Pentium M processor with a an Intel motherboard chipset and an Intel wifi chip.
The trick behind all this though is that if you combine those three elements then Intel will give you MUCHO-$$$ for marketing purposes. Last year Intel gave out $300 million to the likes of Toshiba and Dell to market their Centrino laptops I would not be at all surprised if it turned out that it was CHEAPER to add in an Intel WiFi chip than to have no wifi chip at all once you factor in the advertising bonuses. So that $12 Broadcom chip could well be $14 or $15 more expensive than an Intel one.
You mean, like the Opteron? Or the UltraSparc III? Heck, why not just go whole hog and get a HUGE bus like the IBM Power4 has.
Of course, the real key is not how wide the bus is but how much data you can pump through it. As a result, the Opteron and the Pentium 4 have the same data rate to main memory (6.4GB/s) despite the fact that the Opteron has a 128-bit wide bus (but running at 400MT/s) while the P4 has a 64-bit wide bus (running at 800MT/s).
you would require the entire runtime environment and associated DLL's to be available in 64bit mode like DirectX, etc.
That's exactly how Linux for AMD64 does things, it has two separate copies of all the libraries. This is also how Sun did things with Solaris, as seen in the article.
However, Microsoft is taking a different approach. In their 64-bit Windows, they have ONLY 64-bit libraries. The 32-bit code goes through a thunking layer to translate 32-bit library calls to 64-bit ones. There are, of course, some advantages and disadvantages to either method.
The problem is that it's rather difficult to harness the energy you get by burning hydrocarbons. Sure you get lots of energy, but most of it is lost as heat. Internal combustion engines only manage to convert about 1/4 of the total energy produced by burning the hydrocarbons into useful energy. You could probably do better than that when burning fossil fuels in a power plant, but that's another story altogether.
As for you're comments about compressing hydrogen, you obviously didn't read the article and have no clue as to what I was talking about. The article specifically states that they were able to travel 3x further using this process of splitting out the hydrogen from standard diesel fuel. 1 gallon of diesel fuel in a standard tank vs. 1 gallon of diesel fuel in a fuel-cell tank with a membrane to split out the hydrogen.
And what about the natural gas thing? Natural gas is generally stored as a liquid by keeping the temperature low and pressure up. Doing the same thing is just not practical with hydrogen, which would require EXTREMELY low temperatures and high pressures. Sure, it's possible, but not all that practical at this time. You're talking about a VERY LARGE upgrade to the infrastructure.
Extract hydrogen from hydrocarbons and you no longer have the hydrocarbons for use as fuel, so cracking oil costs roughly as much energy as cracking water.
No, no it doesn't take as much energy. When you separate out the hydrogen you get a net gain of energy. Hydrocarbons are at a fairly high energy state, that's why they do things like burn. Water, on the other hand, is at a VERY low energy state, which is why it doesn't do much of anything.
As for burning all the fossil fuels in plants to separate hydrogen from water, you are ignoring one very important problem, getting the hydrogen from the power plants (or processing plants, or wherever) into your car. Hydrogen is a very-lighter-than-air gas, so it needs to be compressed a whole lot to get any meaningful quantity of it moved. Lugging around and storing a bunch of highly pressurized gas is MUCH more difficult than doing the same thing with liquids. Combine that with the total lack of any sort of infrastructure for transporting hydrogen vs. the multi-billion dollar infrastructure in place for transporting gasoline, and you're plan is a real losing proposition.
Besides, why burn hydrocarbons in a power plant if you can get 3x more energy out of them by separating out the hydrogen and using them to power a fuel sell? That was the whole thrust of the article!
Hmm, I might just be rehashing some of the things you've already heard, but...
Here's a short list of some of the main problems with x86:
1. Too few general purpose registers and some restrictions on how they can be used.
2. Stack-based FPU can be a real pain in the ass and you spend a lot of time and effort shuffling data around.
3. Some people don't like x86 assembly.
4. x86 decoders are very complicated and generally kind of messy.
Now, for #1, first off there are lots of renamed registers. Rather than moving data in and out of regular registers, the processors instead move them from the regular visible registers into the hidden rename registers and back again (kinda oversimplied explination there, but that's more or less how it works). This eliminates the penalty of moving the data to and from cache all the time, but you still need to handle extra load and store instructions that wouldn't be necessary if you had more real registers. There are also some restrictions on what registers can be used for which instructions, so they aren't truely "general purpose" registers.
AMD64 (aka x86-64) helps here in two ways. First they double the number of GPRs from 8 to 16, and secondly it eliminates the restrictions on what registers can be used for different instructions.
For #2, the stack-base x87 FPU is a bit of a problem, and there isn't really anything that can be done to easily fix it. So instead it's been replaced. SSE may have started as just a vector engine, but SSE2 is really a full-fledge FPU replacement. For AMD64 FPU code AMD is recommending that everyone use SSE2 exclusively.
For #3, x86 assembly? Well that isn't nearly the problem that it used to be simply because so few people do assembly anymore. Generally speaking processor optimizations have become sufficiently complex and compilers sufficiently smart that you usually don't buy much in terms of performance when you code in assembly. Also some people really do like x86 assembly, so I guess it's just what you get used to (I personally am not a big fan of it).
The x86 decoders, #4 on my list, are always going to be tricky, but Intel has a rather nifty solution in their trace cache. Rather than saving pre-decoded instruction like is normally done with an L1 I-cache, Intel instead stores post-decoded instructions in their trace cache. They still need a decoder, but since 90%+ of their instructions are coming from the trace cache they can use a much simpler/cheaper decoder.
As for the other stuff. RISC and CISC, in my mind, are pretty darn close to the same thing these days. Sure you've got more instructions with CISC chips and more visible registers with RISC chips, but with the decline in assembly programing and renamed registers, these are quickly disapearing as differences. Both chips end up decoding instructions internally anyway and you end up with very similar execuation paths in the end. Basically on the inside they are the same, just dressed up differently.
Lets see here. Alpha only real processor? Alpha was nice, they did a bang-up job designing it and than DEC managed to do a bang-up job driving the company into the ground and taking the processor with it. Interestingly, the Alpha was designed from the ground-up to clock to high speeds. They took the idea that high clock speeds were the way to go to get performance, yet now if you read this thread people are complaining about Intel doing the same thing.
Itanium is the Itanic? Well now that one is a complex issue and perhaps best left for another thread. Suffice it to say though that the Itanium line of processors have yet to find the right market niche in which to live, despite a LARGE sum of money that Intel has invested. In my mind the issue is that Intel is pushing a chip to a problem that demands a system as a solution. No matter how good the chip is, Intel still needs the infrastructure there to support it. They need HP and SGI to provide the systems and support and they nee
Have a look at the list of applications that make up SPEC CINT2000 sometime. I think you'll find that many of those applications ARE what people use in their every day computing.. err, at least if they run *nix. The tests include compiling with GCC, compression with GZip and BZip2 and running Perl. There is also a database test and a couple Place and Route tests, perhaps not normal workloads but certainly things that some people buy faster computers for.
CFP2000 tests are not nearly as common, they are mostly scientific computing tests. Some fluid dynamics stuff, neural net simulations and equation solving libraries of various types, though Mesa (software OpenGL) does get thrown in there.
VIA's chips offer some nice performance on a per-watt metric. Same power consumption as Transmeta but higher performance. They are also DIRT-CHEAP, which is something that Transmeta hasn't caught on to yet and the reason why VIA continues to gain market share while Transmeta continues to lose market share.
As for AMD, they have a few chips. First off there is the AthlonXP-M chips, the best of which have only just slightly higher power consumption (less than 10% higher) and slightly lower performance than the Pentium M, but they sell for a lot less. They also have their Alchemy line of MIPS chips which compete with Intel's StrongARM/XScale chips, albeit not all that successfully (performance and power consumption of the two are very similar, but ARM seems to be really beating out MIPS in most markets).
The Geode is a brand new addition, really just an old Cyrix design that has been sold and resold. It's pretty much unchanged from the old MediaGX that it started it's life as 6+ years ago. It remains to be seen what AMD will do with it. Hopefully they have a few tricks up their sleave.
AMD's mobile chips are nice, not quite as fast as the Pentium M and slightly higher power consumption (they're pretty close though), but cheaper. However.. umm.. "weighs about 2 pounds less"? 2 pounds less than what exactly? Dell's Inspiron 300m notebook with a Pentium M/Centrino setup weighs only 3.0 pounds, 1.3 pounds less than the notebook you linked to. On the other hand, the Inspiron 8600, using the very same Pentium M processor, weighs in at a hefty 6.9lbs.
The processor has basically ZERO connection with the weight of the notebook. The battery, the chassis and the screen all factor in here, but the processor? Those things are only a few grams!
As you correctly guess, the Prescott is a VERY major redesign of the P4 core. This article has pictures of both a Prescott and a Northwood die, and they are VERY different (side note: I'm not sure I buy his whole Prescott = 64-bit thing, but the article does have some useful data about the two chips).
In any case, while the power consumption numbers are all over the place, we do have some firm die-size numbers for the Prescott. If you look at Sandpile's P4 page, you can see that the Prescott is listed as having a 112mm^2 die (90nm node) with ~125M transistors. For comparison, the Northwood has a 131mm^2 die (130nm node) with 55M transistors.
A large chunk of the extra transistor budget is going towards the extra cache (the extra 512KB of L2 cache is a good 30M transistors all on it's own), and cache transistors pack in tightly, so the die size/# of transistors ratio ends up being a bit lower than you might expect from just a straight process shrink.
The Prescott doubles the size of the L1 data cache (from 8K to 16K), increases the size of the trace cache (from 12K uops to 16k uops if my memory serves me correctly), doubled the size of the L2 cache (from 512K to 1024K), eliminates the integer multiply penalties and probably implements a barrel shifter.
It also makes improvements to the TLB and the load and store buffers, it beefs up the SMT (aka "hyperthreading") performances and adds a few extra SSE instructions. Ohh, and it has more rename registers and can have more instructiosn in flight at any given time.
All of the above changes are designed to INCREASE the per-clock performance of the processor. Most of these won't make a big difference, but the bigger caches definitely will help, and help a lot in many applications. A longer branch misprediction penalty will hurt performance a bit, and there are likely a few other changes made that can hurt performance every now and then.
In short, whether the chip is faster or slower will depend a lot on the exact application being used. My guess, after looking at all the data I can find on the chip, is that the Prescott will be about 5% faster, clock for clock, than the Northwood. This is, of course, just a guess. We'll have to wait for another two or three weeks to find out just how it performs.
WTF? Please, just have a look at some IA-64 assembly code! It's NOT pretty, especially if you want it to go fast. You've got to do the whole explicitly parallel thing, manually pack together independent instruction according to what pipelines you want to run them in.
Itanium is NOT a RISC machine like Sparc, not in the least. Sparc is much more closely related to x86 than it is to IA-64. The Itanium is a VLIW chip, or EPIC in Intel-speak. It's a whole different animal altogether.
FWIW, here's a brief article where Intel talks about implementing a bubble-sort in IA-64 assembly vs. the original C. In particular, they start with the code that the Intel C compiler generates and optimizes it. Their final, optimized version of the algorithm is on page 5, and it's anything but easy.
The Opteron increased the number of total stages but didn't increase the branch misprediction penalty.
There's no word yet on whether or not the branch misprediction penalty has changed on the "Prescott" vs. the "Northwood" P4. The "Northwood" has a 28-stage pipeline with a 20-stage branch misprediction penalty. This "30+" stage pipeline of the "Prescott" could refer to either number.
Ok, someone please mod the parent -1 clueless!
First off, the P4 has about the best branch predictor in the business. The only processor that had a better branch predictor was AMD's K6 (and the NexGen chip from which the design originated).
As for the "slowness" of the P4 vs. the PIII, in many applications the P4 is actually FASTER, clock for clock, than the P3. This was even true back in the days of the "Willamette" P4, and especially true for the "Northwood" P4. Plus the P4 core clocked nearly twice as faster on an identical fab process (2.0GHz vs. 1.13GHz, the top speeds produced for both cores at a 180nm node), so who cares about clock for clock! Dollar for dollar the P4 was WAY faster.
And the broad is better than deep because the CPU is doing many things at once? First off, the CPU can only handle ONE task at any given time unless you support SMT. Intel supports SMT ("hyperthreading in Intel-speak), AMD does not at this time. But more to the point, both broad and deep give you certain advantages and disadvantages with regards to keeping your execution units full, but both requirements end up being pretty similar in the end, ie you need instructions that do not depend on the results of previous instructions.
Now in your third paragraph things start getting really sketchy. First off, AMD's highest market share numbers ever were back in the late 386/early 486 days when they hit 30%. With the K6-2 AMD managed up to about 20% market share. Now they're sitting at about 15-17%, depending on who you ask, and they've been there for a while. The Q4 reports from Intel and AMD tend to suggest that Intel actually gained market share from AMD over the past 3 months, that AMD's average selling price went up a lot more (so theit total revenue is increased more than Intel's).
Of course, the part about AMD's 24-bit FPU must be when the crack really kicking in for the original poster. The K6, like EVERY OTHER FRIGGING X87 FPU EVER PRODUCED, had an 80-bit floating point unit! The K6-III did not make any changes to the FPU (though the K6-2 made a very minor change to how it handled the FXCH instruction, which mainly helped performance in Quake). These chips also did not have any serious compatibility problems, though there were the standard few errata that you get with any modern x86 processor (whether made by Intel, AMD, VIA or anyone else). I can only remember one errata in the K6 line of chips that ever really caused problems, and that was fixed pretty early on with a new stepping to the original K6. There were also timing loop bugs that caused some problems, but that was the result of dumb-ass software, the hardware performed exactly as expected.
The idea of a longer pipeline is that it makes it easier to clock the chip to higher speeds. This is obviously successful for the P4. The highest Intel was able to push the P6 core of the Pentium 3, when using a 180nm manufacturing process, was 1.13GHz. Even then they had to recall their first attempts at 1.13GHz chips and it took them nearly a year to get them working.
On the exact same 180nm manufacturing process Intel was able to crank out 2.0GHz P4s with no trouble at all.
As for 3 times the performance, have you checked out the SPEC numbers? Intel's 1.0B GHz PIII processor managed 457 CINT2000 and 310 CFP2000, while the P4 3.0C GHz managed 1265 CINT and 1229 CFP. So the P4 is actually 2.77 times faster at integer code and 4.08 times faster at floating point code when compared to the PIII. Ok, maybe not a 100% fair test since different compilers were used, but even if you used the newest compilers for the old PIII's you would still get more than a 3 times speed up in floating point code for a 3GHz P4 vs. a 1GHz PIII.
Ironically enough, that's quite accurate for processors!
A 6-stage pipeline with terrible branch prediction and all sorts of holes in it isn't going to do any good at all, while a 30 stage pipeline with great branch prediction (and the P4 does have great branch prediction) and few bubbles or holes (improved SMT, aka hyperthreading, is supposed to help here) will do wonders.
Of course, the real question is now how long the total pipeline is, but the branch mispredict penalty. It should be noted that the "Northwood" P4 has a 28-stage pipeline, but only a 20-stage mispredict penalty. If the "Prescott" has a 30-stage pipeline with a 22-stage mispredict penalty, it isn't exactly a huge change.
A 100% efficient solar panel gives you about 500-1000KW/km^2 during the day, and nothing at night. In North America we consume about 2KW of energy on average throughout the day.
So, let's take a near best-case scenario of putting solar panels on the equator, getting full-intensity (ie noon hour) sun for 12 hours a day, we're still talking about only being able to provide power to 500 people per km^2. For the United State's 270 million people, that works out to 540,000km^2, or about halfway between the size of California and Texas.
Of course, if we were to use real numbers, even with 100% effective solar panels you would need an area MUCH larger than the size of Texas to support out current energy needs.
Note that this isn't even starting to consider the HUGE extra burder to the power grid if we were to try and power all our cars by it like you're suggesting. Our total energy consumption is up around 7 or 8KW/person when you add in non-electrical energy sources (mainly internal combustion engines for vehicles, heating, etc.).
Since there are no wells of molecular hydrogen anywhere on the planet, hydrogen will *always* be only a storage medium, *never* a direct energy source
Err, well unless you count nuclear fussion. I suppose that's a little ways off though!
But the extraction-from-hydrocarbon method has got to go.
Have you got any other suggestions? There are only two widely available sources of hydrogen. The first is water, which is all well and good except that you only ever get out less energy than you put in (ie it's purely an energy transport mechanism, you still need a power plant to provide the electricity in the first place). The second widely available source of hydrogen is in hydrocarbons.
Of course, there are some advantages to getting power from hydrocarbons the fuel cell way instead of internal combustion engines. First off, the real big problem with current energy production is that burning hydrocarbons produces all kinds of sulpher dioxide, nitrogen monoxide/dioxide, etc. By separating out the hydrogen using a membrane you shouldn't get nearly as many of these emissions. Also, if the claim of 3x the efficiency is accurate than it would be a BIG bonus, though most numbers I've heard place the efficiency as being much lower. Finally, a fuel cell powered car would probably work better with regenerative breaking than what you get in current hybrid cars, since you would now just have an all-electrical system instead of a gas motor and an electrical motor. At the very least it should make things easier/cheaper than hybrids.
The nice thing about hydrogen is that you can make it from many different energy-producing processes and ship it fairly easily
Err, actually it's not all that easy to ship hydrogen. It's a gas, and a VERY light gas at that. You really need to compress it a whole lot before you can get any meaningful quantity. You also then have the problem of shipping a lot of highly compressed and highly combustable gas. In short, it's not easy at all. Storing is extremely troublesome for the same reasons. Shipping and storing fossil fuels is MUCH easier.
The wind, wave, and solar power installations that some think will save the world can easily drive an electrolytic converter, for example, and the only byproduct is oxygen
I love wind, solar, wave, etc. energy as much as the enxt guy, but lets face it, they aren't anywhere near capable of providing us with our CURRENT energy needs, let alone the SIGNIFICANTLY higher energy needs if we started doing electrolytic converters for all of our cars!
Why an IP address? So they can provide a link to pictures of their logs?
Don't forget your solid gold cables with a 1m diameter!
Err, we may not know "everything" about sound, but it's been a VERY well understood concept for quite some time. As compared to basically every other aspect of physics it's extremely well understood. Sure, there are plenty of tricky issues, particularly things like the accoustics of a room, but even those are concepts that humans have been perfecting for 300+ years.
Sure, we'll learn a few new things here and there, but the chances of any sort of really fundamental change in our understanding of sound happening in the next 100 years is pretty darn slim.
The Soundstorm chip is expected to become a standalone part, though it looks like they're primarily targetting on-board audio rather than add-in cards. I suspect that it will be just a single chip with little other than audio and a hypertransport connection to the outside world.
As for the whole Abit/nVidia falling out story, I don't know where the heck The Inquirer got that news (or was it The Register, the other techno-tabloid). It came just days before Abit announced plans for several nForce-based products, including Athlon64 boards.
As for me, I've found the nForce platform to be by far the easiest to deal with. Simply beating VIA isn't exactly impressing me, I sometimes feel that trained monkeys could produce better drivers than VIA. However I've found the nForce drivers to actually work well consistantly. That's something that I can't say about any other company, including Intel (Intel usually gets there eventually, but their first revision or two for a new chipset are often VERY bad).