Fastet Packjpg on the way ?

[SvenBent]

just got this reply from Matthias Stirner


Hi Sven,


you wrote:

> When PacJPG is about to (de)compress bunch of files (E.G. PackJPG img*.jpg), instead of doing them one by one, do a bunch in parrallel.
> That should make a nice bost in performance for dual and quadcore owners at the cost of a little memory.

I actually don't know much about multithreaded programming yet, but what you suggested should be possible (while multithreaded compression of one file is not). I'll consider that, and include it in future packJPG versions if possible. Thanks for the suggestion.


Best Regards,
Matthias Stirner


I'm just about to cry

[encode]

I think, at some point, the power of multithreading is overestimated. In many algorithms, it may give no improvement. Anyway, processing many files simultaneously is good idea – you may do this by yourself – running multiple executables. Sometimes I do the same thing with LAME while I do encode WAV files to MP3.

[SvenBent]

#Encode

I do that already. (running multi instances) but it can be difficult to do on a folder with 100's of JPEG's.
With a built in function it much easier-. off cause the memory requirements is going to something like 4x , but it hardly an issue for people on Quad's

[Simon Berger]

I think, at some point, the power of multithreading is overestimated. In many algorithms, it may give no improvement.

You see it from the wrong side. Multithreadting is the system of the future. But yes on some problems you cannot use it or it is so complicated to build it in. That it isn?t at least faster :-P

In packjpg it?s only interesting for me if it will be yoused for the archive format