Quite. It defines a quality treshold and uses as much bitrate as needed to keep it. Unless you have real problems with bitrates going over a certain treshold (streaming, for example), its the best way. Not only it saves some space on parts of music that don't need less than average bit rate but it saves you from glitches in the parts where you really needed a bit more.
Err... no can do, sorry. The x86-64 "extensions" are only avalibla under Long Mode, so you need both a complian OS and application. And, while in MS-DOS applications could just go to protected mode on its own, you can't pull that stunt in a modern OS.
3 MB of on chip L3 cache might just have something to do with it. That apart, the CPU core itself is not that big, as it doesn't have any OoO execution suport. The version mentioned in the article you pointed to is the single CPU version (then codenamed ClawHammer) with some 256/512kB cache (not really sure). AMD also has plans for MP versions (then codenamed SledgHammer) with up to 1 MB cache, so these are likely to be bigger.
Its not diferent formats. Just diferent encoder options. The oggq0 entries are for music enconded in a Variable Bit Rate mode (oggenc -q0) -- the encoder defines a quality treshold and uses whatever bitrate necessary to keep it there. The ogg64 entries are for music encoded with a nominal bitrate (oggenc -b 64 --manage) -- it atemts to keep the bitrate around 64 kbps without looking at sound quality. Why did only Ogg Vorbis got to show these two modes? Because though the test focuses on 64kbps (nominal bit rate) encoding, its likely than most Ogg Vorbis users will use variable bit rate encoding with it. I know I do.
Sid will never be frozen. Sid (Still In Development) is always the unstable distribution. The new Testing distributio is sarge. And hopefully, it won't take 2.5 years till the next version.
In 1996 a Hummer entered the Dakar. Due to its weight, it ran in the truck class.
Still, it proved slower than bigger trucks -- about 96 hours slower.
Results
Re:I downloaded Debian two days ago
on
Gentoo Linux 1.2
·
· Score: 1
KDE3 won't go into Sid until the XFree86 maintainer has XF86 4.2 up and running in all 11 archs.
like Debian, which steadfastly refuses to compile for any x86 other then 386. They say the speed benefit is not big enough, which may be the case.
Debian provides a few optimized packages (libc and kernel) but until they start to use GCC 3.x as the official compiler, the speed gain isn't really worth the trouble.
Also, the package system doesn't support the coexistence of multiple architecture revisions _yet_ -- and there isn't much point in having stuff like "ls" optimized is there?.
But, hopefully, it shouldn't take long before we see it.
This is so wrong I have to comment.
BTW, Intel x86 and derived aren't the only CISC architectures out there. Its just the last one still being developed.
First, why do you assume because a RISC will take more instructions to do the same job will lead to more dependency on memory?
Do you assume that RISC and CISC instructions have the same size? Don't. And most of the memory problems dependency will be from data LOADs and STOREs, not instructions FETCHs (due to caches).
Second, superscalar execution has been present on
RISC chips long before CISC (the Pentium is the only true CISC superscalar CPU I know - capable of executing 2 instructions in parallel).
Even the current hybrid Pentiums and Athlons try their best to make up to 3 OPs in parallel from x86 code (that unfortunately isn't very prone to intruction level paralelism) to feed their RISC-like cores, while modern RISCs are 4 way superscalar.
And then you have all the nice things like speculative and out-of-order execution, which I doubt anyone has ever considered in implementing in a true CISC CPU.
Pentiums and Athlons have the performance and price they have because the sell by the million. There is lots of money to go into R&D for them, putting them at over 2 GHz. And even then they had to use RISC like cores to keep up the pace.
Sun's 64-bit SPARC are named UltraSparc. Sun's Blades are workstations based on Sun UltraSparc CPUs, not a CPU.
Itaniums (first generation are avaliable).
Current AS/400 systems are based on Power4 CPUs too. Don't remeber if the older ones were 64-bit too but I think so.
AIX is IBM's Unix, not a CPU.
You also have 64-bit MIPS and IBM's zSeries.
All up, running and selling.
First, to take advantage of *any* of x86-64 improvements you need an OS supporting the Long Mode. Without that, it will be an ordinary x86 CPU.
This is not the best place to say it but... Windows isn't in the horizon and Penguins don't rule the market yet...
Second, its improvements are limited. More than the ordinary 32 vs 64 bit comparisson shows.
Quoting from AMD's overview:
64-bit flat virtual addressing.
This is good if you care about more than 4 GB memory, useless if you don't. That simples.
8 new general purpose registers (GPRs).
This is plain good. It will allow for faster and with more Instruction Level Paralelism code.
8 new registers for streaming SIMD extensions (SSE).
Same as above.
64-bit wide GRPs and instruction pointer.
You need this to support the 64 bit addressing.
Some aplications may also take advantage of the ability to manipulate 64-bit integers at once.
And thats it! Some migh noticed I didn't refer to the floating point numbers. The FPU, that is already capable of handling 32, 64 and 80-bit floats won't be extended. Same thing with MMX and SSE (with exception of the 8 new registers).
Even if they have an OS suporting long mode, how willing will software vendors be to put money in a x86-64 64-bit version of their software?
Re:Different design decision wishes
on
If I Had a Hammer
·
· Score: 1
x86-64 has 16 64bit General Purpose Registers. Each of those has its 32, 16 and, for most, 8bit partial registers. Partial registers simply explained: though we write rax, eax, ax and al, these are all the same thing: al are the lower 8 bits of ax, which with the 386 became the lower 16 of eax which are the lower 32 of rax.
For instructions that work on GPRs, which all had 8, 16 and 32 bit versions, x86-64 brings the 64 bit versions, off course (with exceptions: some instrucions were droped in x86-64 and won't be missed).
The actual diference between all this is mostly operand size. Operand size is importan in x86/x86-64 as it can take memory adresses as operands.
So, what you propose is a hell of a mess...
Read
more.
Is there any way to link 32 bit data with a 32 bit instruction, ala Itanic?
I'd explain, but I can't even understant what you're talking about.:-)
Cache speed (USIIIs' 8 MB are off chip, for example) and price.
Still, you're bloody right.
With Pentium4, Intel decided that only Xeons would have MP support, so that is the diference to a regular Pentium4 (same cache size).
In the good old PentiumII/III, every chip suported MP and the Xeons just had more L2 cache (up to 2 MB).
First, Compaq sold the Alpha because Alphas never sold well enough and was becoming too big of a burden for Compaq.
Second, EPIC is a concept behind ISA design, as CISC, RISC, VLIW (here is where someone will say that EPIC is just Intelspeak for VLIW). If you design an ISA by one, you can't improve it to another. You design another ISA from scratch.
Third, the Alpha suports 64 bit adressing and data manipulation. Actually, unlike most other 64 bit RISC ISAs, Alpha doesn't even have a 32 bit relative.
Slashdot Mirror
Quite. It defines a quality treshold and uses as much bitrate as needed to keep it.
Unless you have real problems with bitrates going over a certain treshold (streaming, for example), its the best way.
Not only it saves some space on parts of music that don't need less than average bit rate but it saves you from glitches in the parts where you really needed a bit more.
Err... no can do, sorry.
The x86-64 "extensions" are only avalibla under Long Mode, so you need both a complian OS and application.
And, while in MS-DOS applications could just go to protected mode on its own, you can't pull that stunt in a modern OS.
3 MB of on chip L3 cache might just have something to do with it. That apart, the CPU core itself is not that big, as it doesn't have any OoO execution suport.
The version mentioned in the article you pointed to is the single CPU version (then codenamed ClawHammer) with some 256/512kB cache (not really sure).
AMD also has plans for MP versions (then codenamed SledgHammer) with up to 1 MB cache, so these are likely to be bigger.
Its not diferent formats. Just diferent encoder options.
The oggq0 entries are for music enconded in a Variable Bit Rate mode (oggenc -q0) -- the encoder defines a quality treshold and uses whatever bitrate necessary to keep it there.
The ogg64 entries are for music encoded with a nominal bitrate (oggenc -b 64 --manage) -- it atemts to keep the bitrate around 64 kbps without looking at sound quality.
Why did only Ogg Vorbis got to show these two modes? Because though the test focuses on 64kbps (nominal bit rate) encoding, its likely than most Ogg Vorbis users will use variable bit rate encoding with it. I know I do.
Sid will never be frozen. Sid (Still In Development) is always the unstable distribution. The new Testing distributio is sarge.
And hopefully, it won't take 2.5 years till the next version.
In 1996 a Hummer entered the Dakar. Due to its weight, it ran in the truck class.
Still, it proved slower than bigger trucks -- about 96 hours slower.
Results
KDE3 won't go into Sid until the XFree86 maintainer has XF86 4.2 up and running in all 11 archs.
like Debian, which steadfastly refuses to compile for any x86 other then 386. They say the speed benefit is not big enough, which may be the case.
Debian provides a few optimized packages (libc and kernel) but until they start to use GCC 3.x as the official compiler, the speed gain isn't really worth the trouble.Also, the package system doesn't support the coexistence of multiple architecture revisions _yet_ -- and there isn't much point in having stuff like "ls" optimized is there?.
But, hopefully, it shouldn't take long before we see it.
Yes. It actually happened about a post on rec.humor.funny.
Link...
This is so wrong I have to comment.
BTW, Intel x86 and derived aren't the only CISC architectures out there. Its just the last one still being developed.
First, why do you assume because a RISC will take more instructions to do the same job will lead to more dependency on memory?
Do you assume that RISC and CISC instructions have the same size? Don't. And most of the memory problems dependency will be from data LOADs and STOREs, not instructions FETCHs (due to caches).
Second, superscalar execution has been present on RISC chips long before CISC (the Pentium is the only true CISC superscalar CPU I know - capable of executing 2 instructions in parallel).
Even the current hybrid Pentiums and Athlons try their best to make up to 3 OPs in parallel from x86 code (that unfortunately isn't very prone to intruction level paralelism) to feed their RISC-like cores, while modern RISCs are 4 way superscalar.
And then you have all the nice things like speculative and out-of-order execution, which I doubt anyone has ever considered in implementing in a true CISC CPU.
Pentiums and Athlons have the performance and price they have because the sell by the million. There is lots of money to go into R&D for them, putting them at over 2 GHz. And even then they had to use RISC like cores to keep up the pace.
Alphas are awfull expensive.
Even a G4 is quite expensive.
And they can't run your x86 software decently
So, we stick to Pentium/Athlon.
Actully x86 instrucions have variable sizes, from 1 to 17 (yep, seventeen) bytes.
Sun's 64-bit SPARC are named UltraSparc. Sun's Blades are workstations based on Sun UltraSparc CPUs, not a CPU.
Itaniums (first generation are avaliable).
Current AS/400 systems are based on Power4 CPUs too. Don't remeber if the older ones were 64-bit too but I think so.
AIX is IBM's Unix, not a CPU.
You also have 64-bit MIPS and IBM's zSeries.
All up, running and selling.
The UltraSparc III have off-die L3 cache.
The SPARC have off-die cache.
Last option
This is not the best place to say it but... Windows isn't in the horizon and Penguins don't rule the market yet...
Second, its improvements are limited. More than the ordinary 32 vs 64 bit comparisson shows.
Quoting from AMD's overview:
64-bit flat virtual addressing.
This is good if you care about more than 4 GB memory, useless if you don't. That simples.
8 new general purpose registers (GPRs).
This is plain good. It will allow for faster and with more Instruction Level Paralelism code.
8 new registers for streaming SIMD extensions (SSE).
Same as above.
64-bit wide GRPs and instruction pointer.
You need this to support the 64 bit addressing.
Some aplications may also take advantage of the ability to manipulate 64-bit integers at once.
And thats it! Some migh noticed I didn't refer to the floating point numbers. The FPU, that is already capable of handling 32, 64 and 80-bit floats won't be extended. Same thing with MMX and SSE (with exception of the 8 new registers).
Even if they have an OS suporting long mode, how willing will software vendors be to put money in a x86-64 64-bit version of their software?
For instructions that work on GPRs, which all had 8, 16 and 32 bit versions, x86-64 brings the 64 bit versions, off course (with exceptions: some instrucions were droped in x86-64 and won't be missed).
The actual diference between all this is mostly operand size. Operand size is importan in x86/x86-64 as it can take memory adresses as operands.
So, what you propose is a hell of a mess...
Read more.
Is there any way to link 32 bit data with a 32 bit instruction, ala Itanic?
I'd explain, but I can't even understant what you're talking about. :-)
Actually, Rambus has been working on QDR for a few years now. We might see that out in less that 3 years.
Extension. Check www.x86-64.org for some doc.
And most of the work was done by Digital (and SGI for MIPS).
But M$ already did a full 64 bit port of Windows for IA-64...
Galeon is multi-threaded, dumb ass!
Cache speed (USIIIs' 8 MB are off chip, for example) and price.
Still, you're bloody right.
With Pentium4, Intel decided that only Xeons would have MP support, so that is the diference to a regular Pentium4 (same cache size).
In the good old PentiumII/III, every chip suported MP and the Xeons just had more L2 cache (up to 2 MB).
First, Compaq sold the Alpha because Alphas never sold well enough and was becoming too big of a burden for Compaq.
Second, EPIC is a concept behind ISA design, as CISC, RISC, VLIW (here is where someone will say that EPIC is just Intelspeak for VLIW). If you design an ISA by one, you can't improve it to another. You design another ISA from scratch.
Third, the Alpha suports 64 bit adressing and data manipulation. Actually, unlike most other 64 bit RISC ISAs, Alpha doesn't even have a 32 bit relative.
Sorry, but zSeries aren't based in PowerPC.
And yes, its all about how much power you can buy with a given budget. But isn't everything?