Hi! > > Again, it's a dependency tree. You can not parallelize more > > than a certain number, because nodes would have to wait for other nodes > > to finish before they can work. So one has to reduce > > the dependencies and shorten the longest path.
> I do not see in void's wording anything indicating that the unit of work > would be a builder run of one port-package-build. Yes. But if you have 10000 cores of the same GHz Rating as one fast box with only, let's say, 128 cores. If you want to measure from the first to the last package, the way to shorten the total build time is to analyse and optimize the longest path in the dependency tree. Yes, distributing it to more cores might even shorten the total build time, but if the GHz rating per core is not higher, then the longest build path in the dependency tree will still dominate the build. Will 10000 cores build faster than 100 cores ? Yes, but not 100 times as much. Probably only 50% faster or so. Therefore, trying to parallelize the ports tree build time is a worthy endeavour, but the wins (cost/benefit-ratio) might be much lower than expected. >From what I understand, calculating that time is experimental science, because pre-calculating it from the ports tree without building it looks difficult. > He may well be > allowing for make-job or process level distribution or the like. There > is no suggestion of any detailed specifics for the unit of work involved. > > I'm not saying that any such is readily practical. Just the security > issues around executable code being involved in the kind of results > generated by uncontrolled systems lead to a more general blocking issue > as far as I can tell. > > folding@home just does not have such security issues. And it does not have those dependencies, where one result depends on earlier other results. Therefore, it's much easier to parallelize. -- [email protected] +49 171 3101372 Now what ?
