FLAC I/O less efficient than STDIN, Direct file access can be almost twice slower than STDIN |
FLAC I/O less efficient than STDIN, Direct file access can be almost twice slower than STDIN |
Nov 26 2012, 18:26
Post
#1
|
|
![]() Group: Members Posts: 1066 Joined: 4-May 04 From: France Member No.: 13875 |
I was optimizing caudec when I came across this oddity. Basically, letting /usr/bin/flac access .flac files on a slowish HDD directly for decoding ('flac -d file.flac') was in one particular case almost twice slower than piping the files to /usr/bin/flac via STDIN ('cat file.flac | flac -d -').
I used a double album for testing, made of 37 tracks for a total of about 1 GiB, located on a HDD that tops out at about 70 MB/s. Incidentally, flac decodes on my machine at a similar rate. I ran caudec twice (figuratively - I repeated the tests many times) with 8 concurrent processes, for decoding those FLAC files to WAV on a ramdisk. I made sure to drop all caches between each run. First run was with direct file access, and completed in 40 seconds. Second run was with piping to STDIN, and completed in 25 seconds. The difference was much less pronounced, surprisingly, on a USB flash drive that tops out at 35 MB/s, 34 seconds vs. 30 seconds, and non-existant on a RAID 1 array that tops out at 130 MB/s and on a SSD that tops out at 500 MB/s. I experienced similar differences with WavPack. Does anyone have any idea of what's going on? -------------------- Save my friend from going homeless: http://outpost.fr/url/308w
|
|
|
|
![]() |
Nov 26 2012, 22:02
Post
#2
|
|
![]() Group: Members Posts: 512 Joined: 4-June 02 Member No.: 2220 |
Ok, I see that in your third paragraph. (Pardon my oversight, I posted right before a medical appointment so apparently I was distracted.)
If I read correctly: FLAC -d [HDD -> RAMdisk] = 40s FLAC STDIO [HDD -> RAMdisk] = 25s FLAC -d [flashdrive -> RAMdisk] = 34s FLAC STDIO [flashdrive -> RAMdisk] = 30s RAID = no tangible difference SSD = no tangible difference You mentioned WavPack having similar behavior so it doesn't seem the binary is the culprit either. I don't suppose using less concurrent threads would improve the performance of FLAC -d but it might be worth checking. It also is unclear how these threads are distributed but I wondered if multiple decode threads caused an unintended bottleneck (especially with fast-decoding formats). edit: I should also have mentioned I thought an instance of STDIO was limited to one thread per file, but this may be a bad assumption on my part. This post has been edited by Destroid: Nov 26 2012, 22:08 -------------------- "Something bothering you, Mister Spock?"
|
|
|
|
skamp FLAC I/O less efficient than STDIN Nov 26 2012, 18:26
phofman Running the reading and decoding processes in para... Nov 26 2012, 19:11
Destroid I would imagine reading and writing to the same me... Nov 26 2012, 20:19
skamp QUOTE (phofman @ Nov 26 2012, 19:11) Runn... Nov 26 2012, 20:59
skamp QUOTE (Destroid @ Nov 26 2012, 22:02) If ... Nov 26 2012, 22:22
greensdrive try using just one thread for cat and the same for... Nov 26 2012, 23:16
yourlord I tested this on my machine with mostly insignific... Nov 26 2012, 23:28
skamp QUOTE (yourlord @ Nov 26 2012, 23:28) I t... Nov 26 2012, 23:42
yourlord QUOTE (skamp @ Nov 26 2012, 17:42) You le... Nov 27 2012, 01:21
Axon QUOTE (yourlord @ Nov 26 2012, 18:21) The... Nov 27 2012, 01:43
Axon You might try `blockdev --setra 65536 --setfra... Nov 27 2012, 01:32
skamp QUOTE (Axon @ Nov 27 2012, 01:32) You mig... Nov 27 2012, 02:52
Axon OP might also try tuning the I/O scheduler; see e.... Nov 27 2012, 02:46
Axon Cool.
Note that --setra and --setra are completel... Nov 27 2012, 19:59
skamp QUOTE (Axon @ Nov 27 2012, 19:59) I'm... Nov 27 2012, 21:59
Axon QUOTE (skamp @ Nov 27 2012, 14:59) QUOTE ... Nov 28 2012, 01:20![]() ![]() |
|
Lo-Fi Version | Time is now: 25th May 2013 - 22:39 |