![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
etb...the bad dream where you have to take OS again, but "it is what it is" (lolz).
Here is your pop quiz. I can't flunk you because I don't know the right answer.
Program P1 uses an external constraint solver. P1 can call it directly as a shared library "L2", or it can communicate with P2 via Unix pipes. P2 is a wrapper that presents an interactive ASCII-based interface to L2, so there's overhead of P1 constructing an ASCII command (typically only a few dozen characters), transmitting it, P2 parsing the command, P2 constructing a response (a few characters), transmitting the response, and P1 parsing the response. The former case requires only that P1 construct expressions and call functions in L2; in the latter case, P2 would construct those same expressions while parsing the command, and call the same functions in L2.
Under what (non-exotic) conditions would the clumsy, string-processing-ified pipes be faster than the shared library, and why?
(I know such non-exotic conditions exist because I just watched it happen.)
Here is your pop quiz. I can't flunk you because I don't know the right answer.
Program P1 uses an external constraint solver. P1 can call it directly as a shared library "L2", or it can communicate with P2 via Unix pipes. P2 is a wrapper that presents an interactive ASCII-based interface to L2, so there's overhead of P1 constructing an ASCII command (typically only a few dozen characters), transmitting it, P2 parsing the command, P2 constructing a response (a few characters), transmitting the response, and P1 parsing the response. The former case requires only that P1 construct expressions and call functions in L2; in the latter case, P2 would construct those same expressions while parsing the command, and call the same functions in L2.
Under what (non-exotic) conditions would the clumsy, string-processing-ified pipes be faster than the shared library, and why?
(I know such non-exotic conditions exist because I just watched it happen.)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-02-22 03:20 pm (UTC)Are the results consistently reproducible, or just a fluke? You're not measuring process time for P1, right, but wall-clock time? What about load time for the shared library? Does it get loaded the first time you call it, so that you get a performance hit upfront? How do you start P2? Do you take that startup time into account?
no subject
Date: 2007-02-22 04:02 pm (UTC)The results are reproducible. The results are the mean of 4, where each "trial" starts SML, loads the SML program (P1), calls the shared library (this is done to make sure the link really worked, for reasons I won't get into, but it should take care of loading stuff), and then starts the wall clock.
P2 is exec'd "cold" after the clock starts, so the time to start P2 is included in the time, but running P2 on an empty input takes <0.01s and the wall-clock times measured are several seconds, so that can't begin to explain the difference.
no subject
Date: 2007-02-22 04:36 pm (UTC)no subject
Date: 2007-02-22 05:07 pm (UTC)I think you're off in the weeds—I learned how to build expressions (for the interface to the shared library) by reading the wrapper code in P2. They say "plusExp(vc, e1, e2)" to build e1 + e2, I say "plusExp(vc, e1, e2)". It's all trivial; what's to optimize?
Let me specify further: on machines X and Y, the shared-library interface is as fast or faster (depending on the input to P1). On machine Z, the shared-library interface is the same or slower. In what way do you think machine Z differs from {X, Y}?
no subject
Date: 2007-02-22 05:29 pm (UTC)no subject
Date: 2007-02-22 06:42 pm (UTC)Is this where I say "brööööööl"?
no subject
Date: 2007-02-22 06:46 pm (UTC)You can say "brööööööl" or you could just tell me what you think is going on.
no subject
Date: 2007-02-22 07:07 pm (UTC)no subject
Date: 2007-02-22 07:34 pm (UTC)Or you have library version differences, or something is set up differently, or there is something broken with the way you are timing the run (the time command may not necessarily pick up the cycles used by the solver if it's in a separate process).
no subject
Date: 2007-02-22 08:02 pm (UTC)Only thing I can think of is that you're running on a multicore machine, so you're getting some interleaving and using more peak CPU horsepower than you otherwise might.
Yes, the machine where the separate process is faster has multiple CPUs. P1 makes hundreds of calls per second to the solver, so getting P2 on a separate CPU with its own cache could make quite a difference.