Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> 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.