Multiple CPU -> Maximize Throughput (Music Converter)

[timw0932]

I have a 4 core i5 750, and I'm finding the music converter's multiple CPU support to be a mixed bag when source and destination drives are the same (I didn't test different drives for source and dest). When converting (say) FLAC -> ALAC, it seems to be beneficial for short songs, but add some longer ones, and it actively hurts performance, I think due to disk thrashing. For example, I killed a conversion tonight once it dropped down to 30x with 4 cores active. (Mostly INactive, actually!) I tried it with a single CPU, and got 60x. With two CPUs, it ended up 58x. Of course, the 4 CPU run started out 130x due to short songs, but it dropped to half of SINGLE-core speeds once it hit the long ones.

So, I think multiple CPU support is not the ultimate goal. The ultimate goal is to maximize throughput, and the current multiple CPU support actually hurts throughput a lot of the time. So I would look into improving that.

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

Interesting comment. What was the time difference with a single file conversion versus multiple file conversion from FLAC to ALAC for the multi-file conversion to complete? I'd be surprised if a single file conversion ended faster than multi simultaneous conversion. Ignore the throughput showing, but focus on the actual time to complete the entire conversion.

[timw0932]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

Interesting comment. What was the time difference with a single file conversion versus multiple file conversion from FLAC to ALAC for the multi-file conversion to complete? I'd be surprised if a single file conversion ended faster than multi simultaneous conversion. Ignore the throughput showing, but focus on the actual time to complete the entire conversion.

It's actually what you would expect if there were multiple threads each trying to do independent I/O simultaneously to the same disk in an uncoordinated way. The "x-numbers" I quoted correspond (inversely) to the total times; I wasn't just watching the number decrease and thinking that was bad in and of itself. It was impatience at the total time it was taking that made me look at this more deeply.

I no longer have the FLAC source files from this afternoon, but I just did a test converting ALAC->FLAC for 16 ALAC files ranging from 135-230 MB, 2.71 GB total, which is basically the reverse of what I was doing earlier today. I did the tests in the order listed, so in the unlikely case there was any caching going on by my 4GB Windows 7 x64 system, the 2 and 4 CPU trials would have been the ones to benefit:

16 Files, 135-230 MB in size, 2.71 GB total, median 178 MB, all defragmented according to Sysinternals contig -a. Source and target drive are the same, a dedicated data drive with no other concurrent activity during the test, also hosting the %temp% folder, WD20EARS Green Drive (2 TB in size, with about 800 GB free), using Intel Rapid Storage 9.6.0.1014 driver and AHCI. PC is Asus P7P55D Pro, i5 750 with 4 GB RAM, Windows 7 x64. ALAC->FLAC with dbpa r14:

1 CPU:
Time to completion: 5:57 (minutes:seconds)
Final throughput: 77x
Disk active time: 10-15% steady
CPU usage: 25-30% steady

2 CPU:
Time to completion: 5:33
Final throughput: 84x
Disk active time: 10-100%, with extended periods of 100%
CPU usage: 5-50%, maybe 30% average?

4 CPU:
Time to completion: 8:35
Final throughput: 54x
Disk active time: 10-100%, essentially 100% the whole time
CPU usage: 5-90%, perhaps 20% average if I'm being generous

The "Disk active time" and "CPU usage" were obtained using the Windows 7 Resource Monitor. As you can see, even two CPUs is basically a wash, and 4 CPUs is quite actively bad, taking almost 3 minutes longer than the single CPU trial, or 44% longer to finish. Certainly, the hard drive may be a factor; other hard drives might do better, but I'm not going to install a 7200 RPM drive to test it. I would expect a 7200 RPM drive to be faster overall with some smallish improvement to the performance degradation.

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

I did a quick batch conversion test, and I did see a single file batch conversion did outperform simultaneous conversions only when converting three extremely large files. I had three WAV files of 2,401,861,676 byte each. When I batch converted all three simultaneously, it took 7 minutes and 14 seconds to complete. When I batch converted one file at a time, it took 4 minutes and 50 seconds to complete. I've only seen this slow down with huge gigabyte files.

Notice though, that I was able to force a single file conversion versus simultaneous conversion. I'm not sure what this wish is for exactly. Faster hardware? I have a WD Raptor drive where I performed this test. Also, I rebooted Windows after each batch conversion test to eliminate caching (my machine has 16 gigs). I imagine my results would differ if I ran this test against SSD drives...

So, in the event I have to batch convert gigabyte files, I could always force one at a time file conversions.

[timw0932]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

I did a quick batch conversion test, and I did see a single file batch conversion did outperform simultaneous conversions only when converting three extremely large files. I had three WAV files of 2,401,861,676 byte each. When I batch converted all three simultaneously, it took 7 minutes and 14 seconds to complete. When I batch converted one file at a time, it took 4 minutes and 50 seconds to complete. I've only seen this slow down with huge gigabyte files.

You should try it with a large number of 200 MB files as I described.

Notice though, that I was able to force a single file conversion versus simultaneous conversion. I'm not sure what this wish is for exactly. Faster hardware? I have a WD Raptor drive where I performed this test. Also, I rebooted Windows after each batch conversion test to eliminate caching (my machine has 16 gigs). I imagine my results would differ if I ran this test against SSD drives...

I think that's a pretty safe bet. Be sure to let me know when I can buy a 2 TB SSD for $79.

NB: I have no idea what effect (if any) your 16 GB of RAM (4x the memory) would have on the test I described.

So, in the event I have to batch convert gigabyte files, I could always force one at a time file conversions.

As I reported in great detail, the issue is not confined to gigabyte files. It affects much smaller files I commonly encounter. I don't know that it's possible for the use of multiple CPUs to speed up the encoding when so much I/O has to be performed. The "wish", first and foremost, is for it never to hurt. I shouldn't have to examine the files that I'm going to convert and guess whether or not any large files are going to cause dbpa to thrash the hard drive for long periods of time and then adjust the multiple CPU settings on a conversion-by-conversion basis. I think this is very possible to accomplish, even if the architecture amounts to each thread running its own independent instance of flac.exe. A master controlling thread could monitor the CPU and disk utilization of the converter threads, and it would avoid starting new threads when one or more is heavily I/O bound. It would also try to avoid creating the bad situation in the first place and not start multiple threads that will collectively read and write gigabytes of data in effectively a random access pattern for the duration of their runtime. The current approach is like a worst case disk benchmark.

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

I get what you're suggesting. It's not that simple, unfortunately. If Spoon was to make performance changes based on hardware assumptions, we might end up with another case of limiting conversions to WAV at one file at a time. The problem is that this does not improve performance in all cases, but it's hard-coded anyway! You may have seen some of the previous tests I had done on this and requests that he revisit this. My test were on medium sized files, but I've shown a large improvement in multi-file conversion.

You'll be able to get SSD drives at a nice price given time. When you do get these drives, will changes to multi-file logic hurt or improve performance? (rhetorical question :-) Logic could certainly be added to dbpoweramp that adds smarts to it to determine when simultaneous conversions should be used and not. I would think this is outside the scope of audio processing though. I would prefer if Spoon focused on audio processing and integrity.

As for my memory used for cache, if I had not rebooted, Windows should not have read from disk again. The WAV files (that total less than 8GB) would all resided in memory. It would not have been a valid test had I not rebooted.

[timw0932]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

I get what you're suggesting. It's not that simple, unfortunately. If Spoon was to make performance changes based on hardware assumptions

Please read what I wrote carefully and ask questions if you don't understand. I did not suggest improving this was "simple", and I did not suggest making "hardware assumptions". I was not suggesting replacing one suboptimal approach to multiprocessing with another. I was suggesting doing something a little more sophisticated than simply starting 4 instances of flac.exe and letting them fight it out, which appears to be what the current approach amounts to. (NB: At this point, I feel I need to emphasize I'm not claiming that's what the current approach IS, just that it behaves in a similar way.)

As for my memory used for cache, if I had not rebooted, Windows should not have read from disk again. The WAV files (that total less than 8GB) would all resided in memory. It would not have been a valid test had I not rebooted.

What I was getting at WRT your system with 4x the memory is that I don't know if the I/O pattern and strategy might be different if you were to perform a test like I conducted when everything you're doing can easily fit into RAM without displacing anything else. It's something you need to consider in order to compare apples to apples. Also, rebooting doesn't necessarily help your situation if you haven't disabled StupidFetch, which in Vista at least would happily preload large audio and video files. I don't know if they fixed that behavior in Windows 7 or not. I don't think you said what version of Windows you're using anyway. Point is, there are potentially lots of things to account for.

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

Fair enough. As long as the developer is aware of exaclty what you were requesting, because I was not until I all these additional responses.

No one typically responds to these items. Unless what you are requesting is crystal clear, what you're looking for most likely would not get implemented. Otherwise, we might end up with exacly what I had posted (hard-coded to limit a single file conversion). Your initial post really did not go into this detail at all...

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

BTW, I am running 64-bit Windows 7. My testing took over four minutes for the fastest conversion. Even if flac.exe is being used and exists in prefetch, do you really think that milliseconds of an executable loading from disk will make a difference? As compared to gigabytes of data that will reside in memory and will be read from cache significantly faster than being reread from disk.

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

Rebooting to clear cache makes a major difference. If you did not reboot after your initial conversion, your test was invalid (as I stated above).

I just re-executed this test without rebooting this time. I still have the same three large WAV files on my hard drive.

Conversion from WAV to FLAC using best compression--

Single file conversion: 12 minutes and 38 seconds
Simultaneous file conversion: 7 minutes and 46 seconds

Multi-file won this time.

[timw0932]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

BTW, I am running 64-bit Windows 7. My testing took over four minutes for the fastest conversion. Even if flac.exe is being used and exists in prefetch, do you really think that milliseconds of an executable loading from disk will make a difference? As compared to gigabytes of data that will reside in memory and will be read from cache significantly faster than being reread from disk.

Please re-read what I wrote about StupidFetch. I couldn't have been more clear, yet you have again managed to misinterpret what I said to imply I'm concerned about something as negligible as flac.exe loading times. That's the common theme in this thread, and I'm really tired of dealing with it. I won't be dealing with it anymore. No matter how little you may understand the subject of this thread, I really do believe my first post was sufficient to describe the problem to someone familiar with multiprocessing issues, which I assume the actual developer is. If not, he should be the one asking for clarification. I didn't come here to get into a lengthy discussion with someone who isn't responsible for the software, who was unaware that more simultaneous conversions doesn't necessarily translate into better performance, repeatedly misunderstands clear statements, tries to put words into my mouth that couldn't be further from what I'm talking about, and complains I'm not being clear (when I am).

[Jamil]

Re: Multiple CPU -> Maximize Throughput (Music Converter)

I had performed this additional test based on your response in regards to Windows prefetch. Media data have no relation to Windows prefetch, and it has not been disabled on my system. Additionally, I posted in regards to what it actually does -- that is it prefetches executable code.

What is interesting is that my last test on this showed that simultaneous batch conversion performed faster than a single file conversion.

This actually interests me, which is why I post. You do not have to continue the thread, if you do not wish...