For one, they have an audio/video sync code that works fine with the crappy soundcard drivers that linux has (see mplayer article on freshmeat).
Trust me, once you watch starwars 2 on mplayer and the flying cars (Jedi council window) are like Queen Elizabeth's guards (i.e. they don't go smoothly at all) you switch to xine immediately. (yeah, I know -autosync. Hasn't improved much on my system). Don't get me wrong, mplayer is great - just not on my system. And I'm not going to pay 34$ to get commercial oss drivers.
libavcodec is actually just as good as divx5, and certainly better than xvid. While it's true that it produces stuff that's compatible with divx decoders (theoretically all MPEG4s should be compatible with each other, but that's only the theory), it is certainly not subsumed by divx5. It also has many of the codec features of divx5 pro - e.g. B-frames, Trellis quantizer (which improves quality / reduces bitrate big time(tm))
The tests are pretty much showing that an Athlon-64 does not outperform a 32 bit Athlon when running 32 bit apps.
But here's another way to look at it - Itanium also has an x86 layer, but because it's really just an emulation, its performance sucks.
So I view this as a huge success. Why ? Because an Athlon-64 will be able to run "legacy" 32 apps at the same speed, while 64 apps will run faster.
You'd probably wonder why this is the case. Well, IMNSHO it's not because of the wider registers/ALUs, etc, but because of other improvements to the Instruction Set Architecture, like the 8 extra registers (16 total). Because you only have 8 registers on a regular x86, compilers can register-allocate very little. Adding 8 more registers means that you can keep more stuff in the register file, and you don't have to go to the stack (data cache) every single time.
My understanding is that the biggest bandwidth hogs are the peer-to-peer networks. The trafic on these network is mostly made of heavily-compressed movie files and mp3s, and lossless compression isn't likely to do much for these.
Caching could clearly work (wouldn't it be great if your ISP had gnutella nodes ?) but this raises some important legal issues - these days ISPs don't have much legal trouble for transparently allowing users to download pirated content, but as soon as they cache p2p trafic Hillary's with her army of lawyers is gonna be after them
The answer can be as simply as that - the x86-64 has
16 general-purpose registers instead of 8.
So you can actually do register allocation with this architecture (as opposed to vanilla x86 where you pretty much have to keep everything in memory), and you'll already see some performance gain, as its much cheaper to keep a variable in a register than in memory.
The processor is not RISC, it's VLIW. A meta-instruction is made of 8 smaller, 32-bit ones. The key characteristic of VLIW is that these 8 instructions are explicitly parallel; the processor knows, when processing this instruction, that it can execute all these 8 subinstructions in parallel (now a sub-instruction is RISC-like, I grant you that). The difficulty is finding this level of parallelism in existing x86 programs (this is the job of the software code morpher)
Furthermore, only the meta-instruction is 256 bits, not the registers, etc (which are only 32 bits). That'd be way too wasteful. Most apps don't need more than 32 bits, anyway. Only big servers need more than 4 Gigs; this processor is targeted to mobile applications, therefore I'm pretty sure it can only address 4 G of RAM.
Re:32 compatibility mode vs. true 64 bit apps...
on
AMD Opteron Due In April
·
· Score: 4, Interesting
The width of the machine is not the number of threads it's able to run at a given time (SMT like P4), but the number of instructions you can execute in a cycle (in a parallel fashion, of course). The difference between x86 and Itanium is that on Itanium the instructions are "explicitly parallel", i.e. the compiler bundles instructions together and the processor knows it can execute them in parallel, while on x86 the processor is smarter and determines itself which micro-ops (actually it's rops for AMD) it can execute in parallel.
You're very likely going to see speedups on 32 bit code, simply because Opteron is twice as wide as P4 (and this has nothing to do with the size of the operands, which probably is not going to matter as much).
As far as the 64 apps are concerned - Linux already runs on it.
I'm pretty sure this is the physical address space and not the virtual one (which should be 2^64). So the external bus of the processor can "only" address 1TB (i.e. 40 address bits)
The United States have been preaching "economical
openness" for more than 2 decades now I think.
"Do you want US aid? Open your economy...".
Quite a few times this worked against the country
implementing the measure, but most of the times it
worked well for the US (as its very competitive
merchandise flooded those markets). There are some
areas in which openness works against the US - like
CS jobs.
I believe that more and more jobs will be exported
to India, but probably not China, because of the
language barrier.
Now I'm all for openness myself - I just believe
that it *has* to be applied both ways.
(This comment mainly refers to the Java bytecode; AFAIK though most of it is true about CLR, too)
The bytecode, if executed "as is", can be *extremely* inefficient, as the virtual machine is a stack one.
Modern JITs take a completely different approach to achieve decent performance - they reconstruct the control flow/data flow from the bytecode and then "recompile" (with heavy optimizations, that you can't really do in hardware) into native code. Translating bytecode to instructions directly (or naively) gets you very little benefit over interpretation. The problem is that you can't do more than naive translation in hardware in an efficient manner
The bytecode is very high level - so high level that you can reconstruct the sourcecode from it (modulo local var names). Hardware likes simple stuff, and as a consequence it's not good at executing it efficiently
In my not-so-humble opinion, a computer is something that's Turing-complete, i.e. it is computationally equivalent to a Turing machine (or von-Neumann automaton or lambda-calculus or...).
Until you can program such a system to solve any
problem a normal computer can (modulo some size, as no real computer has infinite storage), you can't call it a computer.
I do think it's a great achievement, but I don't like the "marketing paint".
China's gross national income per capita (GNIPC) in the year 2000 was ~700$ (see worldbank) - the average chinese made less than 2$/day.
Poverty is the real source of piracy -
furthermore bussiness strategies that work for people making 2$ a day will very likely not work for people making a 100$ a day and viceversa.
There's no real Linux gaming market (the sales of all Linux games barely add up to the sales of a medium Windoze game). Granted, they're trying to do it differently - attract people to Linux with a completely original game.
The gaming market is the most ferocious software market; the failure rates are between 90% and 95%. I find it difficult to believe that 8 people, working 10-20h per week (after all, they need a real job to pay the rent) can compete with the big guys (because of the wonderful dualboot, they'd be competing with the Windoze games)
As a person who purchased quite a few Linux titles, I wish them good luck nevertheless.
You got me wrong - there are seasons on Mars. The problem is that Mars' rotation & tilt are erratic, and that's due to the absence of a regulator (large satelite). In Earth's terms, that would translate to 6 month of winter in one year and one month in another. BTW, when the tilt of Earth's rotation axis changed by a single degree the impact on weather was huge.
I think that highest problem with Mars' terraforming is not of "biochemical" nature but astrophysical. Mars doesn't have a huge satelite like Earth (relatively speaking, of course - Moon is one sixth of Earth's mass) to regulate its rotation. As a consequence Mars doesn't really have stable seasons (well, Earth doesn't seem to have them either, but for a completely different reason:)) and I believe that this is a huge impediment in any kind of a terraforming effort
Well, the human eye doesn't need more than 30 fps (combined with the sampling rate of the monitor - 60 fps). However, the performance of grafik cards has peaks and valleys (pretty much like the performance of the processor). So I think it's very important to report min-FP ratings besides the avg ones. An average of 30 will very likely mean that it gets to 20fps from time to time; an average of a 100 probably means that you never get under 40.
I'm just wondering why they don't start by uniting the sound systems... having two interfaces is not so bad, as long as they interoperate reasonably well. And by that I mean the very basics, like clipboard and sound. Uniting the sound API shouldn't be that hard, and moreover should reduce the nuissance of killing/restarting artsd everytime I want to use sound within a gnome application .
Make software, not war!
on
Corporate KDE
·
· Score: 5, Insightful
Good to know that there are responsible governments who make a lot better use of their taxpayer's money.
They're hardly in any competition for marketshare. Apple competes with Windoze and so does Linux, but from 2 opposite extremes. It's very much like Jerry and the dog allying against Tom:)
Why did they wait so much to release it as open source? I'm just wondering if their initial plan wasn't to change from Freeware to Commercial at some point. They've most likely realised that they won't be able to make money out of it, and decided to opensource it so it doesn't die (a site that wasn't updated for almost a year can be considered a near-death experience). Anyway, they did do a great job and I'm glad that the opensource gaming is enriched with a free-as-in-beer space shooter.
Slashdot Mirror
Trust me, once you watch starwars 2 on mplayer and the flying cars (Jedi council window) are like Queen Elizabeth's guards (i.e. they don't go smoothly at all) you switch to xine immediately. (yeah, I know -autosync. Hasn't improved much on my system). Don't get me wrong, mplayer is great - just not on my system. And I'm not going to pay 34$ to get commercial oss drivers.
libavcodec is actually just as good as divx5, and certainly better than xvid. While it's true that it produces stuff that's compatible with divx decoders (theoretically all MPEG4s should be compatible with each other, but that's only the theory), it is certainly not subsumed by divx5. It also has many of the codec features of divx5 pro - e.g. B-frames, Trellis quantizer (which improves quality / reduces bitrate big time(tm))
But here's another way to look at it - Itanium also has an x86 layer, but because it's really just an emulation, its performance sucks.
So I view this as a huge success. Why ? Because an Athlon-64 will be able to run "legacy" 32 apps at the same speed, while 64 apps will run faster.
You'd probably wonder why this is the case. Well, IMNSHO it's not because of the wider registers/ALUs, etc, but because of other improvements to the Instruction Set Architecture, like the 8 extra registers (16 total). Because you only have 8 registers on a regular x86, compilers can register-allocate very little. Adding 8 more registers means that you can keep more stuff in the register file, and you don't have to go to the stack (data cache) every single time.
Try making a similar joke about fascism.
Caching could clearly work (wouldn't it be great if your ISP had gnutella nodes ?) but this raises some important legal issues - these days ISPs don't have much legal trouble for transparently allowing users to download pirated content, but as soon as they cache p2p trafic Hillary's with her army of lawyers is gonna be after them
So you can actually do register allocation with this architecture (as opposed to vanilla x86 where you pretty much have to keep everything in memory), and you'll already see some performance gain, as its much cheaper to keep a variable in a register than in memory.
As a (relatively proud) owner of the 5500, I can tell you for sure that there's a lot of room for improvements.
The processor is not RISC, it's VLIW. A meta-instruction is made of 8 smaller, 32-bit ones. The key characteristic of VLIW is that these 8 instructions are explicitly parallel; the processor knows, when processing this instruction, that it can execute all these 8 subinstructions in parallel (now a sub-instruction is RISC-like, I grant you that). The difficulty is finding this level of parallelism in existing x86 programs (this is the job of the software code morpher)
Furthermore, only the meta-instruction is 256 bits, not the registers, etc (which are only 32 bits). That'd be way too wasteful. Most apps don't need more than 32 bits, anyway. Only big servers need more than 4 Gigs; this processor is targeted to mobile applications, therefore I'm pretty sure it can only address 4 G of RAM.
The width of the machine is not the number of threads it's able to run at a given time (SMT like P4), but the number of instructions you can execute in a cycle (in a parallel fashion, of course). The difference between x86 and Itanium is that on Itanium the instructions are "explicitly parallel", i.e. the compiler bundles instructions together and the processor knows it can execute them in parallel, while on x86 the processor is smarter and determines itself which
micro-ops (actually it's rops for AMD) it can execute in parallel.
You're very likely going to see speedups on 32 bit code, simply because Opteron is twice as wide as P4 (and this has nothing to do with the size of the operands, which probably is not going to matter as much).
As far as the 64 apps are concerned - Linux already runs on it.
I'm pretty sure this is the physical address space and not the virtual one (which should be 2^64). So the external bus of the processor can "only" address 1TB (i.e. 40 address bits)
Right, but their higher education system is all in english.
I believe that more and more jobs will be exported to India, but probably not China, because of the language barrier.
Now I'm all for openness myself - I just believe that it *has* to be applied both ways.
The bytecode, if executed "as is", can be *extremely* inefficient, as the virtual machine is a stack one.
Modern JITs take a completely different approach to achieve decent performance - they reconstruct the control flow/data flow from the bytecode and then "recompile" (with heavy optimizations, that you can't really do in hardware) into native code. Translating bytecode to instructions directly (or naively) gets you very little benefit over interpretation. The problem is that you can't do more than naive translation in hardware in an efficient manner
The bytecode is very high level - so high level that you can reconstruct the sourcecode from it (modulo local var names). Hardware likes simple stuff, and as a consequence it's not good at executing it efficiently
Until you can program such a system to solve any problem a normal computer can (modulo some size, as no real computer has infinite storage), you can't call it a computer.
I do think it's a great achievement, but I don't like the "marketing paint".
Poverty is the real source of piracy - furthermore bussiness strategies that work for people making 2$ a day will very likely not work for people making a 100$ a day and viceversa.
There's no real Linux gaming market (the sales of all Linux games barely add up to the sales of a medium Windoze game). Granted, they're trying to do it differently - attract people to Linux with a completely original game.
The gaming market is the most ferocious software market; the failure rates are between 90% and 95%. I find it difficult to believe that 8 people, working 10-20h per week (after all, they need a real job to pay the rent) can compete with the big guys (because of the wonderful dualboot, they'd be competing with the Windoze games)
As a person who purchased quite a few Linux titles, I wish them good luck nevertheless.
You got me wrong - there are seasons on Mars. The problem is that Mars' rotation & tilt are erratic, and that's due to the absence of a regulator (large satelite). In Earth's terms, that would translate to 6 month of winter in one year and one month in another. BTW, when the tilt of Earth's rotation axis changed by a single degree the impact on weather was huge.
I think that highest problem with Mars' terraforming is not of "biochemical" nature but astrophysical. Mars doesn't have a huge satelite like Earth (relatively speaking, of course - Moon is one sixth of Earth's mass) to regulate its rotation. As a consequence Mars doesn't really have stable seasons (well, Earth doesn't seem to have them either, but for a completely different reason :)) and I believe that this is a huge impediment in any kind of a terraforming effort
Well, the human eye doesn't need more than 30 fps (combined with the sampling rate of the monitor - 60 fps). However, the performance of grafik cards has peaks and valleys (pretty much like the performance of the processor). So I think it's very important to report min-FP ratings besides the avg ones. An average of 30 will very likely mean that it gets to 20fps from time to time; an average of a 100 probably means that you never get under 40.
Compared to the investment IBM made (they claim ~1B$), or even Redhat (50M$), this most likely won't have a real impact (except for PR, of course)
I'm just wondering why they don't start by uniting the sound systems ... having two interfaces is not so bad, as long as they interoperate reasonably well. And by that I mean the very basics, like clipboard and sound. Uniting the sound API shouldn't be that hard, and moreover should reduce the nuissance of killing/restarting artsd everytime I want to use sound within a gnome application .
Good to know that there are responsible governments who make a lot better use of their taxpayer's money.
Of course, that might change in the future
Why did they wait so much to release it as open source? I'm just wondering if their initial plan wasn't to change from Freeware to Commercial at some point. They've most likely realised that they won't be able to make money out of it, and decided to opensource it so it doesn't die (a site that wasn't updated for almost a year can be considered a near-death experience). Anyway, they did do a great job and I'm glad that the opensource gaming is enriched with a free-as-in-beer space shooter.
If you don't believe me, check how much 10 seconds of superbowl publicity cost.