Yeah, its probably marketing hype now, but in 5 years, what about 10? Just because we can't do it now doesn't mean that we should stop progress.
No, precisely because we can't do it now, and for the very predictable future, we shouldn't be wasting all that disk space, access and CPU time for a boundary that no production system is likely to ever reach before they get upgraded. That's just practicality.
Seagate apparently sold 18.3 million desktop drives last year. Assuming they're all about 120GB (which is generous of me), that would be about 17.6*10^18 bits. Guess what, that's 2^64 bits. Yes, you would have to buy every single desktop hard drive Seagate shipped in the last year to have the capacity to fill a 64 bit filesystem. And find space for 18 million drives. And a power station to deliver the several hundred megawatts you'd need.
Even at 2 times drive capacity growth per year that's still a ridiculously unattainable figure. In 14 years time you'd only need to buy 1000 drives (which are now 2000TB each). But 14 years is a geological time scale when it comes to computers. You'd have wasted 14 years of CPU time and disk space devoted to those extra 64 bits.
If you still think 64 bits isn't enough, how about 96 bits? It would take 46 years before hard disks were big and cheap enough so you could fill the filesystem by buying 1000 of them. But no, they chose 128 bits because it sounded good.
Getting rid of file/drive size limitations for the foreseeable future?
It would take over 500 years to fill a 64 bit filesystem written at 1GB/sec (and of course 500 years to read it back again). 64 bits is already an impossibly large figure. There's absolutely nothing special or clever whatsoever about doubling the size of your pointers aside from using up more disk space for all the metadata.
64 bits is enough for today's filesystems in much the same way that 256 bit AES is enough for today's encryption - there are far bigger things that will require complete system changes than that so called "limit".
I suspect a better filesystem will come along well before those 500 years are up... I agree with grandparent:
I only ever shut down one of my Linux PCs at home so I can upgrade hardware or fix failed fans. Last shutdown was because my UPS failed. Since I made it a dedicated Linux server 3 years ago, it has never crashed. Ever. It's usually up for about 200 days at a time, at which point I check all the moving parts are still moving, and usually one of them isn't. I don't bother with any kernel upgrades unless they present more than a negligable risk. In the last few years, there haven't been any remote kernel exploits with a risk worth shutting down for. There may be some local exploits, but again I weighed the risk as not being worth the trouble - most were userland apps like openssl which didn't require a reboot.
That's a failure rate of 0%. This isn't just a router PC - it's used for all things including compiling, development and web serving. The trouble is the software is actually more reliable than the hardware.
Thanks for the truly insightful reply. I'm glad to see it moderated as such.
It's a shame it's almost completely wrong. Cornice drives (1.5GB) have most of the controlling logic on the main board rather than in the drive, but all of the 4GB and 5GB one inch drives I've seen (including the Seagate) are plain old ATA interface.
Some of the 4GB Hitachi drives don't work in some devices but that's just due to the ATA command set not being fully implemented by those drives.
An RFID chip doesn't need any contacts, so all the machines involved (passports, readers, etc) last longer, and you only need to hold the chip near a reader, and not line it up and touch it.
If that were true then why is the entire of retail UK switching to the "Chip and Pin" system? It's basically a smart card reader and entry pad. I'm sure they're not incredibly long lived or reliable, but I bet the readers are cheap enough that it's not actually a problem.
In fact, I see the contactless London Underground ticket machines causing more trouble than the magnetic stripe readers. When one magstripe machine breaks, there's plenty of others to go through, or a guard who can quickly read a timestamp and wave people through. When the contactless machine breaks, there's either no other similar gate (because they're expensive), or they both break (probably needs a server link), and then you're screwed because there's no way of working out if your ticket is valid.
Have you seen how long some of these EULAs are? Some are longer than the T&Cs for a credit card. There must surely be some case law against burying unreasonable fine print in massive agreements.
Re:Where do you draw the line?
on
The Spyware Inferno
·
· Score: 2, Insightful
Do you read other contracts you sign, when you sign up for a credit card or buy a plane ticket? Most people don't. This doesn't prevent those contracts being generally enforceable.
An EULA is no different.
Actually, when I "agree" to an EULA, I don't expect to have someone knocking on my door in a few days time to repossess my house. I don't expect that to be followed by woman with very large hands coming through the door saying I married her by clicking on that button.
There's an expectation that people have when they sign a contract. If I'm signing a credit card or mortgage agreement, I expect lots of scary stuff to appear in the fine print. If I'm agreeing to a software license, I do NOT expect that it says "by the way we are going to spy on your every mouse click from now on" somewhere in point 23 of 54. That's underhanded and I would love think that it's somewhat illegal (fraud?), and void because it's not made in good faith. Of course it's not as simple as that otherwise they'd all be in jail by now. I can only dream.
You only have to look at the average amount of spyware installed on a computer (most people have 5+) to realise just how many people don't know what they're signing up for. Caveat empor? No, I think that idea should have died out with the Romans. It's an excuse for otherwise evil acts.
Really? I don't think so.
In order to do anything with it it would also have to pass all the other sanity checks.
What if you find a hole in the sanity checks, or if there aren't any sanity checks at all? It's highly likely there are many programs out there which "trust" data which passes authentication, and don't bother with much in the way of checking. Now this is obviously a short sighted thing to do, but given that SHA-1 and friends are apparently not broken, I wouldn't be surprised.
Personally, I think breaking authentication has far more effect than breaking encryption. Often all you need is a garbage message to be accepted, e.g:
Use an faked md5 to put out rootkitted.tgz? Odds are that any other message with the same hash isn't going to be a valid.tgz.
No, but it will cause the application to fail in an unexpected way: an authenticated.tar.gz which doesn't untar. How about a scarier example: run you an apparently "safe" signed client-side piece of executable code off a web page, except it's actually garbage and it causes your web browser to crash. Or your web server does an automatic update from the vendor only to have its installation corrupted. Or simply inserting garbage but authenticated packets into a network stream thereby causing it to disconnect (or even crash one or both sides).
An interesting thing I notice in the SHA-0 collision is that there aren't that many bits changed - the message looks largely the same. I wouldn't be surprised if you could apply the technique to signed executable code such that a collision is found which would crashes a program in just the right place and just the right way to execute arbitrary code, e.g fork a shell.
If you think you can recreate that gamut with only three base colors, I'd certainly like to hear how.
Er, make a bigger triangle that completely encloses that distinctly non-triangular shape? Still only need 3 phosphors...
Re:Nice, but still shortsighted
on
RGB to become RGBCMY
·
· Score: 3, Interesting
It's not unlike sounds above 20-25kHz in pitch; we don't 'hear' them, but our brain perceives them nonetheless and they are used for stereo imaging of a space.
No, our brain does not perceive sounds much below 20Hz or above 25kHz, and our ears are physically incapable of receiving them in the first place, unless it's loud enough of course (in which case you feel it instead). I have never read any convincing evidence to the contrary in any paper that isn't written by either a vested interest, or by someone who clearly isn't in expert on the subject (usually those go hand in hand).
On the other hand, our eyes do perceive more than RGB. The rods have a slightly different spectrum response than cones, so you need a 4th primary probably centered around its maximum response to get closer to fooling human vision. You can see this effect for example on the leaves of trees at sunrise and sunset. A TV really is just a visual trick - it's emitting just enough of the spectrum to look like the real thing. If it makes your rods and cones respond in the same fashion as the real image would, it doesn't need to do any more. I'm unconvinced that adding 3 more primaries is really necessary.
There is also many other advantages compared to LCDs; Organic light emitting diodes are self-emitting and don't require a backlight, they're brighter and require less power than LCD displays.
The OLED panels I've played with have all been far lower power than an LCD with the backlight turned on, but that's not a fair comparison for some products. For example, MP3 players can get away with turning the backlight off in many cases. An LCD with the backlight turned off takes almost no power. This "idle" state was hard to do with the OLEDs I've used because they were PWM driven, and below a certain brightness they'd get flickery. At the lowest acceptable brightness, they were using about 100 times the power an idle LCD did.
But OLED is still lower power for devices which are useless with the backlight turned off (like cameras, portable TV/DVD players etc). I wouldn't be surprised if next generation panels come down enough in power requirement that the difference isn't important.
No, that's wrong. The truth is that errors in dynamic RAM can be introduced on each refresh.
I think you're mistaken about the cause of DRAM errors. It's not the refresh which causes errors - it's errors in the charge stored in a cell.
The refresh effectively "rounds" the charge back to the nearest bit. If there is enough error in a cell, it will flip states. Without external influences, the chances of an error being of magnitude large enough to flip a bit is not zero, but so small that you could get away with saying "it never happens". But, for example, a stray cosmic ray has a chance of imparting enough charge to change the level beyond a threshold for that bit sense. The refresh then "rounds" the charge and effectively causes the bit to flip. It looks like the refresh is causing the error, but really the information was already lost when the cosmic ray hit, and there's nothing it could have done.
The point is Anandtech seem to have the wrong method, because letting DRAM lie in refresh for extended periods should make absolutely no difference to the chances of an error. It's going to be refreshed every 64ms (for the Micron SDRAM I was interfacing recently) regardless of whether you're accessing it or not.
The fact that Anandtech are also making conclusions about hardware buying based on statistics as worthless as their 0-8 errors over a tiny number of trials is also quite ridiculous, and reassures me that they don't know what they're doing.
You know all those games you have that use MP3 for music? They had to pay a fee to do so. You know all those games you have that use bink video for cutscenes? They had to pay a fee to do so.
Now they don't.
They probably still pay a fee anyway. There's still the nasty matter of those (stupid) MP3 patents, which Thomson and friends reckon covers all lossy audio codecs. A good reason to use a "free" codec despite that is the access to source code, which you usually don't get with a non-free one.
first, the cache is not broken. this is a common design limitation of embedded processors. running code or accessing data from external ram can be VERY slow (1 cycle delay is pretty good).
It is very much a broken design, and it certainly isn't common. Even the ARM720 (which they could have used) is 0 wait state. In fact, this is the only ARM based system I've come across which isn't 0 wait state, and I've come across a lot of them. Notably none of the other PortalPlayer CPUs have this problem.
having said that... adding a complex codec into such a system such as the ipod firmware is a major pain in the ass. they may want to enable vorbis support, but it is a large amount of work, and probably hard for apple engineers to justify. if someone could find a good excuse for apple marketing to justify it, i'm sure engineering could figure it out.
Yes - the developer still has to dick around with micro-optimisations to even get it working because it's not presenting sdram/flash at near the speed of SRAM. If it were a full speed cache like everyone else makes, then moving parts to SRAM would just be a minor battery and performance improvement. As it stands, it's probably too large a task for them to bother.
Vorbis runs easily real time on most ARM720 based CPUs out of SDRAM, yet it's only 80% real time on PP5002. That's what I call broken.
The iPod doesn't rely on its CPU to do the decoding for its mpeg formats. The bulk of that is done by a special coprocessor. Whether this is to cut power use or because the slower clock and coprocessor are cheaper than a faster general purpose CPU, I don't know.
It's just another ARM7TDMI core. There's 2 in it.
Memory isn't a problem. The full of the iPod's memory is directly addressable, and there are even projects (including iPod Linux) which do Ogg (vorbis, really) decoding, however only at low bitrates.
Memory is a problem. I refer you to the article. Also note that the current state of "open source" Vorbis playback on iPod is non-real time. Still, I think there's ample CPU to do Vorbis playback despite the issues.
They say it handles two bits at a time. Doesn't that indicate that's it's a digital computer, not analog?
That's exactly my point - it's a digital computer but I say you could treat the circuits and analog and simulate the gate signals themselves, and still be real time. And if that's true, then the task it's performing must be computable in many orders of magnitude faster than real time on a modern PC.
Next people will be claiming that 1,000,000 people each using an abacus is faster than a modern PC because it's "specific purpose" and "parallel". Hell, you could probably model the physics of each bead as it moves and still do it real time on a PC...
Add to that, the writers "modern PC" is a modern in 1996. Which was what? a 486? So while he may have been correct at the time the various parts of the project was underway, it's not true now.
No, I think the writers still didn't quite understand quite how far off they were even if we're talking about 1996. It's not like we're talking about massive DSP operations here - it's just handling text, albeit lots of characters at once. This makes the comparisons some people are making to the difference between CPU and GPU nonsense, because it's not exactly a hard job for a general purpose machine like rendering inherently is.
I'm sure a 486dx25 would be far faster if properly coded. Maybe he used GWBASIC.
This is custom hardware designed for the job. MHz and GHz don't come into it. If you don't believe me, consider why the processor on so many graphics cards is slower than the CPU in the machine, yet without it, the graphics would grind to a halt.
(repeat subject line here) A modern PC is 2-3GHz, can compute 3 general purpose 32 bit operations per cycle, and has a gate count of about 50 million. Colossus is sub-1MHz, computes "100 bits per cycle" (hard to tell from article text) and has a gate count of 1,000. It also has a tape input which probably amounts to about 25KB/sec (so I am told).
No amount of specific purpose machinary is going to catch up with that order of magnitude difference. Please, I can easily imagine simulating the analog signals going through the 1,000 or so valves in real time on a modern PC, let alone emulating it digitally.
Remarkably, the use of parallel processing (five tape channels) and short gate delay time (1.2 microseconds) allows the Colossus to match the speed of a modern PC
Er, this is an obviously ridiculous statement. A modern PC is such an order of magnitude faster that it could probably run equations simulating the circuit behaviour itself and still run real time. Compare 1,000 values at 1MHz (which it probably isn't anywhere near in reality), and a slow tape data input (even with 5 of them), to 10 million transistors at 3GHz.
Funny thing is so many people seem to think there's nothing odd about it.
Your pentium 166MMX is actually faster than a 400Mhz Xscale processor. Ultra low power comes with a price.
Actually, I'd hazard to say that the 400MHz XScale is faster than a Pentium 166MMX so long as MMX or floating point doesn't come into the equation. I doubt emulating a SNES involves any kind of floating point or MMX, so I'd say the 400MHz XScale should do the job of emulation faster.
Plus it's far easier to generate code for ARM than x86, if that's the route you take for your emulator.
I hate to be pessimistic, but full speed SNES with sound support probably won't happen on the GBA anytime soon, even with overclocking. My PDA, which has a 400MHz Intel Xscale processor overclocked to 472MHz can only run maybe 5 or 6 SNES games with low quality sound at full speed, everything else skips. Without sound, almost every game will play full speed.
That sounds like a really slow emulator. It's probably an interpreting one, which means you can expect it to be something like a 100-1000 times slower than the emulated system clock-for-clock. A good example is Bochs, which is pretty damn slow, but the interpreted approach allows it to run on many systems with little porting.
What you really need for a fast emulator is dynamic translation - rewrite snippets of emulated instructions into native ones, and run that instead. You can get close to a 1:1 ratio of native:emulated clocks, which means in your case you'd have a 472MHz XScale emulating as if it were a 472MHZ SNES.
There's plenty of examples of dynamic translators about. Transmeta's processors all run a dynamic translator from x86 to some freaky native instruction set (they call it "code morphing"). Java's JIT (just-in-time) is an example of a very similar thing - it translates byte code to native instructions on the fly, but doesn't have to worry about maintaining the virtual system's state, because Java doesn't have the concept of one.
So yes, it should be possible.
It's based on the disaster that is UWB
on
USB Going Wireless
·
· Score: 2, Informative
Wireless USB is based on UWB (ultra wideband), which is a horrific modulation scheme that interferes with absolutely everything. It's weird that it's even being promoted by the OFDM alliance, because they're supposed to be promoting, well, OFDM (orthogonal frequency domain modulation). OFDM is a "nice" modulation scheme because it contains itself within a frequency band, and uses the bandwidth extremely efficiently. UWB on the other hand plonks itself over the entire spectrum (several GHz) and when you consider that, it uses it extremely inefficiently. Don't believe the hype - despite the low radiated power per Hz, it still interferes with equipment.
Basically UWB is a nasty piece of work that's being rammed through with corporate pressure and by lobby groups set up by manufacturers. Now that Intel has signed on and indicated it intends to make it ubiquitous, we're pretty much doomed. It seems to have passed certification in the US, but with any luck it won't pass in Europe. It'll hopefully go the way of broadband over powerlines - everyone finally figures out it's just a bunch of snake oil salesmen pedalling faulty goods.
Dude, RIo and Apple both get their device platform from PortalPlayer. There isn't any arguing that point. I don't see how either can be a rip off of the other when they both paid for the concept and design of their internals.
I take exception to both your posts because it's pretty clear neither of you know what you're talking about. You're both mixing up the Nitrus and Karma for a start. The Rio Karma uses a PortalPlayer CPU, but that's as far as PortalPlayer's contribution goes because none of their software is used, and they had no part in hardware design. There is absolutely nothing shared in the design of the Karma and the iPod except the CPU existing on a board.
There is even less (none in fact) design shared between them and the Rio Nitrus because it uses a Sigmatel 3410 CPU. It's far less capable than you're making it out to be mostly because the CPU is far less powerful. But using the 3410 is why it's at 16 hours of battery and not 8.
As for time scale, out of the iPod, Nitrus, Karma and Mini: the iPod was first, then the Rio Nitrus, Karma, and finally (much later) the iPod Mini. The iPod Mini isn't first or original by any stretch of the imagination, though Apple would have you think otherwise. See the keynote speech where Jobs somehow ignores the existence of many 1.5GB MP3 players and compares the iPod Mini to a $250 (hard to find them that expensive) Rio 256MB flash player. He'd earlier announced in that keynote how they'd just invented midi synthesis, sequencing, and moving through photo collections quickly, so I guess that strategy nothing new to them.
Slashdot Mirror
No, precisely because we can't do it now, and for the very predictable future, we shouldn't be wasting all that disk space, access and CPU time for a boundary that no production system is likely to ever reach before they get upgraded. That's just practicality.
Seagate apparently sold 18.3 million desktop drives last year. Assuming they're all about 120GB (which is generous of me), that would be about 17.6*10^18 bits. Guess what, that's 2^64 bits. Yes, you would have to buy every single desktop hard drive Seagate shipped in the last year to have the capacity to fill a 64 bit filesystem. And find space for 18 million drives. And a power station to deliver the several hundred megawatts you'd need.
Even at 2 times drive capacity growth per year that's still a ridiculously unattainable figure. In 14 years time you'd only need to buy 1000 drives (which are now 2000TB each). But 14 years is a geological time scale when it comes to computers. You'd have wasted 14 years of CPU time and disk space devoted to those extra 64 bits.
If you still think 64 bits isn't enough, how about 96 bits? It would take 46 years before hard disks were big and cheap enough so you could fill the filesystem by buying 1000 of them. But no, they chose 128 bits because it sounded good.
It would take over 500 years to fill a 64 bit filesystem written at 1GB/sec (and of course 500 years to read it back again). 64 bits is already an impossibly large figure. There's absolutely nothing special or clever whatsoever about doubling the size of your pointers aside from using up more disk space for all the metadata.
64 bits is enough for today's filesystems in much the same way that 256 bit AES is enough for today's encryption - there are far bigger things that will require complete system changes than that so called "limit". I suspect a better filesystem will come along well before those 500 years are up... I agree with grandparent:
-1, Marketing Hype.
That's a failure rate of 0%. This isn't just a router PC - it's used for all things including compiling, development and web serving. The trouble is the software is actually more reliable than the hardware.
It's a shame it's almost completely wrong. Cornice drives (1.5GB) have most of the controlling logic on the main board rather than in the drive, but all of the 4GB and 5GB one inch drives I've seen (including the Seagate) are plain old ATA interface.
Some of the 4GB Hitachi drives don't work in some devices but that's just due to the ATA command set not being fully implemented by those drives.
If that were true then why is the entire of retail UK switching to the "Chip and Pin" system? It's basically a smart card reader and entry pad. I'm sure they're not incredibly long lived or reliable, but I bet the readers are cheap enough that it's not actually a problem.
In fact, I see the contactless London Underground ticket machines causing more trouble than the magnetic stripe readers. When one magstripe machine breaks, there's plenty of others to go through, or a guard who can quickly read a timestamp and wave people through. When the contactless machine breaks, there's either no other similar gate (because they're expensive), or they both break (probably needs a server link), and then you're screwed because there's no way of working out if your ticket is valid.
Have you seen how long some of these EULAs are? Some are longer than the T&Cs for a credit card. There must surely be some case law against burying unreasonable fine print in massive agreements.
An EULA is no different.
Actually, when I "agree" to an EULA, I don't expect to have someone knocking on my door in a few days time to repossess my house. I don't expect that to be followed by woman with very large hands coming through the door saying I married her by clicking on that button.
There's an expectation that people have when they sign a contract. If I'm signing a credit card or mortgage agreement, I expect lots of scary stuff to appear in the fine print. If I'm agreeing to a software license, I do NOT expect that it says "by the way we are going to spy on your every mouse click from now on" somewhere in point 23 of 54. That's underhanded and I would love think that it's somewhat illegal (fraud?), and void because it's not made in good faith. Of course it's not as simple as that otherwise they'd all be in jail by now. I can only dream.
You only have to look at the average amount of spyware installed on a computer (most people have 5+) to realise just how many people don't know what they're signing up for. Caveat empor? No, I think that idea should have died out with the Romans. It's an excuse for otherwise evil acts.
What if you find a hole in the sanity checks, or if there aren't any sanity checks at all? It's highly likely there are many programs out there which "trust" data which passes authentication, and don't bother with much in the way of checking. Now this is obviously a short sighted thing to do, but given that SHA-1 and friends are apparently not broken, I wouldn't be surprised.
Personally, I think breaking authentication has far more effect than breaking encryption. Often all you need is a garbage message to be accepted, e.g:
Use an faked md5 to put out rootkitted.tgz? Odds are that any other message with the same hash isn't going to be a valid.tgz.
No, but it will cause the application to fail in an unexpected way: an authenticated .tar.gz which doesn't untar. How about a scarier example: run you an apparently "safe" signed client-side piece of executable code off a web page, except it's actually garbage and it causes your web browser to crash. Or your web server does an automatic update from the vendor only to have its installation corrupted. Or simply inserting garbage but authenticated packets into a network stream thereby causing it to disconnect (or even crash one or both sides).
An interesting thing I notice in the SHA-0 collision is that there aren't that many bits changed - the message looks largely the same. I wouldn't be surprised if you could apply the technique to signed executable code such that a collision is found which would crashes a program in just the right place and just the right way to execute arbitrary code, e.g fork a shell.
Read a book on DSP or audio perception. Please.
Er, make a bigger triangle that completely encloses that distinctly non-triangular shape? Still only need 3 phosphors...
No, our brain does not perceive sounds much below 20Hz or above 25kHz, and our ears are physically incapable of receiving them in the first place, unless it's loud enough of course (in which case you feel it instead). I have never read any convincing evidence to the contrary in any paper that isn't written by either a vested interest, or by someone who clearly isn't in expert on the subject (usually those go hand in hand).
On the other hand, our eyes do perceive more than RGB. The rods have a slightly different spectrum response than cones, so you need a 4th primary probably centered around its maximum response to get closer to fooling human vision. You can see this effect for example on the leaves of trees at sunrise and sunset. A TV really is just a visual trick - it's emitting just enough of the spectrum to look like the real thing. If it makes your rods and cones respond in the same fashion as the real image would, it doesn't need to do any more. I'm unconvinced that adding 3 more primaries is really necessary.
The OLED panels I've played with have all been far lower power than an LCD with the backlight turned on, but that's not a fair comparison for some products. For example, MP3 players can get away with turning the backlight off in many cases. An LCD with the backlight turned off takes almost no power. This "idle" state was hard to do with the OLEDs I've used because they were PWM driven, and below a certain brightness they'd get flickery. At the lowest acceptable brightness, they were using about 100 times the power an idle LCD did.
But OLED is still lower power for devices which are useless with the backlight turned off (like cameras, portable TV/DVD players etc). I wouldn't be surprised if next generation panels come down enough in power requirement that the difference isn't important.
I think you're mistaken about the cause of DRAM errors. It's not the refresh which causes errors - it's errors in the charge stored in a cell.
The refresh effectively "rounds" the charge back to the nearest bit. If there is enough error in a cell, it will flip states. Without external influences, the chances of an error being of magnitude large enough to flip a bit is not zero, but so small that you could get away with saying "it never happens". But, for example, a stray cosmic ray has a chance of imparting enough charge to change the level beyond a threshold for that bit sense. The refresh then "rounds" the charge and effectively causes the bit to flip. It looks like the refresh is causing the error, but really the information was already lost when the cosmic ray hit, and there's nothing it could have done.
The point is Anandtech seem to have the wrong method, because letting DRAM lie in refresh for extended periods should make absolutely no difference to the chances of an error. It's going to be refreshed every 64ms (for the Micron SDRAM I was interfacing recently) regardless of whether you're accessing it or not.
The fact that Anandtech are also making conclusions about hardware buying based on statistics as worthless as their 0-8 errors over a tiny number of trials is also quite ridiculous, and reassures me that they don't know what they're doing.
Now they don't.
They probably still pay a fee anyway. There's still the nasty matter of those (stupid) MP3 patents, which Thomson and friends reckon covers all lossy audio codecs. A good reason to use a "free" codec despite that is the access to source code, which you usually don't get with a non-free one.
It is very much a broken design, and it certainly isn't common. Even the ARM720 (which they could have used) is 0 wait state. In fact, this is the only ARM based system I've come across which isn't 0 wait state, and I've come across a lot of them. Notably none of the other PortalPlayer CPUs have this problem.
having said that... adding a complex codec into such a system such as the ipod firmware is a major pain in the ass. they may want to enable vorbis support, but it is a large amount of work, and probably hard for apple engineers to justify. if someone could find a good excuse for apple marketing to justify it, i'm sure engineering could figure it out.
Yes - the developer still has to dick around with micro-optimisations to even get it working because it's not presenting sdram/flash at near the speed of SRAM. If it were a full speed cache like everyone else makes, then moving parts to SRAM would just be a minor battery and performance improvement. As it stands, it's probably too large a task for them to bother.
Vorbis runs easily real time on most ARM720 based CPUs out of SDRAM, yet it's only 80% real time on PP5002. That's what I call broken.
It's just another ARM7TDMI core. There's 2 in it.
Memory isn't a problem. The full of the iPod's memory is directly addressable, and there are even projects (including iPod Linux) which do Ogg (vorbis, really) decoding, however only at low bitrates.
Memory is a problem. I refer you to the article. Also note that the current state of "open source" Vorbis playback on iPod is non-real time. Still, I think there's ample CPU to do Vorbis playback despite the issues.
A few thousand gates total is massive parallism? You should see what you can implement in FPGAs which have that capacity - not a lot!
That's exactly my point - it's a digital computer but I say you could treat the circuits and analog and simulate the gate signals themselves, and still be real time. And if that's true, then the task it's performing must be computable in many orders of magnitude faster than real time on a modern PC.
Next people will be claiming that 1,000,000 people each using an abacus is faster than a modern PC because it's "specific purpose" and "parallel". Hell, you could probably model the physics of each bead as it moves and still do it real time on a PC...
No, I think the writers still didn't quite understand quite how far off they were even if we're talking about 1996. It's not like we're talking about massive DSP operations here - it's just handling text, albeit lots of characters at once. This makes the comparisons some people are making to the difference between CPU and GPU nonsense, because it's not exactly a hard job for a general purpose machine like rendering inherently is.
I'm sure a 486dx25 would be far faster if properly coded. Maybe he used GWBASIC.
(repeat subject line here) A modern PC is 2-3GHz, can compute 3 general purpose 32 bit operations per cycle, and has a gate count of about 50 million. Colossus is sub-1MHz, computes "100 bits per cycle" (hard to tell from article text) and has a gate count of 1,000. It also has a tape input which probably amounts to about 25KB/sec (so I am told).
No amount of specific purpose machinary is going to catch up with that order of magnitude difference. Please, I can easily imagine simulating the analog signals going through the 1,000 or so valves in real time on a modern PC, let alone emulating it digitally.
Er, this is an obviously ridiculous statement. A modern PC is such an order of magnitude faster that it could probably run equations simulating the circuit behaviour itself and still run real time. Compare 1,000 values at 1MHz (which it probably isn't anywhere near in reality), and a slow tape data input (even with 5 of them), to 10 million transistors at 3GHz.
Funny thing is so many people seem to think there's nothing odd about it.
Actually, I'd hazard to say that the 400MHz XScale is faster than a Pentium 166MMX so long as MMX or floating point doesn't come into the equation. I doubt emulating a SNES involves any kind of floating point or MMX, so I'd say the 400MHz XScale should do the job of emulation faster.
Plus it's far easier to generate code for ARM than x86, if that's the route you take for your emulator.
That sounds like a really slow emulator. It's probably an interpreting one, which means you can expect it to be something like a 100-1000 times slower than the emulated system clock-for-clock. A good example is Bochs, which is pretty damn slow, but the interpreted approach allows it to run on many systems with little porting.
What you really need for a fast emulator is dynamic translation - rewrite snippets of emulated instructions into native ones, and run that instead. You can get close to a 1:1 ratio of native:emulated clocks, which means in your case you'd have a 472MHz XScale emulating as if it were a 472MHZ SNES.
There's plenty of examples of dynamic translators about. Transmeta's processors all run a dynamic translator from x86 to some freaky native instruction set (they call it "code morphing"). Java's JIT (just-in-time) is an example of a very similar thing - it translates byte code to native instructions on the fly, but doesn't have to worry about maintaining the virtual system's state, because Java doesn't have the concept of one.
So yes, it should be possible.
Basically UWB is a nasty piece of work that's being rammed through with corporate pressure and by lobby groups set up by manufacturers. Now that Intel has signed on and indicated it intends to make it ubiquitous, we're pretty much doomed. It seems to have passed certification in the US, but with any luck it won't pass in Europe. It'll hopefully go the way of broadband over powerlines - everyone finally figures out it's just a bunch of snake oil salesmen pedalling faulty goods.
I take exception to both your posts because it's pretty clear neither of you know what you're talking about. You're both mixing up the Nitrus and Karma for a start. The Rio Karma uses a PortalPlayer CPU, but that's as far as PortalPlayer's contribution goes because none of their software is used, and they had no part in hardware design. There is absolutely nothing shared in the design of the Karma and the iPod except the CPU existing on a board.
There is even less (none in fact) design shared between them and the Rio Nitrus because it uses a Sigmatel 3410 CPU. It's far less capable than you're making it out to be mostly because the CPU is far less powerful. But using the 3410 is why it's at 16 hours of battery and not 8.
As for time scale, out of the iPod, Nitrus, Karma and Mini: the iPod was first, then the Rio Nitrus, Karma, and finally (much later) the iPod Mini. The iPod Mini isn't first or original by any stretch of the imagination, though Apple would have you think otherwise. See the keynote speech where Jobs somehow ignores the existence of many 1.5GB MP3 players and compares the iPod Mini to a $250 (hard to find them that expensive) Rio 256MB flash player. He'd earlier announced in that keynote how they'd just invented midi synthesis, sequencing, and moving through photo collections quickly, so I guess that strategy nothing new to them.