<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Cargo-Culted Optimisations</title>
	<link>http://www.hexten.net/2008/01/04/cargo-culted-optimisations</link>
	<description>Better than Slashdot</description>
	<pubDate>Sat, 17 May 2008 15:46:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Andy</title>
		<link>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-40289</link>
		<pubDate>Fri, 22 Feb 2008 14:02:54 +0000</pubDate>
		<guid>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-40289</guid>
					<description>Yeah, but my point was that exceptions don't ordinarily involve any UM/KM transitions. It only (apparently) affects certain languages that run on CLR and use Microsoft's structured exceptions. So it's a mistake to perpetuate the idea that exceptions are slow based on one specific implementation.

CLR Structured Exceptions are slow. Exceptions in general are not.</description>
		<content:encoded><![CDATA[<p>Yeah, but my point was that exceptions don&#8217;t ordinarily involve any UM/KM transitions. It only (apparently) affects certain languages that run on CLR and use Microsoft&#8217;s structured exceptions. So it&#8217;s a mistake to perpetuate the idea that exceptions are slow based on one specific implementation.</p>
<p>CLR Structured Exceptions are slow. Exceptions in general are not.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: piers</title>
		<link>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-40288</link>
		<pubDate>Fri, 22 Feb 2008 14:02:44 +0000</pubDate>
		<guid>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-40288</guid>
					<description>&#62; we replace could that admittedly *should* work

we replace code - not "could" - dog lobber.</description>
		<content:encoded><![CDATA[<p>&gt; we replace could that admittedly *should* work</p>
<p>we replace code - not &#8220;could&#8221; - dog lobber.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: piers</title>
		<link>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-40287</link>
		<pubDate>Fri, 22 Feb 2008 13:59:48 +0000</pubDate>
		<guid>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-40287</guid>
					<description>if you're developing an app to be multi-platform you have to take into account the lowest common denominator. if UM/KM transitions are known to be costly on one platform it makes sense to minimise those from the outset - especially if there's a large installed base. that isn't cargo culting - that's recognising that something's a bit crap and accepting that there are potential consequences on other platforms.

i code in VHDL for hardware logic synthesis. there are many features of the language that would be great to use, but i have to use a restricted subset as experience with various customers' various tools all at various patch levels has taught me to keep things simple. this can lead to inelegance in coding style, but it's safe and reduces support costs. occasionally, someone tries to show how clever they are in their coding and we don't find out until quite a way into the customer's tool flow. we replace could that admittedly *should* work with clunky stuff and hey presto we can close the ticket.

the line between adherence to coding style guidelines and cargo culting can be thin in places.</description>
		<content:encoded><![CDATA[<p>if you&#8217;re developing an app to be multi-platform you have to take into account the lowest common denominator. if UM/KM transitions are known to be costly on one platform it makes sense to minimise those from the outset - especially if there&#8217;s a large installed base. that isn&#8217;t cargo culting - that&#8217;s recognising that something&#8217;s a bit crap and accepting that there are potential consequences on other platforms.</p>
<p>i code in VHDL for hardware logic synthesis. there are many features of the language that would be great to use, but i have to use a restricted subset as experience with various customers&#8217; various tools all at various patch levels has taught me to keep things simple. this can lead to inelegance in coding style, but it&#8217;s safe and reduces support costs. occasionally, someone tries to show how clever they are in their coding and we don&#8217;t find out until quite a way into the customer&#8217;s tool flow. we replace could that admittedly *should* work with clunky stuff and hey presto we can close the ticket.</p>
<p>the line between adherence to coding style guidelines and cargo culting can be thin in places.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Nick</title>
		<link>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-34435</link>
		<pubDate>Mon, 07 Jan 2008 09:33:02 +0000</pubDate>
		<guid>http://www.hexten.net/2008/01/04/cargo-culted-optimisations#comment-34435</guid>
					<description>It's amazing how many design decisions are made without people measuring stuff. That's why I was tasked to wite 29,000 lines of C last summer that *made no difference at all*. Still, I enjoyed the job purely for it's interest value.</description>
		<content:encoded><![CDATA[<p>It&#8217;s amazing how many design decisions are made without people measuring stuff. That&#8217;s why I was tasked to wite 29,000 lines of C last summer that *made no difference at all*. Still, I enjoyed the job purely for it&#8217;s interest value.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
