From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] GCC/G++: some stress testing From: erik quanstrom Date: Sun, 2 Mar 2008 13:59:42 -0500 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 6c6d5d74-ead3-11e9-9d60-3106f5b1d025 > 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. i don't understand this argument. are you saying that csp doesn't work in c? or are you saying that csp has caching problems that some other languages solve? also, could you define what you mean by "shared cache" a bit more. would you consider an intel quad core cpu to be a "shared cache" machine, since the two l2 caches sit on the same fsb? > 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. what do you mean by "programming for the memory heirarchy"? - erik