<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Rachels Lab Notes &#187; Language</title>
	<atom:link href="http://www.rachelslabnotes.com/category/language/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rachelslabnotes.com</link>
	<description>Game Development as seen through the Blum Filter</description>
	<lastBuildDate>Thu, 17 Dec 2009 03:10:36 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>The hidden cost of C++</title>
		<link>http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/</link>
		<comments>http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/#comments</comments>
		<pubDate>Tue, 20 Oct 2009 14:04:23 +0000</pubDate>
		<dc:creator>groby</dc:creator>
				<category><![CDATA[Language]]></category>

		<guid isPermaLink="false">http://www.rachelslabnotes.com/?p=20</guid>
		<description><![CDATA[As a game developer, I&#8217;m concerned with performance. Yes, we&#8217;re living in next-gen land, and there&#8217;s a lot of performance &#8211; but then somebody comes along and squeezes every last drop out of a platform you develop for, and you better do that too.

As such, I&#8217;m occasionally involved in discussions about the merits of using [...]]]></description>
			<content:encoded><![CDATA[<p>As a game developer, I&#8217;m concerned with performance. Yes, we&#8217;re living in next-gen land, and there&#8217;s a lot of performance &#8211; but then somebody comes along and squeezes every last drop out of a platform you develop for, and you better do that too.</p>

<p>As such, I&#8217;m occasionally involved in discussions about the merits of using C++. As such, one topic that comes up in every single discussion is the &#8216;hidden cost&#8217; of using C++. And the reply is inevitably &#8220;There&#8217;s no such thing! It&#8217;s all in the source code!&#8221;</p>

<p>Well, yes, it is. But let me explain what I mean by it.</p>

<p>In C, if I have a line of code like this:</p>

<div class="dean_ch" style="white-space: wrap;"><ol><li class="li1"><div class="de1">a = func<span class="br0">&#40;</span>b,c<span class="br0">&#41;</span>;</div></li></ol></div>

<p>I can take a rough guess at the cost of the function by the name of it. The only other part I need to have a mental model of the performance is the overhead involved. And in C, the cost of a function call is pretty fixed. The only &#8217;surprise&#8217; that can happen is that it&#8217;s inline and thus faster than you expected.</p>

<p>Not so in C++. Is it a function call, a member function call, or is it an anonymous constructor? Are b and c implicitly invoking copy constructors for other classes as part of type coercion? Is that a normal assignment, or an assignment operator? Is there a cast operator involved?</p>

<p>And once I have answered those questions, I have to look at all the classes involved. If they have a non-empty destructor, cost is added. Should those destructors be virtual, more cost is added. Virtual cast operators? Add some more.</p>

<p>As the end result, your overhead can grow dramatically. Especially those virtual calls are quite costly. The total runtime of a loop can easily vary by 10x or more based on those parameters.</p>

<p>Of course, they are not really hidden &#8211; if I look at the source code, I can easily see them. The real hidden cost is that now, instead of looking at one piece of source &#8211; the function itself &#8211; I need to look at up to four different classes. Add possible ancestors to find out if a call is virtual.</p>

<p><em>That</em> is the hidden cost. The mental model for a simple function call became incredibly large and complex, and every function call is potentially as complex. Which makes reasoning about performance a rather hard thing to do.</p>

<p>Worse, it makes profiling harder than necessary. All the type coercions that happen at the API level will show up as separate functions, not attributed to the callee, but the caller.</p>

<p>All that translates ultimately into either worse performance or longer development time. Neither one is something you like to hear about.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/feed/</wfw:commentRss>
		<slash:comments>30</slash:comments>
		</item>
	</channel>
</rss>
