<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" version="2.0">
  <channel>
    <title>MaplePrimes - comments on Post, Amdahl's Law</title>
    <link>http://www.mapleprimes.com/posts/35628-Amdahls-Law</link>
    <language>en-us</language>
    <copyright>2026 Maplesoft, A Division of Waterloo Maple Inc.</copyright>
    <generator>Maplesoft Document System</generator>
    <lastBuildDate>Wed, 10 Jun 2026 21:25:48 GMT</lastBuildDate>
    <pubDate>Wed, 10 Jun 2026 21:25:48 GMT</pubDate>
    <itunes:subtitle />
    <itunes:summary />
    <description>The latest comments added to the Post, Amdahl's Law</description>
    <image>
      <url>http://www.mapleprimes.com/images/mapleprimeswhite.jpg</url>
      <title>MaplePrimes - comments on Post, Amdahl's Law</title>
      <link>http://www.mapleprimes.com/posts/35628-Amdahls-Law</link>
    </image>
    <item>
      <title>Amdahl's law hurts</title>
      <link>http://www.mapleprimes.com/posts/35628-Amdahls-Law?ref=Feed:MaplePrimes:Amdahl's Law:Comments#comment44516</link>
      <itunes:summary>In general you can let n be the "real world" speedup of your parallel routine.  Amdahl's law really hurts.  In sequential programming you often think that a relatively cheap operation, like an extra linear pass through the data, doesn't matter.  The focus is entirely on complexity.  In parallel programming that's not good, because quite often you can't effectively parallelize operations that are linear time because of memory bottlenecks.  So you need to avoid them altogether or you'll get killed by Amdahl's law.</itunes:summary>
      <description>The latest comments added to the Post, Amdahl's Law</description>
      <guid>44516</guid>
      <pubDate>Sat, 27 Feb 2010 13:15:35 Z</pubDate>
      <itunes:author>roman_pearce</itunes:author>
      <author>roman_pearce</author>
    </item>
  </channel>
</rss>