Revin Kevin
22/12/06 3:54PM |
Could this module be used by the DVD playing software to get it up to speed? |
ccw (+1.0)
22/12/06 4:59PM |
where do we put this driver?
nice to see the iyonix getting faster |
diomus (+0.9)
22/12/06 5:11PM |
Apologies if it's not entirely clear from the article, but applications have to 'opt-in' to benefit from the acceleration. That is, they have to be modified to use it, or use a SharedCLibrary that uses it. I'll tweak to the article to reinforce this. |
fwibbler
22/12/06 6:33PM |
I wonder if the new version of GutenPrint (5.0) will benefit from this?
It would be nice to get A4 photos printed in less than half an hour. |
wuerthne (+1.0)
22/12/06 8:12PM |
Robin Kevin:
Please be realistic. This module accelerates copying large blocks of memory from one location to another. This is about the very last thing DVD playing software requires. |
wuerthne (+0.1)
22/12/06 8:16PM |
In reply to fwibbler:
It is highly unlikely that Gutenprint would benefit at all from such a specialized optimization. In fact, I can think of very few cases where this acceleration would make any significant difference to an application's speed. With one interesting exception though: Due to the way it was designed, ArtWorks does indeed copy huge amounts of memory around and this has become a problem when editing with large files. So, at least for ArtWorks it will make a lot of sense to use this module when running on an Iyonix. |
rjek (+2.0)
22/12/06 8:23PM |
The Application Accelerator provides functions that help greatly in doing RAID. This is not surprising, given being the controller on a RAID card is what the IOP321 is designed to do. Running general purpose code is not what it is designed to do - as such, any possible applications for it will be quite narrow. |
AMS (+3.0)
22/12/06 9:04PM |
In reply to rjek:
"being the controller on a RAID card is what the IOP321 is designed to do. Running general purpose code is not what it is designed to do - as such, any possible applications for it will be quite narrow."
But the beauty of it is is it's a freebee. It's something built into the hardware, and if malloc() can be made take advantage of it, or even if some specific apps can use it well that's a good thing isn't it? Usually I am not usually surprised that once someone opens the door to making use of a speed enhancing feature people find ways to exploit it. And getting an x10->x20 memory transfer rate improvement for nothing I can happily accept without too much protestation.... 
|
adrianl (+1.0)
22/12/06 9:15PM |
You get an even better speed increase by not copying large chunks of memory in the first place. |
AMS (+3.0)
22/12/06 9:18PM |
Well yes, that's true
I meant in the context where you had to copy it - obviously if you can avoid it so much the better. |
rjek
22/12/06 9:47PM |
In reply to AMS:
I'm not sure why you think malloc() could be improved by this - I assume you mean memcpy() ? What I meant by my post is to clarify to some people that this won't suddenly make their computer go 5 times faster. It might make a small improvement to a handful of applications in very rare circumstances - it's relatively rare that you'd ever want to copy around large amounts of memory on desktop machines. |
AMS (+1.0)
22/12/06 10:19PM |
In reply to rjek:
memcpy(), yes sorry (sheepish grin).
Combination of tiredness and old age creeping up on me methinks.
|
| |
Software running on the 