Recent Topics
-
UNSOLVED Security vulnerability in UnAceV2.dll
Tech Support4 -
Fast Ring: PowerArchiver 2019 19.00.30
Tech Support5 -
UNSOLVED powerarchiver 2019 encryption policy
Tech Support4 -
UNSOLVED PA2019b30 Backup Progress Display Issues
Tech Support1 -
UNSOLVED PBS Filenames
Wishlist3 -
SOLVED PA2019 build 30 Backup Trial Message
Tech Support9 -
SOLVED Unwarranted Right Click Menu Entries By Powerarchiver
Tech Support4 -
UNSOLVED Message popping up.
Tech Support5 -
UNSOLVED Should I trust 7-Zip
General Chat3 -
SOLVED forum image broken
General Chat3 -
UNSOLVED PowerArchiver Test unexpected behavior with encrypted archive
Tech Support2
(BUG) # of Threads -Auto Select only using 1 thread
-
I just tried using PA2017 to create a .pa extreme compression archive of a DSF file.
I left # of threads at Auto Select and it used 1 thread (25% CPU usage)
I cancelled that and created it again, this time manually selecting 4 threads and now it’s using 100% of the CPU.
-
@aluminumhaste said in (BUG) # of Threads -Auto Select only using 1 thread:
I just tried using PA2017 to create a .pa extreme compression archive of a DSF file.
I left # of threads at Auto Select and it used 1 thread (25% CPU usage)
I cancelled that and created it again, this time manually selecting 4 threads and now it’s using 100% of the CPU.how large is the file?
Using mt will quite often increase the size of the file, so chunk size (amount of each thread gets) gets increased based on strength setting, in relation to dictionary size.
however you can manually force usage by selecting manually number of threads, and PA will respect that.
-
The file was 538MB
-
@aluminumhaste said in (BUG) # of Threads -Auto Select only using 1 thread:
The file was 538MB
try it again with PA 2018 and see what happens there. Thanks!
-
I can’t do that at work as I don’t have Admin access on that computer so can only use portable version of PA, which isn’t ready for 2018 yet. I can however try the same thing on my home computer later on tonight
-
@aluminumhaste cool, lets see what happens. On extreme there should be 3 or 4 threads for that size file, in any case, more than 25% on 4 thread cpu.
-
Intel Core i7 4770K @ 4.2Ghz (4 Cores, 8 Threads)
Test File: DSFcomnpressTEST.dsf - 629,998,513 Bytes
1st Test:
PA Optimize Strong - Extreme compression - Threads (Auto)
Elapsed Time: 4:35
Average CPU Usage: 45%
Final Size: 318,914,153 Bytes (49% Compression Ratio)2nd Test:
PA Optimize Strong - Extreme compression - Threads (Manually set to
Elapsed Time: 4:25
Average CPU Usage: 42% <-Strange, I would have expected to see higher usage than that
Final Size: 318,914,153 Bytes (49% Compression Ratio)Since they both came out to be the same size, I’m assuming this means both were using the same amount of threads based on your comments here.
-
@aluminumhaste yes, this is now correct behavior… due to the chunk size settings, more mt cant be used even if set… if you go to advanced option, lower chunk size and try again.
Chunk size is what each thread gets… if default for extreme is 192M, then 2 threads can find work there.
Of course, if you set it to less, then compression dictionary might not be as effective, since it will get to work on smaller amount of data, but it does depend on the data itself.
-
Okay, so there’s really no gains in compression speed here, since the outcome we would want is smallest size.
I’ll leave this as normal then on this computer.
Once PA 2018 portable comes out, I’ll try again on these lower end CPUs at work, which did see large gains forcing 4 threads.
-
@aluminumhaste yep, lets see with that.
