<?xml version="1.0" encoding="iso-8859-1"?><!-- generator="b2evolution/2.4.5" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>Zack Medico - Latest comments on Portage now supports building multiple packages in parallel</title>
		<link>http://blogs.gentoo.org/zmedico?disp=comments</link>
		<description></description>
		<language>en-US</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=2.4.5"/>
		<ttl>60</ttl>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Thu, 14 Aug 2008 05:30:37 +0000</pubDate>
			<dc:creator>Zac MEDICO [Member]</dc:creator>
			<guid isPermaLink="false">c19945@http://blogs.gentoo.org/</guid>
			<description>&lt;blockquote&gt;We might consider implementing more aggressive parallelization algorithms in the future.&lt;/blockquote&gt;&lt;br /&gt;
&lt;br /&gt;
Now I've found a way to make the parallelization algorithm more aggressive in some cases, without making the build order any less optimal. The patch is in svn &lt;a href=&quot;http://sources.gentoo.org/viewcvs.py/portage?view=rev&amp;amp;rev=11405&quot; rel=&quot;nofollow&quot;&gt;r11405&lt;/a&gt; and it will be included in &lt;a href=&quot;http://packages.gentoo.org/package/sys-apps/portage&quot; rel=&quot;nofollow&quot;&gt;&gt;=sys-apps/portage-2.2_rc9&lt;/a&gt;.&lt;br /&gt;
</description>
			<content:encoded><![CDATA[<blockquote>We might consider implementing more aggressive parallelization algorithms in the future.</blockquote><br />
<br />
Now I've found a way to make the parallelization algorithm more aggressive in some cases, without making the build order any less optimal. The patch is in svn <a href="http://sources.gentoo.org/viewcvs.py/portage?view=rev&amp;rev=11405" rel="nofollow">r11405</a> and it will be included in <a href="http://packages.gentoo.org/package/sys-apps/portage" rel="nofollow">>=sys-apps/portage-2.2_rc9</a>.<br />
]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19945</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Wed, 06 Aug 2008 22:32:19 +0000</pubDate>
			<dc:creator>Zac MEDICO [Member]</dc:creator>
			<guid isPermaLink="false">c19942@http://blogs.gentoo.org/</guid>
			<description>&lt;blockquote&gt;&lt;br /&gt;
a) after --resume, and&lt;br /&gt;
b) even after --keep-going resumes&lt;br /&gt;
since I do not see any parallel emerges anymore. :-(&lt;br /&gt;
&lt;br /&gt;
In fact, IIRC after --resume the compressed output of parallel emerges would not even appear, so the new options probably did not survive the restart.&lt;br /&gt;
&lt;/blockquote&gt;&lt;br /&gt;
&lt;br /&gt;
I can confirm that --resume does not properly preserve --jobs and --load-average options, so I will have that fixed in the next release (that will be 2.2_rc7).&lt;br /&gt;
&lt;br /&gt;
I suspect that the --keep-going behavior that you've observed is due to the topology of the dependency graph, and the following algorithm:&lt;br /&gt;
&lt;br /&gt;
&lt;blockquote&gt;The algorithm used to choose packages that will execute concurrently with other packages is as conservative as possible in the sense that a given package will not be executed if the subgraph composed of its direct and indirect dependencies contains any scheduled merges. By ensuring that the subgraph of deep dependencies is fully up to date in this way, potential problems are avoided which could be triggered by other build orders that are less optimal.&lt;/blockquote&gt;&lt;br /&gt;
&lt;br /&gt;
We might consider implementing more aggressive parallelization algorithms in the future. However, those who would consider choosing a more aggressive algorithm should ask themselves why they are in such a hurry. A more aggressive algorithm is inherently less optimal and therefore it only makes sense when there is some kind of deadline to meet. Even with a deadline, there are other techniques such as ccache and distcc which can help improve performance without sacrificing optimal build order.&lt;br /&gt;
&lt;br /&gt;
</description>
			<content:encoded><![CDATA[<blockquote><br />
a) after --resume, and<br />
b) even after --keep-going resumes<br />
since I do not see any parallel emerges anymore. :-(<br />
<br />
In fact, IIRC after --resume the compressed output of parallel emerges would not even appear, so the new options probably did not survive the restart.<br />
</blockquote><br />
<br />
I can confirm that --resume does not properly preserve --jobs and --load-average options, so I will have that fixed in the next release (that will be 2.2_rc7).<br />
<br />
I suspect that the --keep-going behavior that you've observed is due to the topology of the dependency graph, and the following algorithm:<br />
<br />
<blockquote>The algorithm used to choose packages that will execute concurrently with other packages is as conservative as possible in the sense that a given package will not be executed if the subgraph composed of its direct and indirect dependencies contains any scheduled merges. By ensuring that the subgraph of deep dependencies is fully up to date in this way, potential problems are avoided which could be triggered by other build orders that are less optimal.</blockquote><br />
<br />
We might consider implementing more aggressive parallelization algorithms in the future. However, those who would consider choosing a more aggressive algorithm should ask themselves why they are in such a hurry. A more aggressive algorithm is inherently less optimal and therefore it only makes sense when there is some kind of deadline to meet. Even with a deadline, there are other techniques such as ccache and distcc which can help improve performance without sacrificing optimal build order.<br />
<br />
]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19942</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Wed, 06 Aug 2008 13:06:36 +0000</pubDate>
			<dc:creator>Hans Meine [Visitor]</dc:creator>
			<guid isPermaLink="false">c19941@http://blogs.gentoo.org/</guid>
			<description>I have been using these great new features on a multi-core machine during the last days, but it seems that portage has problems &lt;br /&gt;
a) after --resume, and&lt;br /&gt;
b) even after --keep-going resumes&lt;br /&gt;
since I do not see any parallel emerges anymore. :-(&lt;br /&gt;
&lt;br /&gt;
In fact, IIRC after --resume the compressed output of parallel emerges would not even appear, so the new options probably did not survive the restart.&lt;br /&gt;
&lt;br /&gt;
But it's a great feature; in the past I have always tried to mimic that manually, but that would be a lot of work, far from perfect, and sometimes compile some common dependencies more than once if not done carefully.&lt;br /&gt;
&lt;br /&gt;
Thus, I am looking forward to see this feature become more mature.</description>
			<content:encoded><![CDATA[I have been using these great new features on a multi-core machine during the last days, but it seems that portage has problems <br />
a) after --resume, and<br />
b) even after --keep-going resumes<br />
since I do not see any parallel emerges anymore. :-(<br />
<br />
In fact, IIRC after --resume the compressed output of parallel emerges would not even appear, so the new options probably did not survive the restart.<br />
<br />
But it's a great feature; in the past I have always tried to mimic that manually, but that would be a lot of work, far from perfect, and sometimes compile some common dependencies more than once if not done carefully.<br />
<br />
Thus, I am looking forward to see this feature become more mature.]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19941</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Wed, 30 Jul 2008 13:13:01 +0000</pubDate>
			<dc:creator>gringo [Visitor]</dc:creator>
			<guid isPermaLink="false">c19926@http://blogs.gentoo.org/</guid>
			<description>&lt;blockquote&gt;Not having a lot of time and not having interest are two different things. We get lots of feature requests and the list is really quite long. Me might get to that eventually be there are lots of other things with higher priority at this time. Obviously we don't always have time to implement every person's request in a timely manner.&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;
&lt;br /&gt;
i know and obviously i don</description>
			<content:encoded><![CDATA[<blockquote>Not having a lot of time and not having interest are two different things. We get lots of feature requests and the list is really quite long. Me might get to that eventually be there are lots of other things with higher priority at this time. Obviously we don't always have time to implement every person's request in a timely manner.</blockquote><br /><br />
<br />
i know and obviously i don]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19926</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Wed, 30 Jul 2008 10:56:24 +0000</pubDate>
			<dc:creator>Zac MEDICO [Member]</dc:creator>
			<guid isPermaLink="false">c19924@http://blogs.gentoo.org/</guid>
			<description>&lt;blockquote&gt;but my point is that if you schedule qt to build in parallel with other smaller package(s) and you build ooo once qt is done there will probably not be such big overload.&lt;/blockquote&gt;&lt;br /&gt;
&lt;br /&gt;
When the goal is to maximize the amount of work done in a given amount of time, it may be advantageous to have a slight over-abundance of jobs that are ready and waiting to execute as soon as the load average drops low enough for a new job to be scheduled.&lt;br /&gt;
&lt;br /&gt;
&lt;blockquote&gt;Sorry to see you have no interest in implementing a vcs underneath portage.&lt;/blockquote&gt;&lt;br /&gt;
&lt;br /&gt;
Not having a lot of time and not having interest are two different things. We get lots of &lt;a href=&quot;http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;amp;bug_status=ASSIGNED&amp;amp;bug_status=REOPENED&amp;amp;emailassigned_to1=1&amp;amp;emailtype1=exact&amp;amp;email1=dev-portage%40gentoo.org&quot; rel=&quot;nofollow&quot;&gt;feature requests&lt;/a&gt; and the list is really quite long. We might get to that eventually but there are lots of other things with higher priority at this time. Obviously we don't always have time to implement every person's request in a timely manner.</description>
			<content:encoded><![CDATA[<blockquote>but my point is that if you schedule qt to build in parallel with other smaller package(s) and you build ooo once qt is done there will probably not be such big overload.</blockquote><br />
<br />
When the goal is to maximize the amount of work done in a given amount of time, it may be advantageous to have a slight over-abundance of jobs that are ready and waiting to execute as soon as the load average drops low enough for a new job to be scheduled.<br />
<br />
<blockquote>Sorry to see you have no interest in implementing a vcs underneath portage.</blockquote><br />
<br />
Not having a lot of time and not having interest are two different things. We get lots of <a href="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=dev-portage%40gentoo.org" rel="nofollow">feature requests</a> and the list is really quite long. We might get to that eventually but there are lots of other things with higher priority at this time. Obviously we don't always have time to implement every person's request in a timely manner.]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19924</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Wed, 30 Jul 2008 08:13:52 +0000</pubDate>
			<dc:creator>gringo [Visitor]</dc:creator>
			<guid isPermaLink="false">c19923@http://blogs.gentoo.org/</guid>
			<description>&lt;blockquote&gt;&lt;br /&gt;&lt;br /&gt;
One of them is likely to cause the load average to increase to a point where additional jobs will not be scheduled. If for some reason they still happen to get scheduled simultaneously, having a --load-average setting in MAKEOPTS will cause make to react to the current load conditions and prevent your system from overloading itself too much.&lt;br /&gt;
&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;
&lt;br /&gt;
well, yes, but my point is that if you schedule qt to build in parallel with other smaller package(s) and you build ooo once qt is done there will probably not be such big overload.&lt;br /&gt;
&lt;br /&gt;
&lt;blockquote&gt;&lt;br /&gt;&lt;br /&gt;
[toolchain]&lt;br /&gt;
class = portage.sets.shell.CommandOutputSet&lt;br /&gt;
command = /usr/local/bin/toolchain-package-set.sh&lt;br /&gt;
&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;
&lt;br /&gt;
will try, thanks. &lt;br /&gt;
Don</description>
			<content:encoded><![CDATA[<blockquote><br /><br />
One of them is likely to cause the load average to increase to a point where additional jobs will not be scheduled. If for some reason they still happen to get scheduled simultaneously, having a --load-average setting in MAKEOPTS will cause make to react to the current load conditions and prevent your system from overloading itself too much.<br />
</blockquote><br /><br />
<br />
well, yes, but my point is that if you schedule qt to build in parallel with other smaller package(s) and you build ooo once qt is done there will probably not be such big overload.<br />
<br />
<blockquote><br /><br />
[toolchain]<br />
class = portage.sets.shell.CommandOutputSet<br />
command = /usr/local/bin/toolchain-package-set.sh<br />
</blockquote><br /><br />
<br />
will try, thanks. <br />
Don]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19923</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Wed, 30 Jul 2008 04:18:07 +0000</pubDate>
			<dc:creator>Zac MEDICO [Member]</dc:creator>
			<guid isPermaLink="false">c19922@http://blogs.gentoo.org/</guid>
			<description>&lt;blockquote&gt;I</description>
			<content:encoded><![CDATA[<blockquote>I]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19922</link>
		</item>
				<item>
			<title>In response to: Portage now supports building multiple packages in parallel</title>
			<pubDate>Tue, 29 Jul 2008 08:22:11 +0000</pubDate>
			<dc:creator>gringo [Visitor]</dc:creator>
			<guid isPermaLink="false">c19921@http://blogs.gentoo.org/</guid>
			<description>thanks for your input !&lt;br /&gt;
&lt;br /&gt;
1- ok, will check this, i was quite sure there was already such feature but didn</description>
			<content:encoded><![CDATA[thanks for your input !<br />
<br />
1- ok, will check this, i was quite sure there was already such feature but didn]]></content:encoded>
			<link>http://blogs.gentoo.org/zmedico/2008/07/23/portage_parallel_builds#c19921</link>
		</item>
			</channel>
</rss>
