first of all I'd like to thank you for such a great product, but now that 64-bit is gaining acceptance on the consumer market how about making a 64-bit version of PNGOUT?
I am pretty sure there will be a measurable speed gain, what do you think?
Regards doonh
Awesoken at
Re: 64-bit version of PNGOUT
Unfortunately, I do not have access to a 64-bit OS and compiler right now. Usually I like to try things before saying 'you're wrong'. Instead, all I can say is that I see very little that could benefit from 64-bit mode. The bottleneck seems to be random memory accesses and branching. I would be surprised if it runs even 5% faster in 64-bit mode.
If you're looking for a measurable speed gain, why not try PNGOUTWin, which can run trials in different threads. If you select multiple files or trials, it should run much faster than doing the equivalent in the command line version.
Its`about at
Awesoken said at
Unfortunately, I do not have access to a 64-bit OS and compiler right now. Usually I like to try things before saying 'you're wrong'. Instead, all I can say is that I see very little that could benefit from 64-bit mode. The bottleneck seems to be random memory accesses and branching. I would be surprised if it runs even 5% faster in 64-bit mode.
If you're looking for a measurable speed gain, why not try PNGOUTWin, which can run trials in different threads. If you select multiple files or trials, it should run much faster than doing the equivalent in the command line version.
I think that being free of multilib junk would be more than "very little [...] benefit". The kernel becomes substantially larger with IA32 emulation too -.-. If testers with 64-bit environments are needed, I'd be more than willing to be a figurative guinea pig.
PS may I request an SSE4 build, or would that not result in any performance increase?
Edited by Its`about at
Awesoken at
PNGOUT does not use kernel functions in its innermost loops, and vector instructions would not help code that has a lot of branching. I'm sure a 64-bit build of PNGOUT will be released at some point, but it's not likely to happen until I upgrade my OS.
Its`about at
Awesoken said at
PNGOUT does not use kernel functions in its innermost loops, and vector instructions would not help code that has a lot of branching. I'm sure a 64-bit build of PNGOUT will be released at some point, but it's not likely to happen until I upgrade my OS.
By being free of multilib junk, I meant there'd be less junk on the system to install, update and put up with, not that there'd be a performance increase.
As for upgrading your OS, hardened GCC4 has been merged into portage, in case that's what's stopping you (I'm using it presently).
David at
Ken has access to a compiler capable of building 64 bit targets, and he as a PC with a 64 bit processor, but he doesn't (yet) have a 64 bit version of Windows installed that would allow him to debug and tune the code. This is by choice. He has access to more than sufficient funds, and through Ardfry he has access to licenses as well through a Microsoft marketing program.
In my own experience going 64 bit doesn't make all that difference in performance unless you are memory bound. You could probably use some of the extra registers in some cases, but 64 bit isn't a silver bullet for all technical challenges. You do a port to 64 for compatibility more than anything else. If we wanted the PNGOUT plugin for Photoshop to work with the 64 bit version of Photoshop CS4 then we'd have to do a port of the compression engine. PNGOUT also has a decoding module that would need to be ported to 64 bit (I've already ported the JPEG parts), but that wouldn't need to be done as part of the plug in work.
When it's all said and done, any performance gain won't be significant, so I can see why Ken isn't in a rush to do a somewhat tedious porting job that will have little benefit. There are far more interesting and difficult technical challenges out there than changing "long" to "LONG_PTR" in all the right places.