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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!p73g2000hsd.googlegroups.com!not-for-mail From: Maciej Sobczak 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 06:29:56 -0700 (PDT) Organization: http://groups.google.com Message-ID: <964528ba-8e63-49b7-8189-5aa744f9a7ff@p73g2000hsd.googlegroups.com> 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> NNTP-Posting-Host: 85.3.114.215 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205587797 20028 127.0.0.1 (15 Mar 2008 13:29:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 15 Mar 2008 13:29:57 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: p73g2000hsd.googlegroups.com; posting-host=85.3.114.215; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; 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:20418 Date: 2008-03-15T06:29:56-07:00 List-Id: 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. > 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 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. > 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