Yea, but try copying your music files back to your computer. The iRiver, at least my model, is seen as nothing more then an external hard drive by windows. I can acess if fully with Windows Explorer. That was my point.
Well, they gave me great customer service, replacing my iRiver iHP-120 (20 gig harddrive) for free after I accdentally fried it by my own fault.
I have a shelf above my desk, and I had a couple of adaptors plugged into a surge protector up there. One was for the iRiver, another was for my Nimih battery recharger. Like an idiot, I plugged the battery charger adaptor plug into the iRiver, and within a few seconds, I smelled burning. Realizing my mistake, I pulled it out, but it was to late. It was cooked. I emailed them and explained what happened, and asked if they had some reconditioned models I could purchase. Instead, they sent me a new one for free after I returned the damaged one.
A mini review: the controls aren't totally intuitive, but it is loaded with useful features, with none of the DRM crap on many other mp3 plays, like my solid state RIO for example. I don't know if the new ones are still like this, though. But it has way more features then an iPod. I wouldn't trade the iRiver for an iPod. The iPod is a crippled player compared to the iRiver.
No, your mistaken about cache architecture and benchmarks. The Windows Task Manager gives the amount of memory the the program running is using, it has nothing at all to do with the cache. I didn't even benchmark it on my 2100 Athlon XP with 256MB cache, that would have been irrelevant.
As you point out, the cache is only used for active processes, an inactive process is in main memory. And tspc181 runs from a command prompt, not an explorer window. When the reviewer ran this benchmark, there would have been no 20MB explorer window in the cache.
By the way, assuming your figures are correct, the 6% of image for 90% hit rate doesn't apply here. An image is linear in memory, and the cache controler knows what it will need next. Chess programs are very random access, and the hit rate would be nowhere near is good, thus having to go to main memory more often. And besides, even a 10% miss rate would be enough to hurt performance, over a program running all in cache.
They could have tested a 1MB cache Athlon 64 against a 512 cache P4, and the Athlon would kick its ass all over the place in benchmarks like this, for example, in this benchmark.
You choose a cache size that runs the application well.
Sure, you pick a cache which will run the program well, but programs which fit totally in cache are rare in the real world. That makes benchmarks like these irrevelvant for real world use.
How do you explain many of the athlons in the past few years that have edged out P4s with higher cache sizes...?
Well, the programs becnhmarked probably didn't fit into the cache of the P4, despite being bigger. If they did fit, but not in the Athlon's, the P4 would probably win. But Athlon's are a less affected by cache misses then the P4 architecure, because of the stalls caused by the P4's long pipeline with a cache miss.
This review is BS. Any running program which would not fit into the Athlon 64's 512KB cache but fit into the Xeon's 1MB cache would have much better performance. Case in point, I downloaded the Windows version of the tspc181 chess program used in the article, and it showed 644KB memory usage in Task Manager. This would explain the much better score of the Xeon, as the Athlon 64 would have to be constantly swapping with main memory while the Xeon ran from the cache. Any test like this will significantly skewer the results. A fairer comparision would be a 1 MB cache Opteron or FX vs the 1MB cache Xeon.
As almost any tech reviewer would have been aware of this, one can only wonder if some money changed hands, as this article seems to be intentionally slanted to make the Xeon look better then the Athlon 64. Also synthetic benchmarks in general tend to be very unreliable, and sometimes worthless, often slanted in design to favor one CPU or another, usually Intels, since they have the most money to throw around.
Slashdot Mirror
Yea, but try copying your music files back to your computer. The iRiver, at least my model, is seen as nothing more then an external hard drive by windows. I can acess if fully with Windows Explorer. That was my point.
Well, they gave me great customer service, replacing my iRiver iHP-120 (20 gig harddrive) for free after I accdentally fried it by my own fault.
I have a shelf above my desk, and I had a couple of adaptors plugged into a surge protector up there. One was for the iRiver, another was for my Nimih battery recharger. Like an idiot, I plugged the battery charger adaptor plug into the iRiver, and within a few seconds, I smelled burning. Realizing my mistake, I pulled it out, but it was to late. It was cooked. I emailed them and explained what happened, and asked if they had some reconditioned models I could purchase. Instead, they sent me a new one for free after I returned the damaged one.
A mini review: the controls aren't totally intuitive, but it is loaded with useful features, with none of the DRM crap on many other mp3 plays, like my solid state RIO for example. I don't know if the new ones are still like this, though. But it has way more features then an iPod. I wouldn't trade the iRiver for an iPod. The iPod is a crippled player compared to the iRiver.
cjsm
Amen, brother! hallelujah!! Dem Lord has um spoken.
No, your mistaken about cache architecture and benchmarks. The Windows Task Manager gives the amount of memory the the program running is using, it has nothing at all to do with the cache. I didn't even benchmark it on my 2100 Athlon XP with 256MB cache, that would have been irrelevant.
As you point out, the cache is only used for active processes, an inactive process is in main memory. And tspc181 runs from a command prompt, not an explorer window. When the reviewer ran this benchmark, there would have been no 20MB explorer window in the cache.
By the way, assuming your figures are correct, the 6% of image for 90% hit rate doesn't apply here. An image is linear in memory, and the cache controler knows what it will need next. Chess programs are very random access, and the hit rate would be nowhere near is good, thus having to go to main memory more often. And besides, even a 10% miss rate would be enough to hurt performance, over a program running all in cache.
They could have tested a 1MB cache Athlon 64 against a 512 cache P4, and the Athlon would kick its ass all over the place in benchmarks like this, for example, in this benchmark.
You choose a cache size that runs the application well.
Sure, you pick a cache which will run the program well, but programs which fit totally in cache are rare in the real world. That makes benchmarks like these irrevelvant for real world use.
How do you explain many of the athlons in the past few years that have edged out P4s with higher cache sizes...?
Well, the programs becnhmarked probably didn't fit into the cache of the P4, despite being bigger. If they did fit, but not in the Athlon's, the P4 would probably win. But Athlon's are a less affected by cache misses then the P4 architecure, because of the stalls caused by the P4's long pipeline with a cache miss.
This review is BS. Any running program which would not fit into the Athlon 64's 512KB cache but fit into the Xeon's 1MB cache would have much better performance. Case in point, I downloaded the Windows version of the tspc181 chess program used in the article, and it showed 644KB memory usage in Task Manager. This would explain the much better score of the Xeon, as the Athlon 64 would have to be constantly swapping with main memory while the Xeon ran from the cache. Any test like this will significantly skewer the results. A fairer comparision would be a 1 MB cache Opteron or FX vs the 1MB cache Xeon.
As almost any tech reviewer would have been aware of this, one can only wonder if some money changed hands, as this article seems to be intentionally slanted to make the Xeon look better then the Athlon 64. Also synthetic benchmarks in general tend to be very unreliable, and sometimes worthless, often slanted in design to favor one CPU or another, usually Intels, since they have the most money to throw around.