(BUG) # of Threads -Auto Select only using 1 thread

[AluminumHaste]

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.

[spwolf]

@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.

[AluminumHaste]

The file was 538MB

[spwolf]

@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!

[AluminumHaste]

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

[spwolf]

@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.

[AluminumHaste]

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.

[spwolf]

@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.

[AluminumHaste]

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.

[spwolf]

@aluminumhaste yep, lets see with that.