From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e0e1d3b3f7c994b8 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!v3g2000hsc.googlegroups.com!not-for-mail From: gpriv@axonx.com Newsgroups: comp.lang.ada Subject: Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! Date: Sat, 15 Mar 2008 09:09:27 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <13t4b2kkjem20f3@corp.supernews.com> <33557da4-e4ba-4c75-9a55-4b7eb5fdad3b@i12g2000prf.googlegroups.com> <44104211-afd5-4cf7-8467-90471d4afd1b@f63g2000hsf.googlegroups.com> <2c2989ba-a109-40d6-b0a3-f91d94a2d291@a1g2000hsb.googlegroups.com> <9e12a297-599c-48e5-a5f9-5d6dee70e8dc@59g2000hsb.googlegroups.com> <4bf50326-6ebf-455d-b54f-e1e75f265f50@d62g2000hsf.googlegroups.com> <97488937-7c9d-433b-9871-2e6fd0663073@2g2000hsn.googlegroups.com> <964528ba-8e63-49b7-8189-5aa744f9a7ff@p73g2000hsd.googlegroups.com> NNTP-Posting-Host: 151.196.71.114 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205597368 6529 127.0.0.1 (15 Mar 2008 16:09:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 15 Mar 2008 16:09:28 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v3g2000hsc.googlegroups.com; posting-host=151.196.71.114; posting-account=YaY8rAoAAAAAnFXOECY3BGVJsrvFJCgy User-Agent: G2/1.0 X-HTTP-Via: 1.1 SPARKS X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20419 Date: 2008-03-15T09:09:27-07:00 List-Id: On Mar 15, 9:29 am, Maciej Sobczak wrote: > On 15 Mar, 03:29, gp...@axonx.com wrote: > > > IMHO it should not be keeping compiler designers from flushing the > > contents of the registers down to lowest level > > Do you know that it can cost you two orders of magnitude of > performance loss? > > > Performance penalties should not be a cover for not > > doing this. > > On the contrary. Otherwise it would make no sense to introduce > multicore architectures at all. Performance is an issue in less than 1% of our code. You may be in different application though (however I doubt your numbers will be that different) We usually locate this 1 % and concentrate on it still remaining well within the standard. You must be a total idiot to use volatile there or allow context switches. > > > What also seems to be alarming is proliferation of > > architecture specificity into the programming techniques. > > No, there is no specificity. I have an impression that you still try > to keep the volatile mess and then declare that the platform specifity Your impression is totally wrong. My use of volatile may went 2-3 time within 50KLOC program. And as you may notice I don't use C++ in preemtive environment any longer so issue is over. > breaks your code, but the truth is totally inverse - you have broken > code, period. That's it - don't expect compiler vendors to "fix the > world" and penalize those who do things correctly. > If you write correct code (yes, forget once and for all the volatile > keyword), there is absolutely no architecture specificity to worry > about. > > > What will happen when architecture change? > > Nothing. Correct programs will still work and broken programs will > still be broken. It's harder to formulate correctness that's all > > > C started as a language for very simple microprocessor architecture > > language. Now architectures outgrew what the language was originally > > designed for. > > No, you can still target modern architectures with this "outdated" > language. Just do it right. Interestingly, this also applies to Ada > (wow! I've managed to keep the discussion on-topic! ;-) ). > > > Practitioners are simply patching things up trying to > > make 12-year's old pants to fit on 16-years old boy. > > Yes, you are unfortunately right here. Practitioners have to worry > about truckloads of broken code. > > -- > Maciej Sobczak *www.msobczak.com*www.inspirel.com