From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Paul Lalonde Subject: Re: [9fans] GCC/G++: some stress testing Date: Sun, 2 Mar 2008 08:21:25 -0800 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 6c20b6fe-ead3-11e9-9d60-3106f5b1d025 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2008, at 3:12 AM, Charles Forsyth wrote: > C++ is probably the wrong language for the application, then; > it should appear straightforward. Almost certainly. And so is C. Programming many-core shared-cache machines in languages with global state and aliasing is just plain wrong, in the same way that programming in assembly instead of C is wrong. Add a highly heterogeneous real-time task mix on top of that, and you're in for a world of poor cache performance and deadlocks, which could be avoided by better choices of implementation language. One of the interesting things about copy-on-write no-aliasing languages is that the overhead they used to represent is quickly starting to disappear in the gaps between cache misses. It's amazing how much bookkeeping you can handle while waiting a thousand cycles for some memory to become local; the no-aliasing rules even make that kind of scheduling possible through a good match against the cache model. Programming for the memory hierarchy is way more important than optimizing CPU clocks anymore (though that winds up still having a place in some compute kernels). I wish our programming languages reflected that change in perspective. Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFHytQGpJeHo/Fbu1wRAhepAKCzjr3LIMoDK/RfaG1cVCHXguLdpQCbBS8I r8XFPG2F/vn2cWtHkQoss6c= =+7dG -----END PGP SIGNATURE-----