WinRAR 4.20 gets multi-threaded support

[GTRagnarok]

Wow, this is one sweet update. Before, I was getting 4.7 MB/s.

Managed to get this with a bump in BCLK:

Pushed to the limit:

 

[lopri]

3.90 GHz Thuban

 

[lopri]

4.80 GHz Sandy No-HT

 

[lopri]

It is interesting that your numbers are higher than SB at 4ghz.

I think you maybe right about the extra memory bandwidth.

I need someone with SB-E @ 4ghz which is a quad channel setup to post if there numbers are higher than what i posted this should confirm your theory.

Way higher. Definitely memory latency/bandwidth (triple-channel).

 

[lopri]

@AtenRa: In your post #39, all numbers except the triple-channel DDR3-1600 are moving toward 8000 Kb/s after the burst period (look at the "current" number at 1 minute mark), which implies that all the other configs (dual-channel DDR3-1600, triple-channel DDR3-1066, etc.) are not providing enough bandwidth for the IMC. (a good IMC :thumbsup: )

The biggest factor looks to be Hyperthreading (for Intel) and memory bandwidth/latency (for AMD). But does WinRAR performance matter much? (Unless you're hunting around torrents 24/7, of course. :biggrin: )

 

[Makaveli]

Here is a 980X running stock speeds from a Corsair Force 3 SSD. About 70% usage.

Hey nice score what speed is your memory running at since your at stock clocks?

The biggest factor looks to be Hyperthreading (for Intel) and memory bandwidth/latency (for AMD). But does WinRAR performance matter much? (Unless you're hunting around torrents 24/7, of course. :biggrin: )

Agreed it really depends on how much archiving you actually do but I'm just happy to see one more application actually use all these cores most of us are sitting on. And if it means we gotta go one app at a time then so be it.

 

[james1701]

1833 or so. Its a stock setting 9-9-9-24. My memory is ddr3 2000 but I don't run it that high. Since I went back to college, I have turned off my overclocks since I am mainly doing productivity and not gaming much at the moment.

 

[Phynaz]

@ Rubycon

Just impressive :thumbsup:

Yeah, Dawn has nice toys. Ask to see her SSD numbers sometime

 

[Rubycon]

Increasing bclk to 186 does not improve performance that much. Notice the lack of serious load as well.

It's definitely an improvement over 4.01 however. Time to test it in the real world with some 500GB archives.

 

[Makaveli]

Increasing bclk to 186 does not improve performance that much. Notice the lack of serious load as well.

It's definitely an improvement over 4.01 however. Time to test it in the real world with some 500GB archives.

That is the test i'm waiting for ruby cause I know that benchmark isn't really doing that Xeon justice!

 

[prino]

I like all of the results, but has anyone noticed that WinRAR now disables text compression by default and that many archives containing mainly text will be significantly bigger - even archives containing z/OS (i.e. EBCDIC encoded) data.

Running archiving jobs in the background, so not really interested in speed and not a happy bunny!

(And if anyone can explain to me why you cannot compress text in multi-threaded mode, please do so!)

 

[ninaholic37]

This is what it says on rarlab.com:

c) RAR text compression algorithm cannot utilize several CPU cores efficiently, so its performance in multiprocessor environment is much lower than for general algorithm. Also its decompression speed is much lower than in general algorithm regardless of CPU number. So we decided to disable the text algorithm by default.

If you need maximum possible compression ratio for plain text data regardless of speed, you can enable the text compression in "Advanced compression parameter" dialog. Press "Compression..." button on "Advanced" page of archiving dialog to access it. You can also change this option permanently in default compression profile;

In the command line mode the text compression can be enabled with -mct switch;

http://www.rarlab.com/rarnew.htm

Very strange move, considering that text files can compress very well (up to 99% as they hardly ever use characters outside ASCII 32-126), and much better than most other filetypes like mp3, jpeg, avi, etc.! Using the default settings can now put WinRAR a significant step down from zip compression.

 

[borisvodofsky]

This is what it says on rarlab.com:

http://www.rarlab.com/rarnew.htm

Very strange move, considering that text files can compress very well (up to 99% as they hardly ever use characters outside ASCII 32-126), and much better than most other filetypes like mp3, jpeg, avi, etc.! Using the default settings can now put WinRAR a significant step down from zip compression.

Sounds like rarlab was just too lazy to change their algorithm for text compression. It makes sense though, cuz we don't need to compress text too often, they're not that big. :sneaky:

 

[prino]

Sounds like rarlab was just too lazy to change their algorithm for text compression. It makes sense though, cuz we don't need to compress text too often, they're not that big. :sneaky:

The problem is that non-text files also suffer. I make backups of z/OS data (EBCDIC encoded) and they routinely are 10-15% bigger than when compressed with WinRAR 4.11, unless I use the "-mct" switch - I rally don't care about the speed of compression, all jobs run in the background anyway.

 

[SlowSpyder]

3.90 GHz Thuban

That's interesting. I guess DDR3 and the faster NB/L3 really make a difference. I am getting about 5.8MB/sec on my Thuban @ 4.1GHz/2.6GHz and DDR2 @ 866Mhz.

 

[Magic Carpet]

That's interesting. I guess DDR3 and the faster NB/L3 really make a difference. I am getting about 5.8MB/sec on my Thuban @ 4.1GHz/2.6GHz and DDR2 @ 866Mhz.

Can't be that slow. My Thuban @ 3.3 Ghz gets 5.8MB/sec and that's with only DDR3 single channel memory used. (NB @ 2.5 GHz, by the way)

 

[Makaveli]

Can't be that slow. My Thuban @ 3.3 Ghz gets 5.8MB/sec and that's with only DDR3 single channel memory used. (NB @ 2.5 GHz, by the way)

Guys its most likely the Memory speed and bandwidth if you go back and look at Aten Ra testing this benchmark is very sensitive to those factors.

 

[lopri]

That's interesting. I guess DDR3 and the faster NB/L3 really make a difference. I am getting about 5.8MB/sec on my Thuban @ 4.1GHz/2.6GHz and DDR2 @ 866Mhz.

Very roughly, you want the followings:

1. System bus : Memory ratio bigger than 1:2. (such as 3:8 or 3:10)
2. CPU-NB : Memory ratio bigger than 1:2 (e.g. dual-channel DDR3-1333 for CPU-NB @2.2 GHz)

Some boards are better at 3:8 and some are better at 3:10. Almost all boards will experience a "strap" like behavior somewhere around 230~250 HTT. Which means the inner working of CPU-NB is reset at that point. So you want to experiment to find where it lies, even if you have a Black Edition CPU.

Once you find such a spot, you can 1) settle there and raise the multipliers of CPU and CPU-NB, or 2) raise the HTT even further while maintaining low multipliers. Black Edition CPUs can choose either option. Low-multi CPUs are obviously more restricted by the board's HTT capability and memory specs, as well as chemistry between them (i.e. BIOS programming).

