I hate it whenever Mac-heads point to PPC and show how its such a great example of RISC that runs "all you're programs 2x as fast as the fastest Pentium4!" In all reality, the PowerPC line (not necessarily the POWER line) are very unimpressive. These days, a 1.25 GHz Alpha can still hold its own against a 2.5 GHz P4 in terms of floating point power. Yes, the same Alpha that has been neglected for the last half-decaded whose design has stagnated since the 21264 and whose process technology is antique compared to AMD's and Intel's. But the Alpha still keeps kicking x86 in the head. Yet, the PowerPC, running at the same 1.25 GHz, backed by the dual giants Motorola and IBM, built with leading edge copper fab technology, the second most common desktop RISC architecture (after x86:) shipping in every single Apple computer isn't even competitive with the P4. Damn you DEC! Damn you to all hell!
As for registers, I was very interested to find that a modern P4 maps the 8 x86 registers to 128 internal registers. Compare this to a G4 which only has 48 internal registers (32 visible, 16 rename).
Um, read up on processors in general. Just because the processor has 8 execution units, doesn't mean it has 8 times the number crunching capability, it doesn't even mean it can execute 8 instructions per cycle! The execution units on the Power4 are as such:
2 integer units 2 floating point units 2 load/store units 1 branch unit 1 condition evaluation unit
Now, only the first 3 of these really matter, because on most x86 processors, the last two are implemented totally differently and not included in the total execution unit count. Now, the P4 looks as follows:
2 2x integer units = 4 simple integer units (effective) 1 complex integer unit 1 floating point unit 1 FP load/store unit.
Now, the P4 has the Power4 totally beat in terms of integer units, and in FPU units is one short. Load store units are harder to compare, since most of these are integrated with address generation units on x86 proccessors. If you go with this simplistic definition, you can say that a P4 executes more than 7 instructions per cycle (counting loads by the AGUs).
Of course, this comparison is entirely theoretical. There are tons of limitations in the instruction decoders and issue queues that greatly change the numbers. The Power4 appears to have more issue bandwidth, while the P4 saves a lot of time by caching decoded instructions via the Trace Cache. Of course, this doesn't count the biggest bottleneck: code level parallelism. Most code can't be partitioned in such a way as to keep 4 totally different groups of execution units busy. You'll almost never get 8 instructions per cycle through either architecture.
Actually, there is a reference to this in one book or the other I've read. A black hole does not have to have infinite density, mearly enough mass to bend light back to itself. As I said before, the earth would become a black hole if compressed to around 1 cm. That is most definately not infinite density. I think you're mistaking the density of the singularity with the overall density of the black hole.
Um, no, because a 64-bit processor doesn't necessarily issue more instructions per cycle than a 32-bit processor. My palmtop uses a 64-bit CPU that dispatches 2 integer instructions per cycle, while my desktop uses a 32-bit CPU that dispatches 3 integer instructions per cycle. The number of bits in the CPU has nothing to do with the number of instructions dispatched per cycle.
Actually, he said something about the chip not being DDR, which didn't really make any sense. DDR memory works perfectly fine on a non-DDR processor bus (the PIII). In fact, DDR memory also works fine on a quad data rate processor bus (the P4). What's the real issue is the total bandwidth of the CPU bus, not the CPU's ability to support DDR RAM (that's the responsibility of the NorthBridge anyway).
The reason is that it's really a lot of wasted space. You don't often need 64 bit instructions, because the opcode takes maybe 5 or 6 bits, and register references take another 5 or 6 bits. In most cases, you reference memory fairly close to the current program counter, and current 64-bit archs use that fact to stick maybe a 20-something bit PC-relative address in the instruction. If a larger offset is needed, then instructions are emitted that either load the address in two seperate instructions, or stick a full 32-bit address within a 20-bit offset from the PC and load a pointer from there. This tricks may be ugly, but they greatly decrease code footprint.
Not really. As has said before, earth would have to be 1cm across to be a black hole. All the matter in the universe would only have to be about 15 billion light years across, or roughly the size of the universe.
Um, the choice of a monolithic kernel doesn't automatically make the kernel uninteresting. It's like the car industry. Just because they all use the same basic model of a cab on four wheels doesn't mean there is no innovation going on. Originally, Linux's scheduler was pretty interesting. These days, there are tons of things that are interesting, all over the kernel.
Hmm, debugging shouldn't really make things 10 times larger. Maybe it's some weird GCC/C++ interaction. Either way, what, then is your point? Windows programs don't ship with debugging built in (and only developers should enable it anyway), so it's quite right to say that KDE is rather slim.
Actually, the DDR thing is a little misguided. The real reason DDR had no effect was because the 2.1 GB of memory bandwidth was feeding into 1.3 GB/sec of processor bus bandwidth.
It's not as simple as that. The P4 takes a huge hit for its long pipeline. Even if IPC increases due to extra execution units (which won't help non-parallellizable code at all) it will decrease due to worse penalties for pipeline flushes.
The 64bit architecture: Lightwave [if rewritten to be 64bit] will be able to use bigger numbers, and use more memory. Bigger numbers means that calculations that would involve making a 64bit word out of 2 32bit words [as it currently stands] needn't be done. Being able to address more memory is *always* a good thing. >>>>>>>> More memory, maybe, but the 64-bit integers are nearly useless. I doubt lightwave is dealing with any integers in performance intensive code, much less 64-bit ones. What's more important is 128-bit floating point SIMD, and everyone already has that.
The 900MHz bus will allow a *huge* amount of memory to be shuttled back and forth from the processor *very* quickly. This means your huge scenes will be rendered faster. >>>>>>>>>>> Yep, very much so.
Altivec/Vector Processing unit: Because the VPU doesn't do double precision FP, it doesn't help in the final rendering [much]. It *will* help in things like realtime previews, where the math is simplified. Imagine *big* previews of scenes in realtime. >>>>>>>>>> Hah hah, SSE2 does.
4)64 bit programing is more efficent, you can crunch more numbers per cycle which will speed up some applications...don't fall into the "consumers don't need 64 bit" crowd. >>>>>>>>>> Err, you can crunch bigger numbers per cycle. If you don't use any integers larger than 2^32, you're just wasting 32 extra bits. Consumers do need 64 bits, but not for the reason you mention.
SpecFP has almost been reduced to a memory throughput test. >>>>>>> Because in this age of 128 bit vector fp units, fp in general is basically a memory throughput thing. And the G4's pathetic 1.3 GB/sec is killing it.
The 7.2 GB/sec of bandwidth is just not much more than double that of existing P4s (P4 = 4.2 GB/sec) and since Hammer will have 6.4 GB/sec in early 2003, should be essentially the same as competing x86 chips.
I feel sorry for you. Sounds to me, that you will always be unhappy with performance. >>>>>>>>>> Actually, I was perfectly happy with the performance of BeOS on my old PII-300, and with the performance of Win2k (just the UI, not overall). Both those OSs offered instant or near instant response, which is all I'm asking for. 1/4 of a second is about 250ms. You can do a couple of dozen hard drive accesses in that time. Needing more than that for the relatively simple processing required for UIs is just criminal.
How ridiculous. When OSX was at 10.1.4 on my 300MHz G3 (128MB) it was annoyingly slow. But the upgrade to 10.1.5 was a MASSIVE improvement, making it a joy to use. Jaguar is even faster, even though Quartz Extreme does not support my video controller. >>>>>>>>>> This was with X.2 by the way.
If KDE3 is "barely" usable for you on your 2GHz P4, why the hell are you using it? Go WindowMaker, AfterStep, etc if you want lightning fast. >>>>>>>>>>.. Barely usable for me == lightning fast. Just south of instant. I can't go WindowMaker or AfterStep because I end up using KDE apps anyway (Konqueror, Kopete). I've got some complaints, such as even the simplest apps taking over a second to start up, but overall I'm quite happy with it. If I wasn't (and before, on my PII I wasn't) I wouldn't use it.
To think I used to use Linux on a 486DX33 with a badly supported Diamond SpeedStar 24X.
KDE Is only that large if install *everything*. Otherwise, it probably can fit in 20MB. Besides, you're 2GB figure is *way* off. I've got a Gentoo install with O3-optimized (read: larger than usual) binaries.
du --total -s/usr/kde/3.1 gives me 278,468 KB du --total -s/usr/qt/3.1 gives me 54,452 KB
In total, around 300 MB, not bad considering that this is a full KDE 3.1 install, which includes a browser, mail client, PIM, office suite, two imaging apps, several games, several educational programs, a couple of multimedia players, a dozen utilities, half a dozen network clients, Postscript/PDF viewer, a CD ripper, and an MP3 jukebox!
Slashdot Mirror
Where did I say that? You're making no sense at all! Are you just fooling with my head or what?
I hate it whenever Mac-heads point to PPC and show how its such a great example of RISC that runs "all you're programs 2x as fast as the fastest Pentium4!" In all reality, the PowerPC line (not necessarily the POWER line) are very unimpressive. These days, a 1.25 GHz Alpha can still hold its own against a 2.5 GHz P4 in terms of floating point power. Yes, the same Alpha that has been neglected for the last half-decaded whose design has stagnated since the 21264 and whose process technology is antique compared to AMD's and Intel's. But the Alpha still keeps kicking x86 in the head. Yet, the PowerPC, running at the same 1.25 GHz, backed by the dual giants Motorola and IBM, built with leading edge copper fab technology, the second most common desktop RISC architecture (after x86 :) shipping in every single Apple computer isn't even competitive with the P4. Damn you DEC! Damn you to all hell!
As for registers, I was very interested to find that a modern P4 maps the 8 x86 registers to 128 internal registers. Compare this to a G4 which only has 48 internal registers (32 visible, 16 rename).
Um, read up on processors in general. Just because the processor has 8 execution units, doesn't mean it has 8 times the number crunching capability, it doesn't even mean it can execute 8 instructions per cycle! The execution units on the Power4 are as such:
2 integer units
2 floating point units
2 load/store units
1 branch unit
1 condition evaluation unit
Now, only the first 3 of these really matter, because on most x86 processors, the last two are implemented totally differently and not included in the total execution unit count. Now, the P4 looks as follows:
2 2x integer units = 4 simple integer units (effective)
1 complex integer unit
1 floating point unit
1 FP load/store unit.
Now, the P4 has the Power4 totally beat in terms of integer units, and in FPU units is one short. Load store units are harder to compare, since most of these are integrated with address generation units on x86 proccessors. If you go with this simplistic definition, you can say that a P4 executes more than 7 instructions per cycle (counting loads by the AGUs).
Of course, this comparison is entirely theoretical. There are tons of limitations in the instruction decoders and issue queues that greatly change the numbers. The Power4 appears to have more issue bandwidth, while the P4 saves a lot of time by caching decoded instructions via the Trace Cache. Of course, this doesn't count the biggest bottleneck: code level parallelism. Most code can't be partitioned in such a way as to keep 4 totally different groups of execution units busy. You'll almost never get 8 instructions per cycle through either architecture.
Ok, that was a brainfault on my part.
>>>>>>>>
Is that more like a page fault or a TLB fault?
---
Great, we've degenerated into MMU humor...
Actually, there is a reference to this in one book or the other I've read. A black hole does not have to have infinite density, mearly enough mass to bend light back to itself. As I said before, the earth would become a black hole if compressed to around 1 cm. That is most definately not infinite density. I think you're mistaking the density of the singularity with the overall density of the black hole.
Depends, the G4e has a 7 stage pipeline, so tripling it would make it 21 stages.
Um, no, because a 64-bit processor doesn't necessarily issue more instructions per cycle than a 32-bit processor. My palmtop uses a 64-bit CPU that dispatches 2 integer instructions per cycle, while my desktop uses a 32-bit CPU that dispatches 3 integer instructions per cycle. The number of bits in the CPU has nothing to do with the number of instructions dispatched per cycle.
Actually, he said something about the chip not being DDR, which didn't really make any sense. DDR memory works perfectly fine on a non-DDR processor bus (the PIII). In fact, DDR memory also works fine on a quad data rate processor bus (the P4). What's the real issue is the total bandwidth of the CPU bus, not the CPU's ability to support DDR RAM (that's the responsibility of the NorthBridge anyway).
The reason is that it's really a lot of wasted space. You don't often need 64 bit instructions, because the opcode takes maybe 5 or 6 bits, and register references take another 5 or 6 bits. In most cases, you reference memory fairly close to the current program counter, and current 64-bit archs use that fact to stick maybe a 20-something bit PC-relative address in the instruction. If a larger offset is needed, then instructions are emitted that either load the address in two seperate instructions, or stick a full 32-bit address within a 20-bit offset from the PC and load a pointer from there. This tricks may be ugly, but they greatly decrease code footprint.
Not really. As has said before, earth would have to be 1cm across to be a black hole. All the matter in the universe would only have to be about 15 billion light years across, or roughly the size of the universe.
Um, the choice of a monolithic kernel doesn't automatically make the kernel uninteresting. It's like the car industry. Just because they all use the same basic model of a cab on four wheels doesn't mean there is no innovation going on. Originally, Linux's scheduler was pretty interesting. These days, there are tons of things that are interesting, all over the kernel.
I've been using NVIDIA Linux drivers since they came out, on everything from a TNT to a GeForce4 MX. I've never had a single crash.
Fewer levels to the page table? All the 64-bit archs I've seen have more page table levels.
Hmm, debugging shouldn't really make things 10 times larger. Maybe it's some weird GCC/C++ interaction. Either way, what, then is your point? Windows programs don't ship with debugging built in (and only developers should enable it anyway), so it's quite right to say that KDE is rather slim.
Unless this machine is radically different than other 64-bit RISC architectures (it's not) it uses 32-bit instructions.
Actually, the DDR thing is a little misguided. The real reason DDR had no effect was because the 2.1 GB of memory bandwidth was feeding into 1.3 GB/sec of processor bus bandwidth.
It's not as simple as that. The P4 takes a huge hit for its long pipeline. Even if IPC increases due to extra execution units (which won't help non-parallellizable code at all) it will decrease due to worse penalties for pipeline flushes.
The 64bit architecture:
Lightwave [if rewritten to be 64bit] will be able to use bigger numbers, and use more memory. Bigger numbers means that calculations that would involve making a 64bit word out of 2 32bit words [as it currently stands] needn't be done. Being able to address more memory is *always* a good thing.
>>>>>>>>
More memory, maybe, but the 64-bit integers are nearly useless. I doubt lightwave is dealing with any integers in performance intensive code, much less 64-bit ones. What's more important is 128-bit floating point SIMD, and everyone already has that.
The 900MHz bus will allow a *huge* amount of memory to be shuttled back and forth from the processor *very* quickly. This means your huge scenes will be rendered faster.
>>>>>>>>>>>
Yep, very much so.
Altivec/Vector Processing unit:
Because the VPU doesn't do double precision FP, it doesn't help in the final rendering [much]. It *will* help in things like realtime previews, where the math is simplified. Imagine *big* previews of scenes in realtime.
>>>>>>>>>>
Hah hah, SSE2 does.
4)64 bit programing is more efficent, you can crunch more numbers per cycle which will speed up some applications...don't fall into the "consumers don't need 64 bit" crowd.
>>>>>>>>>>
Err, you can crunch bigger numbers per cycle. If you don't use any integers larger than 2^32, you're just wasting 32 extra bits. Consumers do need 64 bits, but not for the reason you mention.
SpecFP has almost been reduced to a memory throughput test.
>>>>>>>
Because in this age of 128 bit vector fp units, fp in general is basically a memory throughput thing. And the G4's pathetic 1.3 GB/sec is killing it.
The 7.2 GB/sec of bandwidth is just not much more than double that of existing P4s (P4 = 4.2 GB/sec) and since Hammer will have 6.4 GB/sec in early 2003, should be essentially the same as competing x86 chips.
Actually, I'm using a 100% kde desktop, and everything uses native widgets, even my drafting app!
I feel sorry for you. Sounds to me, that you will always be unhappy with performance.
>>>>>>>>>>
Actually, I was perfectly happy with the performance of BeOS on my old PII-300, and with the performance of Win2k (just the UI, not overall). Both those OSs offered instant or near instant response, which is all I'm asking for. 1/4 of a second is about 250ms. You can do a couple of dozen hard drive accesses in that time. Needing more than that for the relatively simple processing required for UIs is just criminal.
How ridiculous. When OSX was at 10.1.4 on my 300MHz G3 (128MB) it was annoyingly slow. But the upgrade to 10.1.5 was a MASSIVE improvement, making it a joy to use. Jaguar is even faster, even though Quartz Extreme does not support my video controller.
>>>>>>>>>>
This was with X.2 by the way.
If KDE3 is "barely" usable for you on your 2GHz P4, why the hell are you using it? Go WindowMaker, AfterStep, etc if you want lightning fast.
>>>>>>>>>>..
Barely usable for me == lightning fast. Just south of instant. I can't go WindowMaker or AfterStep because I end up using KDE apps anyway (Konqueror, Kopete). I've got some complaints, such as even the simplest apps taking over a second to start up, but overall I'm quite happy with it. If I wasn't (and before, on my PII I wasn't) I wouldn't use it.
To think I used to use Linux on a 486DX33 with a badly supported Diamond SpeedStar 24X.
KDE Is only that large if install *everything*. Otherwise, it probably can fit in 20MB. Besides, you're 2GB figure is *way* off. I've got a Gentoo install with O3-optimized (read: larger than usual) binaries.
/usr/kde/3.1 gives me 278,468 KB /usr/qt/3.1 gives me 54,452 KB
du --total -s
du --total -s
In total, around 300 MB, not bad considering that this is a full KDE 3.1 install, which includes a browser, mail client, PIM, office suite, two imaging apps, several games, several educational programs, a couple of multimedia players, a dozen utilities, half a dozen network clients, Postscript/PDF viewer, a CD ripper, and an MP3 jukebox!