From mboxrd@z Thu Jan  1 00:00:00 1970
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Sun, 17 Jul 2011 14:04:45 +0200
User-Agent: KMail/1.13.6 (Linux/3.0.0-rc4-l38+; KDE/4.5.5; x86_64; ; )
References: <0a7dc5268ce4dceb21ea20cdcc191693@terzarima.net>
	<20110717084411.95552B827@mail.bitblocks.com>
	<20110717100245.GA2352@polynum.com>
In-Reply-To: <20110717100245.GA2352@polynum.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201107171404.46042.dexen.devries@gmail.com>
Subject: Re: [9fans] NUMA
Topicbox-Message-UUID: 032d383a-ead7-11e9-9d60-3106f5b1d025

On Sunday 17 July 2011 12:02:45 tlaronde@polynum.com wrote:
> My woe is more that an optimization can say "this may improve speed (or
> may not, even slow down processing...)": OK. But an optimization
> that can break a program, that is an optimization whose correctness
> is not guaranteed, is something I can't understand why it is even
> proposed (since I fail to see why someone would be happy to have
> more rapidly an incorrect result, that can even not be said to be close
> to the correct one for some epsilon...).


optimizations make it more likely to trip over undefined behavior -- one that
`was-somehow-working' without it.


http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html


--
dexen deVries

> (...) I never use more than 800Mb of RAM. I am running Linux,
> a browser and a terminal.
rjbond3rd in http://news.ycombinator.com/item?id=2692529