DDR2 platform is at a disadvantage because DDR2 sticks run 800 MHz or 1066 MHz at most. Faster CPU-NB still contributes to better overall performance but latency/bandwidth-sensitive workload loses a portion of performance. Apps that benefit from faster cache (games) also loses some performance because DDR2 can't feed it fast enough.

 

[Despoiler]

I get ~6100 with the specs in sig. All cores load up at ~90%.

 

[Rodrigox]

I get 5600 KB/s with i5 750 @ 3,6Ghz

Seems like even the old lynnfields are better than bulldozers, cuz with 4 cores FX perform worse.

Anyway how about some single thread benchmarks???

I got 1700 KB/s.

 

[nyker96]

I think 7zip already has this feature for a while now. This is also the reason I switched over to 7z from winzip cause i have a quad. 7zip was just faster.

 

[Makaveli]

I think 7zip already has this feature for a while now. This is also the reason I switched over to 7z from winzip cause i have a quad. 7zip was just faster.

I've heard this about 7zip also and recently I did some testing with it.

It definitely had multicore support before winrar, however for me I deal with and have people send me far more rar files than 7zip files so this reason alone is why winrar is my primary I do have both installed tho.

 

[Magic Carpet]

I think 7zip already has this feature for a while now. This is also the reason I switched over to 7z from winzip cause i have a quad. 7zip was just faster.

The default compression method 7z uses, supports only two threads. Maybe it's great for benchmarks, but in regular use it is just way slower. Run some tests for yourself.

 

[lamedude]

Isn't LZMA2 the default now? Its not hard to change it if its not.

 

[Magic Carpet]

Isn't LZMA2 the default now? Its not hard to change it if its not.

I am not sure, but the point is... if I change to whatever supports all of my cores, then it gets considerably slower than WinRAR. And I mean it.

The default choice there, is for a reason. Excellent compression and reasonably fast but... not fast enough (due to the "poorly" written multi-threading engine in that compression mode).