4. Native 64-bit support

    Recent Topics


Native 64-bit support

  • Y

    Hi guys. I figured it’s time to make my pitch, now that Winrar decided to go x64, and Microsoft announced win7 to be the last x86 OS, and 64-bit processors are a lot more common than they were just a year ago. Perhaps it is time to have a native 64-bit version (I can see that that’s unlikely for PA2010, but maybe PA2011 or even later releases of 2010)?
    Winrar people claim that utilizing 64-bit processing yields better performance, and there are all those pesky UI issues that creep up every now and then. Overall, it’s a bit frustrating to use a 64-bit OS and not have software that utilizes its abilities.

    Also, I really like to hear whether your statements regarding faster rar compression than Winrar are still relevant after they also introduced multi-core support (and they alone have native x64 support). Will you get around to do competitive comparisons of compression rates and times between PA and its main competitors, where each suite is operated at best configuration?

    Thanks, and sorry for the lengthy post.
    Also, in the possibility that someone has already posted rearding this issue, let me just say that I did an advanced search that came up empty (but I already know that it sometimes doesn’t work)

    0
  • spwolf
    conexware

    there is no performance benefit from using 64bit for compression purposes. Only benefit you will see from using 64bit OS will be more memory. Sooner you realize that, less dissapointed you will be at the end :-).

    This has been mentioned several times before and unfurtonaly there is no magic wand which will make applications suddenly run faster in 64bit :).

    As to the multicore, WR has multicore for rar compression, we have it for zip and 7zip. Neither of us have it for unrar/unzip (its a lot more complicated), we just have better optimized unrar performance.

    0
  • spwolf
    conexware

    @yoniy0:

    and there are all those pesky UI issues that creep up every now and then.

    if you mean things like white background in shell extensions, that was due to 64bit shell extensions :).

    Also we cant compare directly WR compression to PA, as they dont support multicore for zip and we (obviously) cant compress to rar.

    0 Y 1 Reply
  • Y

    spwolf, I hope I don’t sound as if I don’t appreciate your product. It’s really good. In fact, if someone would have told me a few years ago that I’d be paying money for an archiving utility, I’d probably laugh.
    As I said, it’s really only a matter of time before you’d have to make the move to x64, so I thought perhaps it could happen sooner rather than later. I can live without it.
    Nevertheless, you didn’t really answer me regarding the comparisons. You could compare compression rates of WZ and PA in zip/xzip files, and you could compare compression rates obtain in rar format opposed those you incorporate in PA. Also, users will probably be interested by differences in compression times between PA and WR/WZ even when compressing with different methods (after all, as long as the difference in file size is only a few percents, I really see compression time playing a key role in my decision when I choose a format for backup/distribution). Don’t you think?

    Thanks again spwolf. You really have a winning product. This all is only about making it even better.

    0
  • spwolf
    conexware

    sure, but there would be no difference due to it being 32bit and 64bit.

    it is all about time - we could make pointless 64bit version just because so we can tell our users that it is superior, or we could spend that time and add useful features - like multicore support for zip we added in PA 2010.

    as i said before, there are no benefits i can see from having 64bit version.

    For instance, i tested unrar on 64bit version and compared it to ours (-m5 + solid archive) and ours is still faster, and its 32bit! :-).

    0
  • spwolf
    conexware

    i think sooner people realize they gain nothing with 64bit with exception of addressing more memory, less dissapointed they will be once they move to 64bit Windows.

    0 RJWaring 1 Reply
  • RJWaring

    I have to agree with Spwolf, I personally see no point in re writing PowerArchiver to another model supporting 64Bit.

    The team at PA strive above any other Archive tool to interact with their customers in order to resolve, fix, develop and improve the service and features of their application.

    This interaction has in its self created a significant increase in usability and speed.

    All this without the need of 64bit.

    Microsoft’s Primary reason to move their OS to 64bit is due Memory, Security and Cost. But they will still have to support software running on 32bit for Decades to come… And if you do your research the 64bit Processor was actually invented and used in super computers around the 1960’s. It wasn’t until 2003 that AMD and Intel adapted the technology to be used within the PC.

    That’s 5 Decades so working on that timeframe who knows how compression algorithms will develop and by that time PA would have adapted their software to suite.

    0
  • drteeth

    The only time the move to 64 bit will HAVE to be made is when a 64 bit version of Windows is released which will NOT run 32 bit apps. 64 bit is NOT obligatory or necessary at the moment at all. 32-bit apps still get several memory benefits running under a 64 BIT OS.

    Talking of speed of 64 bit apps…a programmer told me that even the 64 bit version of office 2010 uses a 32 bit subsystem (MAPI interface) and that also holds back any speed ups.

    DrT

    0 twphoenix 1 Reply
  • twphoenix

    Hello,

    i still think the task to support native x64 should be made.
    even if there is only a 5% - 8% Speed Inrcrease of Compression/Decompression.

    I Have different Archivers Running on Windows 7 x64 and Windows 7 x86 (on my Notebook, will switch later because i need more RAM)

    Powerarchiver 11.64
    WinRAR 3.93
    and
    Squeez 5.62

    On x86 Windows Powerarchiver is the Fastest, closely followed by WinRAR then in the last Place Squeez because it has no Multicore Support is the slowest.

    On my x64 Windows WinRAR x64 is the Fastest then comes Powerarchiver and then Squeez witch runs as a Native x64 App - It Still can Keep Up even if the Development Stopped.

    0 drteeth 1 Reply
  • spwolf
    conexware

    there is no difference in WR 32bit and 64bit when it comes to extraction, i tested it when we made our improvements to unrar.

    0 twphoenix 1 Reply
  • spwolf
    conexware

    ie there will be no 5-8% improvement due to 64 bit… but there are improvements to be found in general optimizations to be sure, probably even greater than that…

    We will have to make 64bit version once 64bit delphi compiler comes out, mostly because it is marketing - you cant convince people there are no tangible differences :)… It is easier to advertise “64bit version - faster and more secure!!!”.

    0
  • twphoenix

    Hello,

    that maybe so for Extraction/Decompression but on my PC the Compression is faster not by much but Still faster.

    Ok. That Delphi (or RAD Studio) still no x64 Compiler has is strange and is a Problem. So I guess we have to wait.

    0 spwolf 1 Reply
  • spwolf
    conexware

    @twphoenix:

    Hello,

    that maybe so for Extraction/Decompression but on my PC the Compression is faster not by much but Still faster.

    indeed - it is faster for sure, i tested it - we are talking about WR though, so you cant compare it to PA directly :).

    but here is the thing - we managed to make much bigger improvements in 32bit (and 32bit in 64bit OS) with general optimizations in unrar, so i would guess if we could create rars, we could do similar types of improvements as well :).

    0 twphoenix 1 Reply
  • twphoenix

    @spwolf:

    indeed - it is faster for sure, i tested it - we are talking about WR though, so you cant compare it to PA directly :).

    That is so with most of the Archivers or Compression Programms. 🙂 Even if You could compare them because they can compress the same formats. There is still no direct Comparsion possible.

    @spwolf:

    but here is the thing - we managed to make much bigger improvements in 32bit (and 32bit in 64bit OS) with general optimizations in unrar, so i would guess if we could create rars, we could do similar types of improvements as well :).

    Yes. I think you could. 😉 Witch is why i also bought Powerarchiver. If you also could add some features i need witch are present in the Other Archivers i think i could and would Stop using WinRAR and Squeez.

    Best Regards,

    R. Landscheidt

    0
  • spwolf
    conexware

    well post away with the wishes so we can know what you want!

    0 twphoenix 1 Reply
  • twphoenix

    Hello,

    Well i think i posted them in "What format next? December 2009) but i’l make an new Thread with them.

    0 spwolf 1 Reply
  • drteeth

    @twphoenix:

    Hello,

    i still think the task to support native x64 should be made.
    even if there is only a 5% - 8% Speed Inrcrease of Compression/Decompression.

    I wonder how you managed to measure those differences. <10% is not noticeable in general use.

    DrT

    0
  • spwolf
    conexware

    @twphoenix:

    Hello,

    Well i think i posted them in "What format next? December 2009) but i’l make an new Thread with them.

    one thread per major wish, thats much easier for us to keep track of things…

    0
  • spwolf
    conexware

    Here you go:
    http://www.powerarchiver.com/forums/showthread.php?t=4867

    new thoughts on 32bit or 64bit dilemma… post away!

    0
  • spwolf
    conexware

    64bit engine version for new PAF? Vote away here:
    http://ideas.powerarchiver.com/

    0
  • S

    I know I might be going over new ground but correct me if I’m wrong.

    doesn’t powerarchiver need to access file management tools to get files. File managers need to access the 64bit windows file system why doesn’t powerarchiver?

    0 spwolf Brian Gregory 2 Replies
  • spwolf
    conexware

    @splash3313 said in Native 64-bit support:

    I know I might be going over new ground but correct me if I’m wrong.

    doesn’t powerarchiver need to access file management tools to get files. File managers need to access the 64bit windows file system why doesn’t powerarchiver?

    As mentioned recently on forums, x64 is coming with PA 2017.

    But as to your question, PA 2016 already has x64 parts such as shell extensions so it works properly. PA 2017 will be full x64 so we can address more than 2 GB of memory for new format.

    0
  • Brian Gregory
    Alpha Testers

    @splash3313 Ah, so you’re one of those weirdos that denies that 32 bit software runs on 64 bit Windows 🙂

    0
  • S

    Actually 32 bit software will run just will have problems on 64bit computers when it comes to file management not my words microsofts.

    0 Brian Gregory 1 Reply
  • Brian Gregory
    Alpha Testers

    @splash3313 Can you provide a reference for that please?

    0 S 1 Reply
  • S

    @Brian-Gregory https://blogs.msdn.microsoft.com/oldnewthing/20081222-00/?p=19763/

    basicalyl the link is old but gets to the point that a 64bit operating system use emulation to run 32 bit software.

    http://www.digitaltrends.com/computing/32-bit-64-bit-operating-systems/

    0
  • S

    64bit and 32 bit store files slightly different that is why on a 64 bit system programs that are v32 bit might not be able to see all files available on your computer.

    0
  • spwolf
    conexware

    x86 programs run perfectly (and start faster) on x64 system. Only thing not available is addressing over 2GB of memory.

    Since in 2017 we are adding our own format where you can use more than 5-6 GB of memory, realistically, when needed, we are also adding full x64 version of PA.

    Also, codecs built from grounds up might support faster instructions in x64, so with .pa format you will see up to 30% faster performance in x64 than in x86… for .zip, performance difference is nowhere as close, if any.

    0
Log in to reply