More > JRiver Media Center 18 for Mac
What's your JRiver on Mac JRMark result?
Matt:
--- Quote from: bplexico on October 22, 2013, 11:10:10 am ---Hey John! Thanks for the thoughtful explanation, makes sense and it is appreciated. And by the way, it was not intended as a slight at the Mac version, more intellectual curiosity.
--- End quote ---
Would you be willing to post the full result from each platform? Maybe use the fastest result from two or three runs on each platform.
I'd like to compare them line-by-line. Thanks.
bplexico:
--- Quote from: Matt on October 22, 2013, 11:27:59 am ---Would you be willing to post the full result from each platform? Maybe use the fastest result from two or three runs on each platform.
I'd like to compare them line-by-line. Thanks.
--- End quote ---
Absolutely, I will do so when I get home tonight.
Barr
bplexico:
Ok Matt, here you go:
2012 Mac Mini - 16 GB Memory - 512 GB SSD Boot Drive - 2.6 GHz Intel Core i7 - OS X - version 10.8.4 - Playback over NAS - no wifi enabled.
Mac OS 10.8.5:
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 3.869 seconds
Single-threaded floating point math... 2.563 seconds
Multi-threaded integer math... 1.044 seconds
Multi-threaded mixed math... 0.746 seconds
Score: 2311
Running 'Image' benchmark...
Image creation / destruction... 0.750 seconds
Flood filling... 0.697 seconds
Direct copying... 0.759 seconds
Small renders... 1.345 seconds
Bilinear rendering... 1.047 seconds
Bicubic rendering... 0.515 seconds
Score: 4303
Running 'Database' benchmark...
Create database... 2.037 seconds
Populate database... 1.659 seconds
Save database... 0.164 seconds
Reload database... 0.064 seconds
Search database... 1.131 seconds
Sort database... 0.950 seconds
Group database... 0.786 seconds
Score: 3165
JRMark (version 19.0.55): 3260
Windows 8 - all updates applied.
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 3.776 seconds
Single-threaded floating point math... 2.511 seconds
Multi-threaded integer math... 1.147 seconds
Multi-threaded mixed math... 0.770 seconds
Score: 2316
Running 'Image' benchmark...
Image creation / destruction... 0.240 seconds
Flood filling... 0.402 seconds
Direct copying... 0.463 seconds
Small renders... 1.201 seconds
Bilinear rendering... 1.007 seconds
Bicubic rendering... 0.660 seconds
Score: 5537
Running 'Database' benchmark...
Create database... 0.396 seconds
Populate database... 1.223 seconds
Save database... 0.314 seconds
Reload database... 0.063 seconds
Search database... 1.014 seconds
Sort database... 0.933 seconds
Group database... 0.715 seconds
Score: 4615
JRMark (version 19.0.58): 4156
And finally using a Windows 8 Audio optimization script:
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 3.793 seconds
Single-threaded floating point math... 2.513 seconds
Multi-threaded integer math... 1.077 seconds
Multi-threaded mixed math... 0.771 seconds
Score: 2330
Running 'Image' benchmark...
Image creation / destruction... 0.229 seconds
Flood filling... 0.399 seconds
Direct copying... 0.459 seconds
Small renders... 1.200 seconds
Bilinear rendering... 0.842 seconds
Bicubic rendering... 0.553 seconds
Score: 5976
Running 'Database' benchmark...
Create database... 0.415 seconds
Populate database... 1.255 seconds
Save database... 0.309 seconds
Reload database... 0.059 seconds
Search database... 1.008 seconds
Sort database... 0.932 seconds
Group database... 0.717 seconds
Score: 4579
JRMark (version 19.0.58): 4295
Matt:
Thanks for the report.
The math scores are identical on each platform. That's good, because it shows the hardware is operating roughly at parity on both systems. The math test is the one test that doesn't really involve much code or JRiver stuff -- it's just a raw CPU performance test. That means comparing the rest of the numbers should be valid.
In the image section, Windows is running away on memory allocation and writing. When it gets to rendering that's more CPU intensive and less memory intensive, they get pretty close. Looking at our code, one thing I see is that there's an assembly memory fill in the image engine not unlocked on Mac yet. We'll look at this.
In the database code, it's really close on the normal operations like grouping, sorting, etc. That means real-world performance will be quite similar. However, the memory allocation difference shows again during the create database section. We'll have to investigate this. It may turn out that more aggressive caching (to reduce memory allocation) of string objects or something could help Mac a lot.
Anyway, thanks for doing the tests. I hope it helps us make the Mac version faster.
bplexico:
Always happy to assist, and I am having fun trying out the Windows version as well.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version