I converted a FLAC file to Apple Lossless. Max uses only 50% CPU load of one CPU (according to activity monitor). I have 120-140% load idling (in terms of one CPU). So Max here not even uses one CPU completely. Any idea why?
Edit: the used disk ransfer rates (about 4MB/s while converting) are far away from the disk performance, so this is not the limiting factor.
Dual 2GHz G5, 3GB Ram, OS 10.4.6, Max 0.5.6
FLAC to Apple Lossless CPU load
woody77. The later PowerMac G5's have Dual Core processors.
But I am 99% sure that the Dual 2.0GHz was available as Single Core as well, before they went Dual Core some 7-8 months ago.
If 'ye' have one of the later Dual Core G5's, then it explains why it dont use all the processing power. If not, then there might be other reasons.
But I am 99% sure that the Dual 2.0GHz was available as Single Core as well, before they went Dual Core some 7-8 months ago.
If 'ye' have one of the later Dual Core G5's, then it explains why it dont use all the processing power. If not, then there might be other reasons.
It is a machine with two single core CPUs.
Activity monitor reports:
Max:
%CPU: 66 (200% would be full load)
Threads: 6
overall System load: (here 100% is full load)
%User: 30.5
%System: 23.5
%Nice: 0
%idle: 46
If I run the same conversion twice, the Max CPU load goes slightly up to something like 75%.
Some other applications (Safari, Mail, Acrobat reader,....) were also running.
You see the percentage vary somewhat, also from my first post, but the symptom remains always.
It seems not possible to attach screen shots here, but I can mail these to illustrate, if someone wants to see them.
Activity monitor reports:
Max:
%CPU: 66 (200% would be full load)
Threads: 6
overall System load: (here 100% is full load)
%User: 30.5
%System: 23.5
%Nice: 0
%idle: 46
If I run the same conversion twice, the Max CPU load goes slightly up to something like 75%.
Some other applications (Safari, Mail, Acrobat reader,....) were also running.
You see the percentage vary somewhat, also from my first post, but the symptom remains always.
It seems not possible to attach screen shots here, but I can mail these to illustrate, if someone wants to see them.
I did some more experiments. The bottle neck could be the data transfer to the hard disk. The data transfer rate is O.K but there are a LOT of read/write operations per second (read >200/sec, write >800/sec).
In the second run of the same file I get, as noted above, a higher CPU load, nearly no read operations and about 1000 writes per second. So some cache effect I suppose.
The problem seems to be that there is a lot of read/write of TO SMALL files, hence driving the disk to its limits.
In the second run of the same file I get, as noted above, a higher CPU load, nearly no read operations and about 1000 writes per second. So some cache effect I suppose.
The problem seems to be that there is a lot of read/write of TO SMALL files, hence driving the disk to its limits.
This is interesting.
For the reads, I am using ExtAudioFileRead. I have no idea how the caching works internally.
For the writes, I am using ExtAudioFileWrite throughout Max. I will try to switch over to ExtAudioFileWriteAsync and see if that improves performance.
Edit: I tried using the async write, and the performance was essentially identical (10 vs. 11 seconds to encode as Apple Lossless). I think the benefits of using async writes would be greater on slower drives, though.
For the reads, I am using ExtAudioFileRead. I have no idea how the caching works internally.
For the writes, I am using ExtAudioFileWrite throughout Max. I will try to switch over to ExtAudioFileWriteAsync and see if that improves performance.
Edit: I tried using the async write, and the performance was essentially identical (10 vs. 11 seconds to encode as Apple Lossless). I think the benefits of using async writes would be greater on slower drives, though.
I'm using a Raid5 SATA disk array. Only for small transfer blocks I get low transfer rates in bench programs (at least: 7MB/s for 4 kbyte blocks, 15MB/s for 8 kbyte blocks and >36MB/s for 16 kbyte and above).
So the only possibility, I see, is that the data blocks transfered to the disk are 8 kByte or even smaller (perhaps wrong or un-buffered output ????).
So the only possibility, I see, is that the data blocks transfered to the disk are 8 kByte or even smaller (perhaps wrong or un-buffered output ????).
Max 0.6 update
With Max 0.6 the situation is somewhat different.
In phase I (converter) I now get nearly 100 % CPU and less write transactions (only about 300/s). This is an improvement, here I got only 60% CPU before.
In phase II (encoder) I still get <50% CPU, a transfer rate of 5MB/s at about 1300 reads/sec. This is evaluates, conspicuously enough, to transfer blocks of 4kB size.
P.S. perhaps I should mention I use a 280MB FLAC file (a complete CD) for the test.
In phase I (converter) I now get nearly 100 % CPU and less write transactions (only about 300/s). This is an improvement, here I got only 60% CPU before.
In phase II (encoder) I still get <50% CPU, a transfer rate of 5MB/s at about 1300 reads/sec. This is evaluates, conspicuously enough, to transfer blocks of 4kB size.
P.S. perhaps I should mention I use a 280MB FLAC file (a complete CD) for the test.
Who is online
Users browsing this forum: No registered users and 1 guest