Compression: 32bit or 64bit?
-
@gan:
I’m not saying that 64 bit is necessarily better and faster in all cases, but all the benchmarks/tests i have seen so far for WinRAR shows that the 64 bit edition is basically faster. These benchmarks show that 64 bit OS with 64 bit WinRAR is faster for all operations compared to 64 bit OS with 32 bit WinRAR, but 64 bit OS and 32 bit WinRAR is faster than 32 bit OS and 32 bit WinRAR which seems to be the slowest combination.
Not sure why the results differ for this test performed by PA.
-gan
maybe compression benchmarks, but for extractions, it is definitely slower… there is nothing special with these benchmarks, they can be done by anyone.
Basically due to nature of design, 64bit extraction has a lot of redundancy compared to 32bit. There is nothing extra there to gain speed, unlike during the compression.
So you come into situation that 32bit PowerArchiver is significantly faster than 64bit WinRar v4 under same 64bit Windows 7 computer :-)
Of course, PA is always faster anyway due to super duper optimizations our Eugene used for unrar :)
-
maybe compression benchmarks, but for extractions, it is definitely slower… there is nothing special with these benchmarks, they can be done by anyone.
Basically due to nature of design, 64bit extraction has a lot of redundancy compared to 32bit. There is nothing extra there to gain speed, unlike during the compression.
Well i’m not saying you are wrong and sure you guys know what you are doing:) I’m just saying all the benchmarks i have seen for WinRAR then WinRAR x64 performed better for both compression and extraction compared to WinRAR x86. If that means 64 bit is faster or if they done better work with the 64 bit version or if it doesn’t mean anything at all i don’t know.
-gan
-
@gan:
Well i’m not saying you are wrong and sure you guys know what you are doing:) I’m just saying all the benchmarks i have seen for WinRAR then WinRAR x64 performed better for both compression and extraction compared to WinRAR x86. If that means 64 bit is faster or if they done better work with the 64 bit version or if it doesn’t mean anything at all i don’t know.
-gan
well you can see benchmarks above for both 7zip and Rar v4… and with extraction, it is always slower. It has to be slower, it is due to how 64bits work… In the same time, compression is faster.
So ultimate tool would always use 32bit extraction and 64bit compression…
thing is, everyone will still complain, thinking that simply it has to be faster since it is 64bit! :-)
-
Did you do the 32 bit tests on a x64 machine/windows?
-
Did you do the 32 bit tests on a x64 machine/windows?
same computer was used, that was the point :-)
-
So the 32bit is executed using WOW? So x64 generates a lot of overhead.
-
So the 32bit is executed using WOW? So x64 generates a lot of overhead.
yep… for extraction it is useless… for compression, double the number of registers help it.
-
I vote -1 for 64 bit. Give prio to something else.
I never compress P*rn. I just extract it :D
-
-
-
So ultimate tool would always use 32bit extraction and 64bit compression…
thing is, everyone will still complain, thinking that simply it has to be faster since it is 64bit! :-)
Either way compression is a lot more time consuming so the most important part to improve. If i could pick 64 bit PA to get a bit faster compression, but also a bit slower extraction i would have picked that option.
I believe 64 bit Windows on the desktop really had a breakthrough with Vista and 7. A lot of people want 64 bit for the OS and then usually prefer native 64 bits applications as well even if they don’t notice a difference compared to 32 bit. I guess it’s not a matter of “if” a software company should have a 64 bit version, but but “when” it should happen since 64 bit obviously is the future. Some competitors are already there and i think PA should consider to do the same thing sooner instead of later.
-gan
-
@gan:
Either way compression is a lot more time consuming so the most important part to improve. If i could pick 64 bit PA to get a bit faster compression, but also a bit slower extraction i would have picked that option.
I believe 64 bit Windows on the desktop really had a breakthrough with Vista and 7. A lot of people want 64 bit for the OS and then usually prefer native 64 bits applications as well even if they don’t notice a difference compared to 32 bit. I guess it’s not a matter of “if” a software company should have a 64 bit version, but but “when” it should happen since 64 bit obviously is the future. Some competitors are already there and i think PA should consider to do the same thing sooner instead of later.
-gan
well this is why the thread was started - to see if people want 64bit extraction of RARs even if it is slower than 32bit extraction of RARs and has no benefit except for being slower :-)
-
well this is why the thread was started - to see if people want 64bit extraction of RARs even if it is slower than 32bit extraction of RARs and has no benefit except for being slower :-)
Sure i understand and just giving my vote:) But faster compression is a benefit i would say and i assume a 64 bit PA would support the creation of zip, zipx and 7z like the 32 bit edition. The ability to create RARs using PA would be great as well, but that’s another discussion already to be found in other threads.
-gan
-
@gan:
Sure i understand and just giving my vote:) But faster compression is a benefit i would say and i assume a 64 bit PA would support the creation of zip, zipx and 7z like the 32 bit edition. The ability to create RARs using PA would be great as well, but that’s another discussion already to be found in other threads.
-gan
it is possible to use 64bit compression and 32bit extraction for instance (in the same app)
whole idea that started the thread was that we thought we might add 64bit extraction of rars to PA 32bit, in the case it was faster… so we tested… and tested… and realizied it is not :-).
PA can not be fully 64bit until there is 64bit version of Delphi (maybe this year), but even then, apparently, it would make sense to actually test if some engine would do better with 32bit version.
Mixing 32/64bit is more work but if it makes things faster, why not.
-
Extraction to me is not as important as compression (Given a reasonable time frame for both). With ISP’s limiting traffic and the rise of cheap online storage, I want to be able to effectively backup things. A smaller file size to me is more important than a little extra time waiting to extract it.
Mame
-
…A smaller file size to me is more important than a little extra time waiting to extract it.
If you are talking seconds (or less) then I would agree.
But if you start needing an extra 10 - 20 mins (for v. large archives) then I would disagree. My point is “real-time” not a percentage change. -
I don’t think that some (milli)seconds are the problem. Sorry, but i don’t sit while compression/extraction with a stopwatch at the pc. The reason why i would use a 64bit Version is the native support. I believe, when more software works native, software could be more optimized on it. At the moment there is no reason for developer to (or microsoft) optimize the code execution, as long the 32bit software works…
Ask yourself… would you run on xp a 16bit application if you have a 32bit that do the same? -
The reason is that I don’t want my Windows to be over-bloated with WOW64 emulation to support old 32 bit code. I prefer all code to migrate to 64 bit and MS to drop emulation.
Second reason is that when a developer says he can’t support 64 bit it instantly crosses my mind that he uses outdated IDE and compilers. And this makes me think that probably the whole code (GUI and everything) is not optimized for current multi-core processors and 64bit OS.
In Delphi you cannot use for example Intel Parallel Studio to optimize the code for multi core etc. Also Delphi use that over-bloated forms which makes huge executables.
-
all of our code is in C libraries, not delphi… which is why it is faster than WinRar and WinZip, and soon 7zip.
IPP is too buggy to be seriously used, but it is good try… we optimize our multicore code manually.
Intel has decent idea with primitives and ipp, it is just buggy.
-
On an existing business side of things, its far too expensive and complicated to move everyone onto 64Bit system and OS then upgrade every Application. I work for a group that has over 7300 Employees UK they use Windows XP Pro 32bit and office 2003 SP3.
They have a 3 year I.S Plan to move everyone onto Windows 7 32Bit, why not 64bit?? because of known software incompatibilities and Code has to be rewritten from scratch so developers charge more.
Keeping PowerArchiver as a 32bit application although its proven better at extracting than 64bit does not stop skeptics from questioning and in many ways slander the application on forum’s, reviews, websites etc all just because it isnt using the more “Modern” 64bit. This in return can cause a domino decline on New Business and increase lapsed sales.
On my side of things, and companies i work closely with both inside my group and outside via charities or contracted assignments they all Compress to Send out large documents, images etc etc and also to backup large folder’s on networked drives to then upload to a remote servers via FTP…. All methods the New PowerArchiver now features…
SO… Having a program that is 64bit with a 64bit OS that can handle large archives faster is a welcome addition to what already is a great application.
My advise to ConeXware…
Finish 2011, work on a new website and then come 2013 Anounce “PowerArchiver X64 Toolbox Edition”.
I would not do a 64bit Standard Edition, Why? Because I deem 64bit used more by Profesionals that deal with file archiving every day and that would fall under the new Toolbox edition.
