At 11:15 Uhr -0400 24.10.2002, Jason Deraleau wrote:
This is possible, but the task of splitting up the builds on two process is non-trivial, in fact determining the order in which both processes should build stuff is NP-complete I think (i.e. increasing exponentially with the number of packages involved). Of course one could implement an ad-hoc resolve that attempts to simply saturate two build queues. But then it would still have to decide which things can be built in parallel, which still requires elaborate algorithms. Also a control logic has to be built into the main process to control the build process. Furthermore design decisions have to be made as to what to do if onf of the build procecss fails - should Fink abort everything, or just go on with the "rest" (for which of course it has to take into account that one package failed to build, so anything that depends on it can't be built either).I just got a dual proc box (only G4/450s, not one of the 1.25GHz :( and I'm wondering if there's a way to have Fink make use of both processors while compiling. It seems that while Fink is compiling something, I still have about 50% of my CPUs idle, or, one processor. I'm wondering if anyone has a patch for something like that. And I actually have a bit of an idea for it.I know that right before Fink compiles an application it checks all of the dependencies for it. I'm then presented with a list telling me what will be compiled and installed. What if Fink took this list and divided it by the number of processors in the system? For example, if I'm installing xfree86-rootless and it determines that I need 24 packages, why not break up the package list and compile two packages at once? Are dependencies required at compile time or only at runtime? Even if it's compile time I'm sure there is a way to do this that is quicker.
So yes it's possible, but it falls into the category: very complex, very hard. Needs somebody with a lot of time and experience to first design the things then implement it.
That said, it's a worthy goal and would also be useful for single processor machines - if one package fails, Fink could still go on and build the rest (or the subset of the rest which is possible to build w/o the failed package).
If you want to volunteer, go ahead :-)
Cheers,
Max
--
-----------------------------------------------
Max Horn
Software Developer
email: <mailto:max@;quendi.de>
phone: (+49) 6151-494890
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
