Slashdot Mirror
AMD's 64-bit Plot
ceebABC writes "In a long interview with eWEEK, AMD's CEO Hector de Ruiz talks about struggling to compete with Intel, but more importantly about their upcoming 64-bit processors. He says that AMD's 64-bit chips will be comparatively priced to the 32-bit ones, and backwards compatible. He also thinks there will be a market for desktop 64-bit systems. Skip to the last page for the most interesting stuff."
Is there really much consumer (not business) application for 64-bit processors? If so, where would desktop computing benefit?
slashdot!=valid HTML
will it be faster than 32 bit offerings? For almost anyone out there, it's the only factor when buying a CPU: speed! Adressing >4Gb of memory is not that worries me first :)
have you been defaced today?
Yes 64 bit CPU's for desktops will soon be the next new thing, but who really needs them? Grandma and grampa checking their email won't need something that fast and even the normal computer user will never experience such CPU intensive work to need a larger word size. Trust me I am not saying I won't be one of the first people to run out and get one, but there really is no need for the general public to have 64 bit processors.
those people who think they know everything are a great annoyance to those of us who do. -isaac asimov
Will the processors run cooler than the current 32 bit offerings from AMD?
As much as I love AMD, my box is far too loud, and I'm too damned cheap to shell out another $100 for decently quiet fans.
Yeah, and I have a 128-bit graphics card. (I know, they have like 100 Mbit ethernet cards now. :) ) However, The GPU and processor are totally different. The graphics card has more bits but obviously it doesnt run as fast as the cpu. All it does is make your fragfest a little more purty by letting you see the giblets all over. Having the CPU 64 bits is quite different, security-wise, code-wise, and speed-wise. If you have a 64-bit 2 GHz processor and a 32-bit 2 GHz processor, the 64-bit processor is going to be much faster. This speeds up the whole system, not just the rate at which you make giblets fly.
I'm the Devil the Windows users warned you about.
Both Intel and AMD have been betting big on 64 bit computing and it will be interesting to see how this plays out.
Itanium 1 was a flop. Itanium 2 has respectable performance, but is not IA-32 backward compatible, where AMD x86-64 is backward compatible.
I will bet that backward compatibility will tilt the balance to Opteron and that Intel will scramble to introduce a new chip Yamhill(?) designed to provide the backward compatibility that IA64 lacks.
"Provided by the management for your protection."
Didn't AMD announce that they were no longer going to compete for the desktop CPU? And now they say that there *IS* a market for the 64 bit CPU on the desktops!!! Well, are they, or are they not competing then?
I confused!
Here are some benchmarks for a Operton.
http://www.aceshardware.com/
OK people, I know some of you are trying to be humorous, but really the 64 bits is the size of the registers and how much data the processor handles at once. Which means at 64 bits, the processor can process (theoretically) twice as much data per second than a 32 bit processor. Which also means it can handle any number up to 2^64.
I'm the Devil the Windows users warned you about.
...and anything is can do for people's humor quotient will be welcome as well
from previous: "What about the Commodore 64? And when whas this? 1992? Sheez." ah commodore 64 = 64kb ram, not a 64bit processor.. oh that was a joke, i get it haha! To my knowledge the processor was an 8 bit.. bit of a difference.. oh hahaha pun pun joke joke..
"If you are going through hell, keep going." - Winston Churchill
64 bits is useful for databases accessing gigantic datafiles and other I/O intensive operations. High performance computing loves moving 64 bit values around. Ever do a "file" on /sbin, /usr/bin, /usr/sbin on Solaris? 32 bits all the way. The only reason I downloaded a trial copy of Sun's C compiler was to compile lsof for Solaris 9, which, since it talks to file structures, needs to be 64 bit.
I think having 64-bit Linux without buying a SPARC, RS6000 or PA-RISC box will be huge for the enterprise. The rest of us will wonder why our apps still suck.
At first they will be expensive, then they will be in the $599 desktops. Why wouldn't you use them?
Just wondering, if Linux already runs on 64bit, which I think it does, and I have not heard of microsoft having anything ready for this market, does this mean that just as gamer's buying games pushed the video card (and in my opinion, the os) market, will we see linux be increasing adopted since it will run 64bit and MS does not?
Just a question.
Thanks for the replies
Sigs are dangerous coy things
If you have a 64-bit 2 GHz processor and a 32-bit 2 GHz processor, the 64-bit processor is going to be much faster. This speeds up the whole system, not just the rate at which you make giblets fly.
Ehrmm. no, if it were that easy we would all be using 64bit by now. 64bit has historically been faster because they belong to a better group of architectures called RISC, the new AMD 64-bit will be faster not because they have more bits but because AMD has upgraded the architecture and added more registers.
The number of bits is a meaningless as counting the number of seats in a car, twice as many seats doesnt make a faster car. In fact it makes the car harder to design to be fast, so does 64bit processors.
You can already do 64 bit adressing on AGP. As for bus width, width of the bus is independent of processor register size. PCI/X already has a 64 bit width configuration and works quite well with processors that are only 32 bits wide.
paintball
If you have a 64-bit 2 GHz processor and a 32-bit 2 GHz processor, the 64-bit processor is going to be much faster. This speeds up the whole system, not just the rate at which you make giblets fly.
No. That's a myth. As it stands, Pentiums for many years now have sported 64 bit buses and 64-bit FPUs (well, 80-bit CPUS actually), so we're not talking about bus size and FPU width. We're talking about:
1. All addresses being 64-bits.
2. All internal integer registers being 64-bits.
For #1, realize that this is going to greatly increase the data size of many applications. The larger the data size, the higher the chance of cache misses. In general, this is a loss, not a win.
For #2, realize that some integer operations are O(N) where N is the number of bits involved. 64-bit multiplication and division are slower than the same 32-bit operations. Period.
The gain with 64-bit processors is one of address space and nothing more.
These plots are 32 times as good as the 2-bit plots in Hollywood movies.
Good thing it's backwards compatible or all the studios would have to upgrade their writers too.
paintball
talks virtually nothing about similarities to IA-64. Perhaps, what I'm asking is, can anybody compare and contrast the two architectures; is there a certain advantage to one or the other?
Check the Windows XP 64 bit edition website. I hate to burst your bubble, but microsoft knows what it's doing.
I'm amazed to read the discussion, wether or not 64 bit will succeed over 32 bit processors.
...
This is 10 years after DEC has introduced the Alpha Architecture (in spring 1992).
The Alpha was fun to work with, not only because of it's 64 bit architecture, but because of the clean orthogonal instruction set and it's outstanding performance.
Rest in peace
No real benefit will come until geniune 64-bit apps hit the consumer market. This will be a steep learning curve for most developers who have only ever know 16 or 32-bit programming.
The problems to be hurdled are:
1) Reliance on the fact that size of pointer is equal to size of int.
2) Reliance on a particular byte order in the machine word.
3) Using type long and presuming that it always has the same size as int.
4) Alignment of stack variables.
5) Different alignment rules in structures and classes.
6) Pointer arithmetic.
A lot of engineering (and developer re-education) work also needs to be put into not only these issues, but also designing the application so that it is actually getting the most out of each clock cycle.
-- Ed Avis ed@membled.com
no, the Commodore 64 was 64 bi^h^hkilobytes of RAM. hey, imagine a beowulf cluster of those.
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
AMD's 64-bit chips will be comparatively priced to the 32-bit ones
So, they're going to be twice as much?
heh.
.sig last updated Jan. 14, 2000
No this is the interesting stuff
"eWEEK: What does it mean to you personally, though, when a Gateway or an IBM not just stop, but announce that they'll no longer be offering AMD as an option?
Ruiz: I think it's terrible, obviously. It's terrible. I think if you were to talk with Ted Waitt at Gateway, and ask him, "Why'd you do that?" and if he would really tell you why, it's a question of he's being bribed to do it. Now, he's got to look out for his own hide and the company that's probably in great difficulty has got to listen to the huge amounts of money that can help him do that.
But you know what I find amazing, think about the power, is that despite all that, which obviously we really get emotional about the fact that somebody like Gateway gets bribed into doing that, is that despite that, according to Dataquest last week, we're still holding a 19 percent share of the market. That to me tells me we're in the throes of breaking this open"
Hey Intel, see you in court! Of course now that Intel is along with Microsoft backing a group to outlaw opensource in the government, I think its time for the opensource community to boycott Intel. Why should our money go to a company which is now attempting to hurt Linux and opensource? I know because these recent actions, I will NEVER buy Intel ever again!
If you wanna get rich, you know that payback is a bitch
I see many posts here wondering about porting Linux to 64 bit...
Remember the Alpha? 64 bit goodness all the way. Has been running Linux for years.
And for those old enough to remember... Microsoft did support Win NT on the Alpha just a few years ago.
As far as the software goes, both Linux and Microsoft are ready for 64 bit computing.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
2^32 addressing is obsolete already -- it cannot keep up. Most enthusiasts have a gig of RAM (or more) in their DESKTOP PCs. In 2005, most of them will have hit the 4gb limit. In 2009, most consumer PCs will have hit the same limit. Servers have already hit this limit. That's why there are special instructions (a return to segmented memory access) on P3 and P4 processors, allowing up to 64gb of RAM in 4gb segments to be addressed. If you remember doing DOS programming (I do), you know why this 64-bits is good, while 32-bit segmented access isn't.
:)
2^32 addressing limits addressable HD space to 2 terabytes. "2 terabytes? But that's way larger than even enthusiasts use in their PCs, despite their larger than average needs." This ignores the fact that many companies have storage arrays that are at 2 terabytes. Some work went into the 2.5 Linux kernel to increase the number of blocks that could be addressed by moving internally to 64-bits. Storage needs are always increasing. If we're hitting 2tb today, isn't it a good thing that we're moving to a better amount of bits?
2^64 addressing is not the only benefit of the change. FPUs see additional benefit when they have more bits. More bits means more precission; this is very important and desirable, especially when working with numbers that have fractional components. For proper 3D rendering, physics models, and anything else that involves computing numbers that have fractional parts, more is better. When the FPU can handle a double in one clock cycle because it works natively on 64-bit IEEE floating point numbers, you will notice a performance boost in addition to the increased accuracy.
64-bit word operations means that databuses can be slower, since each clock-tick sends more data. 64-bits means you can do more, more flexibly, with your computer.
There will always people who resist change, even when there is no reason to resist change. The same people are posting comments on Slashdot about how 32-bits is enough, and how happy they are with 32-bit applications. These are the same people who had to be carried, kicking and screaming, from their 286s to the new 386 and 486 machines which had 32-bit addressing and data operations. Don't let these people hold back your exploration of new technology!
For those of you who are saying, "what about 64 bits? Will 64 bits be enough?" 2^64 is 32 orders of magnitude bigger than 2^32. 2^32 is roughly 4.5 billion (unsigned). 2^64 unsigned is 18,446,744,073,709,551,616, or roughly 2220 * 8309 trillion. 4.5 billion goes into that number 4.5 billion times. 2^64 is certainly enough for at least a hundred years
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Have you ever done a physics engine? When you are working with vectors, you want as much precission as you can get. More precission means more bits.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Increased maximum memory helps.
Opteron's extra registers help.
64-bit calculations are easier, they don't have to be put into multiple 32-bit parts.
So...a 32-person bus is just as good as a 64-person bus? It may be harder to design and build, but when you have to move >32 people it's nice to have that big of a bus running around.
What I'm saying is, being 64-bit DOES make you faster. Not twice as fast, but definately faster and more powerful.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
A major advantage, especially to the Open Source community of 64 bits on the desktop is software development.
Remember, many (most?) open source developers are private individuals and not huge corporations. Allowing individual open source developers to own an affordable 64 bit desktop machine will allow them to more effectively develop and debug the code that runs on the 64 bit servers.
It only seems natural that a developer, given a 64 bit system to develop and debug code on, is going to produce better 64 bit code. And we all want Linux (and the BSD's!) to be the best 64 bit platform it can be, right??
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
Let's also not forget the fact that the C64 was closer to 1982 than 1992.
Dissolve... Resolve... Evolve...
wouldn't the chance of cache misses depend on the caching policy? How does the data size matter? If your policy is good, when your misses will be rare. Otherwise you're screwed even if it is 8-bit
The gain with 64-bit processors is one of address space and nothing more.
Which includes better behaviour for those programs that have to fake larger address space. That would be a speed increase.
I've been eagerly waiting for Hammer ever since it's announcement. High-bandwidth interconnects, 8-way SMP support, and AMD's incredibly high IPC all team up for a chip that sounds like a winner.
However, each chip is only going to get a single DDR333 memory path. With all of this time and effort, and so much at stake for AMD, you'd think that they'd make sure that they did it right, and move to a dual-channel solution, or at the very least, a DDR400 solution - which will be a pretty standard offering when the Opteron/Hammer/Athlon64/Whatever is released.
Sure, it'll perform pretty well with a single channel of DDR333. But I'll bet it would perform MUCH better with more bandwidth. And compared to all of the design and development that they've already done, implementing a dual-channel memory controller really wouldn't have been any significant challenge.
So, I'm not nearly as optimistic. On the other hand, I'm not a skeptic yet. When they come out, I'll see how they perform. But I'm certainly not as excited as I used to be.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
What does it get the consumer:
New apps (as in killer apps)? No.
New OS features (by going 64bit)? None.
Speed? Somewhat.
Since when did a little bit more speed make linux a killer app? Also considering that if there is a marked, Windows will most certainly give out a 64bit-version.
Kjella
Live today, because you never know what tomorrow brings
Kernel 2.4.20 has x86-64 support built-in.
Look for SuSE's Andi Kleen in the release-notes.
fpg
Are there any sites that talk about how to get a 64 bit AMD system going? How expensive are they?
NT ran in a crippled 32-bit mode on the Alpha. It did not support 64-bit applications.
Mea navis aericumbens anguillis abundat
For #2, realize that some integer operations are O(N) where N is the number of bits involved. 64-bit multiplication and division are slower than the same 32-bit operations. Period.
If area is not an issue, you can do a multiplication in log N steps. Current latencies suggest that this has been done for a while, so I wouldn't expect to see much of a difference at all for multiplying numbers. It's division that takes O(N) steps (you can apply brute force to reduce the proportionality constant, but the order remains).
Would you mind elaborating on that part?
Talk to the right people and you'll find a beta of win2k server for the alpha cpu. At the time neither intel or AMD had a ready for prime time cpu and MS needed to keep a working 64 bit codebase.
Only the State obtains its revenue by coercion. - Murray Rothbard
Every time the processor bus width has gone up (8 -> 16 -> 32), applications have expanded to "fill" the newly available bandwidth. A few data points:
1) I remember PC Magazine predicting that 80286 systems would only be needed as servers.
2) I get by with a 733 MHz system at work but the only system I can't saturate at home is my dual Athlon box by "just" playing a game. The more realistic and "imersive" the game, the more bandwidth it takes.
3) I correspond with several people who do digital video editing and they can swamp their dual CPU systems.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Alphas might have had a chance, being 2^32 times as good as their 32 bit competition.
paintball
The number of bits is a meaningless as counting the number of seats in a car, twice as many seats doesnt make a faster car. In fact it makes the car harder to design to be fast, so does 64bit processors.
:)
It does let you transport people twice as fast though - although most trips will still end up being made with some empty seats.
I'll leave the car pooling analogy to someone else
It's nice that AMD are benefitting from open source developers such as those as http://www.x86-64.org
But keep in mind that AMD have stepped forward (with Intel) and said they will be planting DRM features in their products to satisfy M$'s trusted computing push. And while initially you will be able to turn them off, soon the US and their states such as England and Australia will pass laws to make such consumer disobedience illegal.
Windows 3.51 ran on Alpha, Mips, and PowerPC. 4.0 was restricted to Alpha only, then some service pack took even this away. Even though it doesn't run on anything but IA32, I doubt if the code is real "64-bit impure" now, and they probably already have had x86-64 and Ittanium teams chugging along for a while now. Most of the free UNIXes (Linux, FreeBSD, NetBSD) have Alpha support, which is another 64-bit Little Endian chip, so it shouldn't be too hard of an shift to x86-64. NetBSD already has the OS up and running on an x86-64 simulator.
If you want to say "an OS optimized for 64 bit" and applications that scream with 64 bit chips, then I'd say "ahh, there's the rub." It will take folks to move to 64 bit, just as it took folks to move from the relatively dirty 16-bit "selector plus offset" addressing of Intel 16 bit code to the cleaner flat addressing model of 32 bits. but you need the chips out there for people to play with and get real applications for.
How about.. Hey Ruiz, see YOU in court.
Unless he has proof, that would be libel, no? Of course not - in his world, when a competitor gets more business by offering a substantial discount that you cant match - thats bribery. When you do it, that's good business.
Maybe Gateway cant deal with the support cost of overheated (and dead) Athlons? Or maybe too many processor cores are getting crushed when putting on the heatsinks? Maybe they just DONT SELL to gateway's customers. I can think of a lot of reasons not to want to stock AMDs CPUs that don't involve some giant corporate conspiracy.
Now,
AMD has their thumbs just as deep in MSFTs Palladium pie, they just have smaller thumbs and leave smaller prints.
Why do you assume because a company is struggling in a market makes them somehow kinder and fuzzier?
What makes you think AMD gives a flying fuck about open source? Are they a non-profit orginization now?
If tomorrow, AMD magically had 80% (desktop) market share, and Intel 20%, would the world be a better place?
If you really wanted to make a difference, you'd boycott anything and everything digital, DVDs, CDs, video games, computers, and make a statement that you don't like the way the industry is treating us with DRM et al.
Anything short of that is not only pointless - it's hypocritical. Hear yourself saying "Intel is an evil company! Buy AMD!". It's moronic.
I don't need no instructions to know how to rock!!!!
For #1, realize that this is going to greatly increase the data size of many applications. The larger the data size, the higher the chance of cache misses. In general, this is a loss, not a win.
wouldn't the chance of cache misses depend on the caching policy? How does the data size matter?
Data size matters because a program will typically access a fixed number of working variables, not a fixed amount of data. If a program's working set size stays at, say, 1000 words, and you move from a 32-bit to a 64-bit architecture, you need a cache with twice as much storage space to hold the working set without thrashing.
There's easily enough die area to double the sizes of the L1 and L2 caches; the problem is that it slows down cache access (more latency cycles fetching something from L1 is a Bad Thing).
Certain types of load work with constant size instead of constant word count, but most of those deal with working sets large enough that you'll thrash no matter what.
The gain with 64-bit processors is one of address space and nothing more.
Which includes better behaviour for those programs that have to fake larger address space. That would be a speed increase.
Nothing running on x86 will do that. Unless you're running old DOS programs in real mode, you're already working with a flat address space. Typically 2 gigs of this is available to user programs (with the rest being mapped to kernel or device space). If you have a problem with a working set larger than 2 gigabytes, you already have a Sun/$other_vendor machine to solve it on.
Larger address space targets the _future_ problem of desktop users who want many gigabytes of memory.
A fringe benefit is being able to more efficiently map multi-gigabyte files into memory space, but performance for this kind of task is limited by disk latency and controller bandwidth, not memory architecture.
The article you point to was all about how AMD is interested in branching out. It's no longer their key business, is what they're saying; I wouldn't surprised if they're looking at going up against Motorola, which tends to have it's chips in pretty much everything.
... or was it three?..)
:P
In other words, that article was mostly an appeal for new corporate partners.
As usual, the Slashdot employee got it wrong; timothy, in this case. Funny.. I don't remember seeing him screw up before.
Anyone want to make a scorecard site of some sort for these kinds of things? I think it'd be kinda amusing to keep track of how many times each of the respective Slashdot editors over-exaggerate an article's content. Or, at the very least, it might embarrass them into enforcing some stricter quality control.. (although if last week's two dupe-posts couldn't do it..
Mod me down if you must, but I did answer the question.
This is a Question ive wanted answered for a while now..
these news 64bit proc's
will they bis SISC? or RISC?
isnt it time we dumped the whole SISC architecture? like the ISA standard
The More Knowledge you have the Luckier you Get- J.R. Ewing
so now the registers will be named like "weax" and "xfbc"?
I Browse at +4 Flamebait
Open Source Sysadmin
who could really use this, I bet. Their typical job ATM has an array of at least 3000x2000 data points as input (starting the job) and the job requires differential calculus to the 12th decimal point for each possible combination... last I heard, their shiny! new! pentium 4s with WinXP were choking and gagging for days on end.... so like I said, bring it on, AMD.
C|N>K
Why does AMD have to compete with Intel on raw speed? Why does AMD need to have the absolute fastest chip available? Why not concentrate on providing customers with a low price and high performance instead- in other words, chips that may not be the absolute fastest, but are fast enough?
The reason my last two PCs have been AMD-based boxes is precisely because they didn't have Intel processors. I'd like to think I'll still have a choice a couple of years from now.
Hmm. And the next gen OSs will slow it back down again to where we are today with cruft and bloat.
Just for fun, I installed windows3.11 on a P3 500 and had a boot up in 7 seconds from bios handover to loading up word. I suppose the bit that depresses me is that XP does very little more than 3.1 (more peripherals supported, but not too many more)
And Linux fans, get off your high horse, Mandrake and Redhat on modern hardware cannot compete with aincient distros of slackware for speed of bootage. Yes I know I can roll my own and an out of the box may not be considered "fair" but how many users in the real world do more optimization than is presented during install time?
So more grunt will be sacrificed once again at the alter of bloat.
Sand.
A sig is placed here
To display how futile
English Haiku is
I think you'll be surprised where 64-bit CPU's may become useful consumers.
The first place where this will be useful is video editing. With the proliferation of MiniDV camcorders that have IEEE-1394 connections to desktop computers, many camcorder users are downloading video onto their computers for editing and creating home-made VideoCD or DVD-R discs. With 64-bit CPU processing we now can see the development much more sophisticated (yet easier to use) programs that make video editing and VideoCD or DVD-R disc creation almost a snap.
The second place this is useful is still image editing. With the proliferation of digital still cameras with USB ports people are doing more and more image processing of still images before printing out the pictures. With 64-bit CPU processing we can see image-editing tools that can do image processing that is far more sophisticated than what even Photoshop 7.0 can do today, yet would be easier to use than ever.
The final place is games. 64-bit processing makes it possible to do extremely sophisticated graphics effects in real time without over-reliance on an expensive high-end graphics card; a lot of games that need fast motion with complex backgrounds could benefit from going to 64-bit CPU processing.
you, sir, just said it best of anyone so far, IMO.
:D
"Once the processors are available, applications will be written to take advantage of the larger word sizes. There's no way to tell what will happen."
Exactly. What can't you do on your PC now, fast enough? full-motion, real-time, uber-quality video editing? Molecular/weather/beer modelling? Compression? Encryption? Random CPU usage for fun?
That's why we need better computers - because you can do nearly _anything_ on a PC, given enough processing power. That's why they are so beautiful: general purpose computing rocks. In ten years, I will look at my 32-bit Athlon, and sigh, and remember the days...
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
ha. good point. benchmarks? we don't need no STINKIN benchmarks!
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
As for as I know, the SISC (single instruction set computing), typically embodied by the instruction SBN (subtract and branch if negative) is only used as a joke, in the same manner as Intercal and Malbolge.
Oh, you probably meant CISC, never mind...
32 bit architectures are not limited to 4 gigabytes of memory. "32 bit processor" refers to the width of the DATA bus (and registers). It does not refer to the width of the address bus.
For example, the z80 and 6502 were 8-bit processors, but they supported more than 256 bytes of RAM (2^8 bytes). The 68000 and 80286 were 16-bit processors, but they supported more than 64k of RAM (2^16 bytes). That's because the 8-bit processors had 16-bit address busses, and the 16-bit processors often had 24-bit address busses.
The current pentium-4 Xeon chip supports 64 gig of RAM, despite being a 32-bit processor.
64-bit computing means that you can hold a 64-bit quantity (long int or double) in a register. Also, you can load, store, or perform arithmetic on such quantities using one instruction and often in one clock cycle.
This offers very few benefits for the end consumer. Mostly it's about perception: consumers will percieve that a 64-bit chip is twice as good as a 32-bit one.
That's not exactly accurate. A 64 bit processor has a large data pathway, and is more comparable to a roadway than a car. The cars are the data, and a 64-bit roadway has twice the space for cars (data) on it, which is where the extra speed is. But I do agree with you otherwise.
You can use Newton's method. Combined w/ constant time multiplication, division is only O(log N)
Newton's Method involves doing a division...
I think you mean CISC.
...
...and not have any other way to solve the problem
RISC = Reduced Instruction Set Computer
CISC = Complex
The basic idea of (most) RISC chip designs, such as the MIPS, Alpha, PowerPC & Sparc, was to have a large number of general purpose registers, fixed length instructions that could only refer to those registers, and only a handful of instructions that specifically read/wrote to main memory (which is why they're also referred to as 'load/store' architectures). This simplistic design allowed them to push clock speeds without too much trouble. RISC processors were also adopted superscalar designs (having multiple execution units, allowing the execution of multiple instructions 'simultaniously') before their CISC counterparts.
In contrast to the simplicity of the RISC systems, there are the CISC chips, such as the x86 and the old VAX processors, which tried to make their instructions resemble high-level languages, as well as having a smaller number of registers, many of them having a special purpose. With variable length instructions, and many different modes of operation for each instruction, the CISC methodology generaly resulted in much larger, more complex chip designs that were harder to speed up, pipeline & make superscalar.
To compare the two, lets take a simple operation, such as taking two numbers from memory & adding them together. A generic RISC system would do something like:
1) load 1st number into Register 1
2) load 2nd number into Register 2
3) add the value in R1 to R2, putting the value in R3
4) copy the value from Register 3 to memory
where a CISC chip, would more likely do something more like:
1)add the value at memory location 1 to the value at memory location 2, and store in a special Accumulator register
2) copy the Accumulator register back to memory
The difference being that where the RISC machine only had one addition operation (register+register->register), the CISC machine would have a handful of them, depending on where the data came from (memory (using multiple forms of reference), registers, constants, and various combinations).
In the early 80s, the RISC/CISC debate was a hot one in accademia, and RISC won out there, by virtue of its simplicity & easy of improvement. By the mid 80s, the debate was starting again in industry, as a number of RISC chips started entering the marketplace, where Intel's x86 architecture won by virtue of the IBM PC.
The whole debate is pretty much a moot point now,
since Intel's new x86 chips have RISC cores wrapped by a thin layer to translate the complex instructions. As an added bonus, the new 64b x86 systems should be adding a bunch of extra registers, further negating the penalty of the architecture.
my sig's at the bottom of the page.
The new Thoroughbred Revision B Athlons (XP 2400+ and higher) made a significant drop in power consumption (1.65V core), while the 3GHz P4 guzzles more electrons than any Athlon (have you seen the heatsink Intel bundles with that thing?!). The Hammer series uses Silicon-On-Insulator technology to keep power consumption (heat) down, to the point that the larger Hammer core consumes about the same amount of power as the TBred RevB. AMD is gunning for the high-density rackmount market with the Opteron where efficient power use is critical. They'll get it too.
I have a dual CPU Athlon 2400+ box, 2GHz each, using Thermalright SLK800 heatsinks and 80mm adjustable fans set to 2500RPM. My temps are 41C/43C/42C (case/CPU1/CPU2) at the moment with about 25% CPU utilization. Power consumption (as measured by my UPS load monitor) is the same as the dual Athlon 1800+ chips (1.53GHz) the new CPUs replaced.
- 1. All addresses being 64-bits.
This is incorrect. The Hammer "long mode" uses 32 bits as the default data size. 64 bits are only used for pointers and explicitely overridden 64 bit operands. I.e., you still have to declare "long long" or "int64" or whatever, in your languages to access those 64 bits. All your old 32-bit data still occupies the same space.For #1, realize that this is going to greatly increase the data size of many applications. The larger the data size, the higher the chance of cache misses. In general, this is a loss, not a win.
Furthermore, measurements by AMD indicate that op-code size did not increase with the expanded instructions, but actual *decreased* because the additional registers decreased the typical amount of spill/fill code emitted.
Therefore there is no additional cache pressure. The "code bloat" problem remains solely in the hands of the software developer, and is *NOT* worsened in any way by hammer.
- 2. All internal integer registers being 64-bits.
This is also incorrect. There are numerous well known techniques used in ALU design that makes precious few operations "O(bits)". Again, AMD specifically targetted this. For example: the 64-bit integer multiply in hammer is *FASTER* (per clock) than the 32-bit integer multiply in either the Athlon or Pentium 4.For #2, realize that some integer operations are O(N) where N is the number of bits involved. 64-bit multiplication and division are slowerthan the same 32-bit operations. Period.
The reason AMD is able to do this is because arithmetic and logic operations can largely be implemented in a "more gates for more speed" fashion. They are closer to O(ln(N)) than O(N). But at this level of circuit design, you don't necessarily think in those terms (since N is constant, everything just looks like O(1)) -- these high speed circuit designers worry about other technical things like "latch speed".
The 64 bit integer divide may be a little slower, however, again you need to explicitely use 64 bit ints in your software, and division is a comparatively uncommon operation.
- The gain with 64-bit processors is one of address space and nothing more.
This is the largest gain (big DB people will be very happy with it) but it certainly is not the only gain. Remember that there are now twice as many SSE registers. This opens up some performance possibilities for multimedia applications.Although I don't know that its related to SSE, it should be pointed out that EPIC (as in the video game company) has ported the Unreal engine to x86-64! Like most people, I was quite surprised that they did this, however, they apparently found doing it to be worthwhile.
Do not underestimate the upside of going to 64 bits in the way that AMD has done it. They have literally made it a no-lose scenario -- that alone should spur (mostly new) application developer interest.
You are thinking about large integers. Actually at the circuit level, multiplication is not done in O(log(N)) steps, but instead, they just have blazingly fast adders.
I have been treating adders as operating in constant time, as we're working with small integers.
The grid approach to multiplication that everyone sees in undergrad microprocessor design requires N serial additions. A tree structure still requires N additions, but done in parallel in log(N) levels (as you pointed out). This is where my statement came from.
Very large integers would indeed require O(log(N)^2) cycles, due to non-negligeable adder delay, but we can make the constant-time approximation for our purposes (especially since the pipeline is likely tuned to have adds take one cycle).
If you find you need that sort of mega addressing the chances are the app you need already runs on 64 bit Solaris. After that point it's up to the vendor (Think Avanti Corp /Apollo) Wheither it's worth their while.
Remember, You need their application. Unless your app is home
grown or you have some signifigant pull with a vendor the port isn't
going to happen.
The desktop is an afterthought. This chip was designed to be sold in quanties of 8 and higher in single large servers. Once they cut into that market the economies of scale just happen to make it cheap enough for the desktop market to pick it up. They have a much better chance at getting it down with their builtin backwards compatibility and keeping costs down. Alpha never hit that "sweet spot" for the volume to really bring down the price..
Now, Don't think Intel is going to sit on its hands while AMD eats their lunch. They're more likely to drop an Itanium instruction decoder into an Alpha EV7 core and push that than follow with an x86-64 processor line. Itanium is just to big and costs too much to at this stage of development to make inroads fast enough stop AMD in gaining marketshare but more importantly, mindshare. Intel would never take up x86-64, Doing so admits defeat to the industry i.e. You're not the leader anymore.
So to sum it up, Intel will either:
2 and 3 are much more likely than one, You know which one I'd rather see happen :).
Either way it'll be a boon for the OS community and certainly make our (The Alpha community) lives easier. The way I see it, even if hammer is moderatly successfull. You guys will 'clean' most of the popular soucecode out there to be 64 bit clean, reducing our matainence work by like 80%. The only thing we'll have to worry about is firmware, toolchain, libc, Xwindows, and kernel. So please buy a *hammer and learn the joys of porting to 64 bits. If it proves too painfull, please see the ld manpage for the "-taso" flag :).
Peter
www.alphalinux.org
I.e. 8-way becomes a PCB-design issue, not a chipset issue.
And an OS support issue. Of all Microsoft operating systems, only Microsoft Windows 2000 Advanced Server and Microsoft Windows 2000 Datacenter Server support 8 CPUs, Don't expect 8-way Windows to cost less than $2000 per copy, assuming that the OEM price is half the retail price of Windows 2000 Advanced Server with 25 CALs.
Will I retire or break 10K?
...because I'm fairly sure that it's not that big a deal as they make it out to. Hopefully it won't be as bad as the Pentium Pro, but I'm guessing it won't run faster on 32bit code, which is what 99% of the programs will be at launch.
Look at it more as their version of the GHz game. "Our processor runs at 3GHz, yours at only 2GHz" "Yes, but we have 64bit registers, yours only has 32bit" Neither is a good measure of actual capabilities. But I'm sure it'll help AMDs marketing department.
Kjella
Live today, because you never know what tomorrow brings
I'm working on several projects right now dealing with these problems. The thing is that you're right. These misnomers are hacky things done by not-so-good programmers.
Unfortuanetly explain that to a FORTRAN program that was written in the early 70s and didn't have a pointer. It had to use an integer.
Yes, a lot of old stuff is shit and now programmers who thought, "If it's not broke don't fix it" are getting burned.
Unless he has proof, that would be libel, no? Of course not - in his world, when a competitor gets more business by offering a substantial discount that you cant match - thats bribery. When you do it, that's good business.
Maybe, maybe not. When Standard Oil undercut all its competitors by pricing its products BELOW production costs in order to drive them to bankruptcy and buy them out, that was ruled A Bad Thing and led to SO being broken up. There is a point where offering "special deals" is considered anti-competitive. If Standard Oil got nailed simply for offering product for too low a price, it's not unreasonable that Intel should likewise be nailed for offering product for a super low price, but only to companies that don't buy from Intel competitors. That's kind of shady territory there.
For example: BobComp buys Intel and AMD CPUs, so they get P4s for $35 each. JoeComp buys only Intel so they get the "deal" of $30 each. If BobComp buys 1000 CPUs a year from Intel and JoeComp buys only 500, then it's clearly not a "bulk discount".; it's a "helping us ace out the competition" discount. Now if $30 represents a significant loss of profit margin over $35 for Intel, then I'd say Intel is edging into some pretty anti-competitive territory.
If a job's not worth doing, it's not worth doing right.
Spare me the smoke and vapor. Don't you remember the sad story of Mica, errr, NT on Alpha? Loudly proclaimed, quietly killed, that's why I think they are not there. If you consider the number of bugs and holes in 32bit M$ work, you might conclude they never arived anywhere.
In the mean time, you can get Linux and BSD on Alpha and other 64 bit platoforms:
Oh, it hurts so much to remember and think!
Friends don't help friends install M$ junk.
However, The GPU and processor are totally different.
Yes, thats correct. But the Nintendo 64 had a 64 bit processor (and a 128 bit graphics bus)
autopr0n is like, down and stuff.
I have to share this insightful comment I read on Usenet 3 years ago:
The "bit width" of a CPU is not strictly defined by a single architectural
attribute. Several candidates for a "normative" bit width exist:
- word width of the general purpose registers
- width of internal data paths
- width of external data paths
- width of the ALU
- width of the architected address range
There are probably more...
Back in the days of the 8 bit processors, ALUs were 8 bit wide, but address
range was already 16 bit.
In the age of 16 bit processors, registers and ALUs were 16 bits wide, but
often there were more than 16 address bits. Segmented addressing was needed
to make use of more than 64 KB for a single process.
When the first 32 bit CPUs appeared, they had 32 bit wide general purpose
registers and 32 bits of architected address space. But for example the 68000
had only a 16 bit ALU and its data bus was only 16 bits wide. Of the address
bits, only 24 were externally visible on pins.
Nowadays, with "64 bit CPUs" a reality for high-end computers, the address
width is the important criterion. Only a true 64 bit machine can linearly
address more than 4 GB for each running process. And when you handle pointer
variables that are 64 bits wide, it makes a lot of sense to have 64 bit wide
registers, a 64 bit ALU and 64 bit wide internal data paths. All current
64 bit CPUs that I know of meet this definition of "64 bit".
Internal bus widths tend to be wider (think of the 256 bit wide backside L2
bus of Coppermine or the G5), and registers have been wider than the "bitness"
ever since FPUs have moved on-chip (you don't even need to consider AltiVec or
SSE). External buses are sometimes narrower (to save some pins and a lot of
bucks on packaging) and sometimes wider (to better feed the new and fast CPU
cores from the same old memory chips).
So, by all intents and purposes, the x86 architecture was 16 bit until and
including the 286, and is 32 bit from the 386 onwards. AMD's K8 will probably
extend it to 64 bits. The P6 core is 32 bits, but it has some extensions to
enable it to address 64 GB of physical RAM. But every single process can only
address 4 GB directly, since pointers are still 32 bits wide. AFAIK K7 and P7
also have these extensions, but are still 32 bit cores.
BTW, the G5 is also rumored to be able to address 64 GB of physical RAM.
There are four unused bits in each of the "segment registers" which could be
used by the OS to select one of sixteen banks of 4 GB each. But processes
would still be limited to 4 GB of directly addressable memory.
Holger Bettag
Could it be for the same reason people who have "high speed internet connections" still place charge by the minute long distance calls instead of using voice over IP, or crawl to a company like Yahoo to be a middleman? Look to Redmond, there you will see the answer. Anti-competitive, greedy stupid shit. Remember the 64 bit Alpha? You would think it would be cheap to make by now, no? Sorry, that might hurt someone's bottom line.
In short, I'd love to use one but I'm not going to get my hopes up.
Friends don't help friends install M$ junk.
that it will become trivial in terms of speed to compile your distribution (a la Gentoo) and so rpm- and deb-based distributions of pre-compiled (and thus not optimized to your specific CPU) programs will lose their current speed-of-installation advantage. Having really fast CPUs means that you can have an OS with major optimization to the specifics of those CPUs and associated hardware. This ease of customization might produce a situation parallel to the one in which the specialty steel business remains profitable while the old, monolithic producers require massive subsidies to survive. That is, it could hurt both Microsoft and Red Hat - while being very good for open source.
"with their freedom lost all virtue lose" - Milton
AMD isn't up to 3ghz yet. Perhaps that's part of the reason why they're interested in becoming more independent of the desktop market?
Knew i forgot something. NO VIDEO CARD! ARGH! Still, you can get a decent one for under $85, keeping the price at $600. *shrug*. All Hail Newegg!
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
The flaw in your logic is that Intel's actually making a profit, while AMD is still, I believe, in the red. Seeing as how it tends to be difficult to turn a profit when your primary product is sold at a loss, I'll take a stab in the dark and guess that they're not actually selling any chips for below the production cost.
Also, don't forget that Intel's manafacturing technology is about three years ahead of AMD. Their production costs are half of AMD's per unit.
A big problem with AMD chips, and something that I suspect is a not insignificant factor when it comes to the big OEMs, is that AMD builds fragile chips! If I need to build and ship x thousands of computers per day, if half the chips I buy get cracked during installation, I'm effectively paying double the unit cost.
Well, while you're bashing me,
PC-Chips, afaik, is not ECS,and their Sis board is very, very good. Somehow I doubt it is illegal...being sold online and all. I've had no problems and it's been more stable than other, more expensive boards I've used. Yeah...I build systems, I'm not just making this up.
Liteon was reviewed by Linuxhardware.org, and it beat out several Plextor drives.Their products are solid and fast.
Chieftec, as far as I can tell, makes the cases that Alienware uses. Yeah. And the PS was by Foxconn, if you bothered to look.AMD approved.Where did you get 430 watts from?
So I don't know quite what you are talking about. I've built 2 systems essentially like the one above. I've checked up on the users, and both are completely satisfied, say the systems are stable and amazingly fast. You say 5400 RPMs is slow...ok, but where did you get any idea that I was talking about 5400 RPM? the one i listed was 7200 RPM.
One thing you missed, while you were bashing me - I forgot a video card. Buy a nice GeForce 2 or 3, they are nice...don't get an MX.
So, you can do it, you can build a nice, sweet system for about $600, if you do it yourself. It's much easier (and educational!) to do it that way. AMD's price/performance ration is quite nice, and I don't mind taking advantage of it.
And whatever burr got up your butt, I'm sorry. A little more background info, maybe?
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
Who moderated this up?
64-bit CPUs have been around for years. Linux and Windows both run fine on 64-bit platforms. There is more to computing than PCs and Macs.
Uh, 64-bitness is due to the size of integers and the memory addressing that the chip supports.
Numerical approximation of differential equations is a floating point problem, and you wouldn't use fixed-point math (integers) to do it (unless you were nuts). The P4 (and the Athlons) support 80-bit extended double precision floating point math, and with SSE2, it's damn fast. If they want really insane performance, they should consider grabbing one of the Itanium2 systems from HP. Intel are floating point gods; wwhy do you think SGI is planning to migrate their supercomputer lines to IA64?
Stop using these base ten exponents while talking about computers, you're making my brain hurt!
autopr0n is like, down and stuff.
The atari Jaguar had a 64bit graphics processor, just like a 486 does if you plug an S3 Trio64 card in...
The main processor of the jaguar was a Motorola 68000, a 32bit processor with 16bit external paths and 24bit addressing.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If only this were the case, the itanium 2 is very different to the alpha.
Really they should have continued the alpha, instead of creating a new architecture... The alpha is the cleanest of all the 64bit architectures, and has always been the most performant, plus by using an existing architecture you would already have a software and user base.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The sparc64 linux kernel handles 64bit sparc and 32bit sparc applications, the sparc64 version of solaris does the same. IRIX on 64bit MIPS does too, but i`m not sure about the mips64 port of linux. /usr/freeware/bin/galeon-bin: ELF N32 MSB mips-3 dynamic executable MIPS - version 1
Infact... I`m typing this right now on an IRIX64 machine running a 32bit version of galeon:
root@evil:~# file `which galeon-bin`
root@evil:~# uname -a
IRIX64 evil 6.5 07121149 IP30
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Perhaps I worded that poorly. Rather than the the ISAs growing to resemble existing HLLs, many CISC architectures have complex instructions giving a higher-level idea of what the CPU is doing. The x86 even has text-manipulation opcodes, and the VAX (commonly refered to as the epitome of CISC computing) has 8 different ways to interpret the value of a register.
RISC machines are intended to be programmed by compilers; CISC are designed to make life easier for programmers.
my sig's at the bottom of the page.
You mean comparably? It's note quite than/then, but it's pretty unidiomatic.
A deep unwavering belief is a sure sign you're missing something...
FPU units which can communicate faster over the bus, since they send 1 data word per clock tick, instead of requiring 2 ticks to send 1 dword.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
The 286 could address 16 megs of RAM, too. In real mode, you still had to deal with a 64k segment view on the world.
The PPro has, at best, a 4gb segment view of the world. This is because it's still very 32-bit. Unless it's all 64-bit, it's of limited use.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I do believe that there are people that need the horsepower. But there are probably 10 people that don't for the one that does. Animators, video people, developers, engineers and scientists probably do. People running Office anything or some web client probably do not.
Until I can have an entire virtual space that allows a complete view of the entire range of RAM, it's all just a way of jury-rigging more memory onto a system not designed for it.
True, it may not be as hard to use as segments, but it's not as easy to use as 100% flat addressing either. And the 4gb limit is still a problem for some RDBMS systems.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Let's say I have a 16,000 by 16,000 image frame. I have 60 of them per second, and have 2 hours of film. That works out to 100.5 terabytes of data. 2^64 happens to let me store and address about 166,937 of these superduperHD movies.
Now, I don't know about you, but I only own a couple-hundred movies, and I only own a couple-hundred games. Even if they were the mega, mega high res I mention above, I'd still not use up more than a miniscule fraction of what I had available. That's why I think it'll last at least a century.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
"He also thinks there will be a market for desktop 64-bit systems."
I'll only say this...
http://www.theinquirer.net/?article=6501
Beware: In C++, your friends can see your privates!
I was hoping. If I could get some karma out of my CS degree, it'd be more than I've been able to get from it yet, considering the dismal state of the economy. Now is not the time to be a fresh graduate.
my sig's at the bottom of the page.
"early adopters, people like the gaming folks. Those people are really dumping tons of data into broadband"
'nuff said; AMD is really counting on the DVD-iso scene demaning higher performance..
Kudos for the direct link to last page, that should be the slashdot standard for any story and hardware review!
I know newegg's a pain for links...sorry.
i've never had problems with newegg or that chipset...2/2 times. *shrug*.
But I HAVE had troubles with PCChips, two boards, both awful, with onboard video etc, no support, and general crappiness. My Mom's PC that i didn't get to suggest any change about, and a friend of mine who's main questions was: how cheap is it for what sounds good? ARGH! PC chips is a whore.
So... ECS is PC-chips? huh. something new...
Liteon: I've never had problems. Maybe I'm lucky. never know.
Back to homework.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
What is so bad about x86 anyhow? Is it that its support for smaller sections of registers (8 bit AL register that merged with 8 bit AH register to become the 16 bit AX register, then EAX, RAX, etc) made for more hardware that slowed it down? That's apparently not the case, with the speed war between AMD and Intel pushing ~3 GHz. So why does x86 have such a bad rap? Because it is little-endian?
Remember "Bring 'em on"? *sigh
My favorite part so far (not at the end yet) is the part about why Microsoft would support it
Back-scratching. Remember how an AMD figurehead testified in favor of Microsoft at the DOJ trial? It may have been enough to convince MS not to walk hand-in-hand with Intel while it tries to crush the #2 chipmaker.
Remember "Bring 'em on"? *sigh
Actually cache pressure may not be that bad. Correct me if I'm wrong.
.
For OS caches, 64 bit is neutral, what you lose in bigger data, you gain in being able to have more RAM.
With respect to CPU caches, lots of data sets don't fit anyway. Unless you're talking about 8MB caches - very expensive
In contrast, my guess is the size of loops in program code haven't increased, in fact they probably have gone down due to caching (Don't want to unroll a loop till it falls out of the various caches).
Really, apart from the increased memory address space, there aren't many advantages (which result in speedups) that 64bit processors hold compared to 32bit ones. And even that extra memory space is only useful to a select number of applications (such as 3D renderers and scientific applications) currently, although I suppose that will change over time.
Donate free food here
Not just high-end games or 3D modelling.
:). Or databases.
Sure I agree that it's not worth upgrading from 2.4GHz to 3GHz, but can't tell the diff between 866MHz and 2.4GHz???
You do notice faster processors when you use scripting languages
Believe me you'll feel the difference when _serving_ the web vs surfing the web.
As for web browing? Faster machines on both client and server make the _Intranet_ browsing experience VERY different.
When you match servers which can serve up dynamic custom pages at video refresh rates (70 hits/sec)with clients that can render it at that those rates. Pages just snap up in front of you. Very very nice. Your application stops getting in the way of people and users stop noticing your application even subconciously.
Users who really don't notice the difference even when switching to slower machines are the same users who don't notice what the dialog box said before they clicked OK, and will then tell you they didn't change or do anything.
Why so many words?
Dave _bsr's Law: They'll never be fast enough.
Computer, count to from 0 to infinity and finish it now.
Not useful? OK how about this:
Computer, do a statistical analysis of prime numbers vs normal numbers from 0 to infinity and tell me if you find anything interesting based on my previous interest in this subject, NOW.
--
Heck even the speed of light isn't fast enough. Ask any transcontinental quake player.
One word: ramdisk.
Here's a first example of what you can do. DVD or CD-Rom is very slow, hard drive space is faster and is cheap. So I copy the contents of my reference books from the DVD onto the hard drive. But this too is slow. So when my machine boots, I would like to be able to load a ramdisk image of two or three DVD's worth of reference material.
A second example, would be to do the same, but with something like the contents of /bin, /sbin, /usr/bin and /usr/sbin to speed up the execution of my bash and ksh scripts.
Having something like six gigabytes of memory would make this perfectly feasible.
That reminds me of the 640kByte anecdote.
I don't see this immediately happening in consumer (or even prosumer) systems however, because you'll either need a lot of dimm slots or very high density dimms and both will be quite expensive.
Please also note that I was reacting to the original poster's statement that 64bit processing would automatically make your system faster. That's simply not true. If you start adding lots of ram, then it will become faster because of the ram (which is indeed made possible because you have 64 bit address space, although like other have already said in this thread, the address bus is often already larger than 32 bits in the 32 bit processors we use today).
This was also in reaction to the statement that 64 bit processing would automatically make your system faster. If lots of programs had to do lots of 64bit calcuations, then this would be true. The fact is that very little calcualtions require 64 bit integer precision. Nothing says this won't change in the future, but until then your programs will not run any faster on a 64 bit processor (even when completely recompiled) than on a 32 bit processor. In fact, they'll most likely be slower because of the extra memory bandwidth that's necessary for loading pointers.Donate free food here
How cheap can you get? You take an interview between some second-rate reporters (pompously described as being "Executive Editor/News" and "Editor in Chief") and some marketing exec who cannot talk coherently, and just transcribe the conversation. Leaving aside the travel costs, you've got an article for the cost of twenty minutes' worth of typing secretary.
The monkey of an editor didn't even proof-read!
I'm enthusiastically waiting for Hammer (I'm waiting as fast as possibly I can)... but this kind of article makes me glad I don't shell out any schekels for eWeek.
technology is now not an issue. You can do almost anything you want to with technology. Can we now make it more useful? Can we make it more practical?
AMD will sell a certain number of chips because 64-bit is a sexy number, just like the obsession with clock speeds, just like people buy PCs with 32Mb of video ram to do WP.
But the quote above seems to me to encapsulate the challenge facing the IT industry in general. What qualititive difference does the latest processor - or the latest kernel for that matter - make to the end user? What real-world job will it let me do that I can't do now? In terms of servers, it is easy to answer the question. In terms of desktop machines, I'm not so sure.
Virtually serving coffee
Short answer:
0
Itanium = IBM PS/2. Hammer = PC AT.
Long answer:
Itanium is a VLIW architecture with a new 64 bit instruction set, that performs in-order execution (like an original Pentium, or a Sun UltraSparc.) It has very high floating point performance, because of its dual, fully pipelined FMAC units. The architecture is interesting in that it uses a wide variety of mechanisms (predicates, conditional loads/stores) to avoid branches without using speculation.
Because of its new instruction set, its not compatible with any prior software. *Everything* must be ported from scratch, and there is no prior install base from which to leverage. (Actually that's not strictly true -- it has an x86 compatibility mode that is exceedingly slow; its like a quarter to a third of the performance of leading x86s.)
Compilers in particular are a really different kind of beast on the IA-64. All the "out of order execution" techniques that are in most other modern CPUs have to be somehow implemented in the compiler. The performance of everything depends on these compilers, and so far only Intel and HP's compiler have measured up to snuff. SGI's, Microsoft's and gcc have been ported, but apparently aren't very credible. It appears as though creating good compilers for IA-64 is a truly monumental task.
Microsoft has gone on record as saying that they have no intention of porting Office to Itanium -- its not that kind of platform. Itanium is seen as a server only player. While one is tempted to say "oh but that will come to the desktop eventually", unless Microsoft (or Apple or Sun -- but those are even less likely) is willing to port a significant number of applications to it, that's just not going to happen. Microsoft has ported Windows to IA-64, but has pretty much stopped development of IA-64 at that point.
Itanium has been available for over a year now, and has had a very cold reception in the marketplace. Nobody wants them.
Hammer (Opteron) is just a 64 bit extension of the x86 architecture. If you are an assembly, or system level programmer take a look at this:
http://murl.microsoft.com/LectureDetails.asp?69
Its quite detailed. The key thing to note is that the x86-64 instructions are really just extensions of the IA-32 instructions. That means that all the compilers and tools work almost identically to how they worked for IA-32. The key features that have been added are: 64 bit registers, a 64 bit address space, and twice as many integer and SSE registers.
x86-64 remains backward compatible with ordinary x86 in two ways. If the chip boots as normal with a 32-bit OS, that is unaware of its 64-bit mode, than just like 16-bit DOS before it, it functions like a normal old 32-bit Athlon. It also contains two other interesting modes: 1) Long Mode (this is how 64-bit are enabled) and 2) Compatibility Mode.
Long Mode enables the new instructions, registers, address modes, etc. Compatibility mode allows it to execute the old 32-bit software in a virtual environment, much like the v86 mode used for DOS Boxes under Windows.
It is known that Microsoft has ported Windows to Hammer, and apparently Office and Internet Explorer are up and running on it. But don't be fooled, Microsoft didn't waste their time *porting* Office or Explorer to x86-64. They simply run in compatibility mode under this new Hammer enabled 64 bit Windows. That's the whole beauty of their scheme -- 32 bit and 64 bit applications can be running at the same time, sharing the same OS resources.
Now because x86-64 is so similar to IA-32, it allowed AMD to implement both long mode, and compatibility modes in the same pipelines, with optimal ALU usage, using the same instruction translation super-structures, the same rename registers, etc, etc. I.e., any effort AMD spends in speeding up the critical paths of 64 bit operations, translated back directly to 32 bit operations and vice versa. There is no compromise -- it will be a very fast 32 bit processor, as well as a very fast 64 bit processor.
While Hammer will not be quite at the same performance as IA-64 for floating point, it won't be that far behind, and it will almost surely cream it on integer performance. This much has been revealed by AMD/Intel's Spec CPU claims/disclosures thus far.
As far as selling Hammer? Its just a natural follow-on to Athlon. It won't cost more (it actually has a smaller die size, so it actually costs AMD *less* to make Opterons than Athlons) and it will be just as compatible with your software (Linux, Windows, or whatever.) At the very least, people *will* adopt them for the same reason they adopted the Athlon. So 64-bit ready desktops are going to ship middle of next year, and the customers *will* be lining up to get them (regardless of whether or not they use the 64 bit features, or even get the 64-bit Windows for it.)
Microsoft has gone on record as saying they endorse AMD's approach. And of course they don't need to commit one way or another to porting any applications, since they will all run at top speed on Hammer regardless. While there is nothing more overtly committed by Microsoft, reading between the lines will lead you to realize the Microsoft probably intends to port its DB and IIS to Hammer.
Linux, of course, has been ported to both, but I don't know if they have enabled the compatibility mode for Hammer.
When you think it's OK to screw people for buisness reasons, that's what you will get.
Friends don't help friends install M$ junk.
Well, that linux can't only be recompiled for a new platform in nearly every case is clear, since parts of it are coded in assembly, it needs drivers for the mb-chipsets and whatnot. This is where the arch/ subdir from the kernel tree comes into play.
For userland apps the story is completely different, the needed changes nearly all are cleanups, where the code wasn't 64bit clean.
IOW, the statement that you can do CFLAGS="-m64" on any app isn't true.
> For #2, realize that some integer operations are
> O(N) where N is the number of bits involved.
> 64-bit multiplication and division are slower
> than the same 32-bit operations. Period.
Not true. They are done in circiuts so you can use parallel algorithms. Mostly arithmetic ops are n log n so they dont take a significant amount of time longer. You do need more transistors though...
In the late 70's, we hit the limit of what 8-bit computing could do. 16-Bit processors were produced.
8 Years later 16 bit processors were hitting their limit. In '86 Intel produced a 32 bit processor.
Now, 16 years later, we will jump from 32 to 64 bit processors.
That should last us for another 32 years, then we'll hit the limit and really have to go with 128 bit. A Quick calc of the needed bits would be the year - 1970. Sure, we may not need 64 whole bits right now. But we do need more than 32. so the next obvious step is to just bump it up to the next power of two and wait it out.
(This is desktop microprocessors of course. High end and mainframe processors have advanced at earlier dates, but about the same intervals.)
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Infact thrashing occurs when an OS is unable to keep a large enough RMS(Resident Memory Size) of a process. It has *nothing* to do with the cache.
In Computer Engineering, "thrashing" refers to the overflow of any kind of cache, be it a CPU's cache of system RAM or system RAM's cache of the OS's virtual memory space (RAM plus swap plus what-have-you).
It is true that some applications will break if you simply try to compile them on a 64-bit platform. This is because those applications violate the C standard, typically assuming that sizeof(int)==sizeof(void *). Applications that make such assumptions aren't necessarily portable to other 32-bit platforms, let alone 64-bit. If you write your application badly to start with, it's not a surprise if it's harder to port. But if you write it well, porting to Hammer (or IA64, or Alpha) should be a piece of cake.
You can refactor til the cows come home, but that won't by itself isn't going to help with porting a poorly written application.
Seriously...
Now the biggest problem with your filth is that Hammer specs aren't out. system integrators need thermal information to make designs. And when Dell and friends get the thermal data, along with everyone else, then you can talk about what kind of heat output AMD-64 will have.
No shit. Didn't you even read my post? I said there was no definitive answer to his question... oh, never mind. We've been down this road before and all i'll get is more babble and garbage posts laden with personal insults i've already heard from you a million times before which were taken right out of some Elementary school playground.
Grow up. Seriously. It's been a month. A fucking MONTH and you still haven't gotten the point yet. I'M NOT LISTENING TO YOU. Get a life! Do something productive instead of wasting time spewing crap and typing shit nobody is interested in reading anyway.
-- Jim
Craig Mundie (perhaps a different MS PR Rep) said in an interview that he felt the GPL was unamerican, and suggested it might be something that congress should "look into". Dunno if MS has actually done anything about it, but comments like that plus campaign contributions might be all that's feasible. Don't want to go googling for links right now, sorry...
Intel has done no such thing, of course. I don't know what the hell the troll meant by saying that they were "backing" orgs trying to destroy OSS.
There are no trails. There are no trees out here.