Oh, ok, so it wasn't a cut-and-paste job. But I still don't understand the "better movies" angle. Are you talking about that one reference to a "3-D movie"?
You're right, of course, but I think she was talking about web applications, where most people's browser doesn't support the standards. This problem is far worse with web apps than with Scheme, Java, or C++, although the latter did suffer severely with this problem a while back.
If everything else were the same, an 8-bit CPU would blow the pants off of a 32-bit CPU, for benchmarks that don't need more than 8 bits.
Explain it to me: where does the speed come from?
I can think of only one way in which a souped-up 6502 would beat a 32-bit processor: the 6502's pointers are only 16 bits. That makes the data structures smaller. Therefore, if you can find a 6502 program whose data structures fit in 64KB, but don't fit in the 64KB L1 cache of a modern 32-bit CPU, and doesn't suffer from the suffocating lack of registers, and spends most of its time doing 8-bit math, then the 6502 might have an advantage on that particular program.
In other situation, to say the 6502 would beat a moden processor is pure nostalgia.
A 64-bit processor isn't going to be inherently faster than a 32-bit processor, except for code that needs 64 bits.
By similar logic, a 32-bit processor is likely to be inherently faster than an 8-bit processor on any code that "needs" more than 8 bits, which is practically all code.
The fastest 64-bit AMD is rated 2.0ghz while the fastest AMD 32-bit is 2.2ghz.
First, that certainly doesn't mean the 64-bit chip is slower. AMD is not like Intel: they don't focus their design on stratospheric clock speeds, but on overall performance. The K8 core is faster cycle-per-cycle than the K7.
Third, even if there weren't, Moore's law tells us that a 10% clock speed difference amounts to, what, 11 weeks? So the K8 would be caught up by April. So who cares?
Using modern technology to build a 386 chip would result in one of the highest clock speeds ever but it would be practically useless.
This doesn't make any sense. If you use modern technology, it's not a 386, it's a Xeon. That's what a Xeon is.
Ok, let's think about this. For starters, the 6502 needed something like 2-8 clock cycles per instruction. In contrast, the Athlon 64 can execute 3 instructions per cycle.
Besides, you couldn't possibly run a 6502 at 2GHz with today's technology. The chip is not pipelined, so there is way to much logic to complete in each 500ps clock cycle.
Even if you made a new 6502-compatible design that runs at 2GHz, it only had one 8-bit general-purpose register, so to do any useful math would require a lot of arithmetic instructions and a hell of a lot of spills. And where would these spills go? The stack is only 256 bytes.
Want to multiply two 32-bit numbers? Be prepared to do 16 individual multiply operations. And guess what? 6502 has no multiply instruction, so each of those 16 multiplies requires a series of shifts and adds. Plus, the result of each multiply is 16 bits long, so it won't fit in your one GPR. You either need to keep part of the result in memory or in one of the index registers, and either of those is painful. I remember tuning an 8 x 8 -> 16-bit multiply and getting it down to about 200 clock cycles, and that was the best I could do. So, you can expect your 32 x 32-bit multiply to take something like 3000 clock cycles and involve dozens or hundreds of loads and stores.
The moral of the story is, almost every architectural difference between the 6502 and modern CPUs exists for one reason: speed. Still think a 2GHz 6502 would be a screamer?
A millionth of an inch? The rifle bullet is only travelling about five times the speed of sound, so you only need to move the microphone one inch for each five inches the bullet moves. The electronic tuning might still be easier, but it's not really necessary.
A while back, I was looking into more efficient heap storage of Java objects, and found that the heap of a variety of Java programs consist of about half pointers and half ints. The next most common type was booleans, and they were under 1%. Everything else was vanishingly small.
Thus, you can expect Java heaps to expand by about 50% when moving from 32-bit to 64-bit pointers. What effect this has on your program's performance depends on the relation between the program's resident sets and the machine's cache. For instance, if your program has a resident set of 200KB on a machine with a 256KB cache, then the extra 50% will blow the cache and kill your performance. If the resident set were 150KB, the performance impact would probably be minimal.
Disclaimer: I was doing this as a pet project in my spare time, so take these numbers with a grain of salt.
Neither does it change the simple fact that the processor has twice as many architected registers, and so will likely show a substantial performance boost from a simple recompile (assuming the code is 64-bit clean).
Slashdot Mirror
Indeed, but if my government blindly accepted and used your binaries, I would be mighty upset.
Question: how can one trust a BitTorrent link from an untrusted source? What's the best way to ensure you're getting the real deal?
Dude, the joke is over.
Thanks for the explanation.
I think you cut and pasted that comment into the wrong article. This is not about Cameron going into space. It's about commissioning drawings.
Uh, no it didn't. Read the parent post he replied to, not the grandparent post.
Yep, it works: http://www.google.ca/search?q=litigious+bastards&b tnI=1.
So what exactly is your advice? Basically do a bit of everything, but not too much? I don't see how that's helpful.
You're right, of course, but I think she was talking about web applications, where most people's browser doesn't support the standards. This problem is far worse with web apps than with Scheme, Java, or C++, although the latter did suffer severely with this problem a while back.
I can't think of any reason a game would use 64-bit integers. The advantage of AMD64 for games would be from the extra registers.
That's great advice, since clearly there couldn't possibly be anyone who would want a uniprocessor machine.
Some dingbat makes this argument every time computer performance is mentioned. I swear I'm going to start making all you dummies as Foes.
The image is just a man's face.
I can think of only one way in which a souped-up 6502 would beat a 32-bit processor: the 6502's pointers are only 16 bits. That makes the data structures smaller. Therefore, if you can find a 6502 program whose data structures fit in 64KB, but don't fit in the 64KB L1 cache of a modern 32-bit CPU, and doesn't suffer from the suffocating lack of registers, and spends most of its time doing 8-bit math, then the 6502 might have an advantage on that particular program.
In other situation, to say the 6502 would beat a moden processor is pure nostalgia.
By similar logic, a 32-bit processor is likely to be inherently faster than an 8-bit processor on any code that "needs" more than 8 bits, which is practically all code.Second, there is a 2.2GHz Opteron, as these SPECjbb2000 results show.
Third, even if there weren't, Moore's law tells us that a 10% clock speed difference amounts to, what, 11 weeks? So the K8 would be caught up by April. So who cares?
This doesn't make any sense. If you use modern technology, it's not a 386, it's a Xeon. That's what a Xeon is.Maybe I just don't understand what you're saying.
Besides, you couldn't possibly run a 6502 at 2GHz with today's technology. The chip is not pipelined, so there is way to much logic to complete in each 500ps clock cycle.
Even if you made a new 6502-compatible design that runs at 2GHz, it only had one 8-bit general-purpose register, so to do any useful math would require a lot of arithmetic instructions and a hell of a lot of spills. And where would these spills go? The stack is only 256 bytes.
Want to multiply two 32-bit numbers? Be prepared to do 16 individual multiply operations. And guess what? 6502 has no multiply instruction, so each of those 16 multiplies requires a series of shifts and adds. Plus, the result of each multiply is 16 bits long, so it won't fit in your one GPR. You either need to keep part of the result in memory or in one of the index registers, and either of those is painful. I remember tuning an 8 x 8 -> 16-bit multiply and getting it down to about 200 clock cycles, and that was the best I could do. So, you can expect your 32 x 32-bit multiply to take something like 3000 clock cycles and involve dozens or hundreds of loads and stores.
The moral of the story is, almost every architectural difference between the 6502 and modern CPUs exists for one reason: speed. Still think a 2GHz 6502 would be a screamer?
A millionth of an inch? The rifle bullet is only travelling about five times the speed of sound, so you only need to move the microphone one inch for each five inches the bullet moves. The electronic tuning might still be easier, but it's not really necessary.
No need for an electronic delay, I think. Just put the microphone in the appropriate place. The bullet travels faster than the sound anyway.
Yes.
Thus, you can expect Java heaps to expand by about 50% when moving from 32-bit to 64-bit pointers. What effect this has on your program's performance depends on the relation between the program's resident sets and the machine's cache. For instance, if your program has a resident set of 200KB on a machine with a 256KB cache, then the extra 50% will blow the cache and kill your performance. If the resident set were 150KB, the performance impact would probably be minimal.
Disclaimer: I was doing this as a pet project in my spare time, so take these numbers with a grain of salt.
Did you read his business proposal?
Point taken though.