Issue #2 wontfix

Writing file on PowerPC system takes an age.

created an issue

Just compiled and tested this shiny new build on a PowerMac G4 (Dual 1.42GHz) and a Mac mini (Intel Core Duo 1.83GHz). Built on the G4, the universal binary runs, but takes FOREVER to tag a file (upwards of 15 minutes for a 287MB MP4). The same binary works perfectly on the Mac mini, completing the same file in a matter of seconds.

How can I help to troubleshoot this?

Comments (10)

  1. Wez Furlong repo owner

    If you build the binary on the mac mini, does it run faster on the powermac?

    What is the output of "file AtomicParsley"? This is what I see for the binary built on my macbook pro:

    % file AtomicParsley 
    AtomicParsley: Mach-O universal binary with 2 architectures
    AtomicParsley (for architecture i386):  Mach-O executable i386
    AtomicParsley (for architecture ppc7400):       Mach-O executable ppc

    is ppc7400 the most appropriate architecture to target for your powermac?

    Also, is the disk performance in the powermac "good"?

    How long does it take to copy the mp4 file to another file, and is that in the same ballpark as the time it takes for AtomicParsley to run?

  2. roobarb_ reporter

    Given this another try on an iMac G4 and have exactly the same problem. Compiled on the G4 and it's been tagging an 87MB MP4 for about 20 minutes now. Copying the file takes only a few seconds. The same UB on an Intel Core 2 Duo 2.4GHz iMac works perfectly - takes only a second or two to tag the file.

    The output of file AtomicParsley is (almost) exactly the same as your output:

    $ file ~/Downloads/atomicparsley/AtomicParsley 
    /Users/admin/Downloads/atomicparsley/AtomicParsley: Mach-O universal binary with 2 architectures
    /Users/admin/Downloads/atomicparsley/AtomicParsley (for architecture ppc7400):	Mach-O executable ppc
    /Users/admin/Downloads/atomicparsley/AtomicParsley (for architecture i386):	Mach-O executable i386

    The ppc7400 would certainly make sense for the powermacs I've been using, and disk performance of both G4s is perfectly good otherwise.

    Tried compiling on the Intel iMac and again the UB works perfectly, but copied to the G4 iMac the universal binary now produces this:

    $ ~/Desktop/AtomicParsley ~/Desktop/test.mp4 -t
    dyld: lazy symbol binding failed: Symbol not found: _fopen$UNIX2003
      Referenced from: /Users/admin/Desktop/AtomicParsley
      Expected in: /usr/lib/libSystem.B.dylib
    dyld: Symbol not found: _fopen$UNIX2003
      Referenced from: /Users/admin/Desktop/AtomicParsley
      Expected in: /usr/lib/libSystem.B.dylib
    Trace/BPT trap

    Hope that makes more sense to you than it does to me! :)

  3. Wez Furlong repo owner

    in src/parsley.cpp there's a bit of code that looks like this:

    uint32_t max_buffer =
    #ifdef __linux__
      0.5 /* splice() allows us to use less buffer space */

    you can try varying that "10" in the "else" part. My first suggestion is to look at making it smaller, say 0.5 instead of 10 and see how that goes.

    That max_buffer parameter controls the size of the buffer that is used internally for copying data; if you could experiment with making that smaller or larger and see if you can find a sweet spot, I can merge that in.

    You'll need to re-run make each time you change that value for it to take effect.

  4. roobarb_ reporter

    Had a play with that setting; tried a selection of values from 0.1 through to 50 (obviously doing a 'make clean' and 'make' after each)... nothing made any difference, I'm afraid. :(

    In fact, I'm not sure any setting I chose made it any worse either. But it didn't improve matters.

    Anything else you think I could try?

  5. Wez Furlong repo owner

    I can't think of anything else to try without the guidance of profiling tools.

    Are you in a position to try some runs under "Instruments" or "Shark"? (they ship with Xcode)

    I've never used either tool, so I can't provide much help, but the general approach is to run the "slow" application under the profiler and let it complete and the profiler will give you some diagnostic output. Roughly what you're looking for is the function or call stack that takes the most time to run.

  6. Anonymous

    I have a similar issue here, but it is not related to PowerPC, I am seeing this on an Intel Mac Pro. Attaching gdb reveals that all of the time is spent down inside the fread() function. Drilling even deeper, most of the time is spent in the kernel. I googled and found this:

    May be related, but no solution yet. Just wanted to post this here to share my findings.

  7. nabeards

    Hi Wez. Just wanted to update this that I had the same issue on a G4 Mac mini. Setting the value to 0.1 did make a difference in that the percentage updated much more frequently. It took about 2 hours to set tags on a 1.4 GB video, but I figured that's probably about right for that old of a processor.

  8. Log in to comment