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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-29 02:30:02 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!news.uni-stuttgart.de!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor Date: 29 Jan 2004 11:16:17 +0100 Organization: Sun Microsystems Message-ID: References: <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <_JSdna166JuxFo3dRVn-hg@comcast.com> <401115B7.5020205@noplace.com> <101bjm54k3rn8f0@corp.supernews.com> <101ghqq1bpk3m6e@corp.supernews.com> NNTP-Posting-Host: europa1.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1075371378 19386 129.159.113.161 (29 Jan 2004 10:16:18 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 29 Jan 2004 10:16:18 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:5031 Date: 2004-01-29T10:16:18+00:00 List-Id: "Randy Brukardt" writes: > "Warren W. Gay VE3WWG" wrote in message > news:a%ARb.52241$Kg6.386478@news20.bellglobal.com... > > Randy Brukardt wrote: > ... > > > What is the point of having that functionality? Any code depending on it > is > > > by definition not portable. > > > > Performance! > > > > Some platforms for instance support asynchronous I/O. > > Some with bugs, others not at all. If you are writing > > servers, that BTW are very performance sensitive, then > > if you can determine that asynch I/O works properly > > (and well) on a given platform, then you're going to > > use it! Anything less is inferior. > > Truly high-performance applications are by definition, not portable. The > parts that aren't high-performance might be sharable, but again, this is a > larger granularity than conditional compilation would be good for. Taking > your example, you need to use tasks to make asynch. I/O work. If you don't > have asynch. I/O, you probably don't want the tasks, either (because they > have a substantial overhead in most cases), especially as the I/O may very > well block all of the tasks. So large parts of the code will need to be > different. You do not need tasks if you have asynchronous IO like the mechanisms available under POSIX, Solaris or Windows. You can use tasks with asynchronous IO of course, but you do not need them. If you do not have asynchroous IO you definitely want to use tasks, precisely because on many (most?) platforms doing IO from one task will not block other tasks. Usually you get better performance with async IO than with using tasks, because there usually will be more internal locks set in the OS, effectively stopping you from executing multiple IO operations in parallel as efficiently as with async IO. > > ... > > > What Claw does for features that aren't available on the current target > is > > > to raise Not_Supported_Error (which hopefully the caller can do > something > > > useful with, such as fall back to something that is supported). > > > > That will really help performance. Let's add some unnecessary > > exceptions! > > Different problem. We're trying to get the code to run unmodified on as many > targets as possible. Having it being self-adapting is very valuable in that > aim. (Hopefully, even the binarys can run on most targets unmodified.) > > Randy. > Yes, but he is trying to get the code to run unmodified on many platforms by making it adaptive at compile time. Same goal, different means. > > > -- C++: The power, elegance and simplicity of a hand grenade.