Re: System calls - GNAT library vs. direct bindings

[Pascal Obry <pascal@obry.net>]

anon a �crit :
> In <1180623520.303981.191090@q75g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
>> Hi,
>>
>> I would like to now your opinion about the two options in the subject.
>>
>> Let's suppose that the problem is a network-aware application on the
>> POSIX system. Ada doesn't know about network per RM, so we have to
>> look around for libraries.
>> One option is to use the GNAT library that has some package for
>> sockets.
>> Another is to write thin wrappers that bind directly to relevant
>> system calls (socket, connect, read, write, close, bind, listen,
>> accept, select - that's it for the basic stuff).
>>
>> 1. The advantage of using GNAT library is portability across various
>> systems that are targeted by GNAT. (I assume that the GNAT library is
>> available outside of POSIX - if not, please correct me.)
>>
>> 2. The advantage of writing custom thin wrappers is portability across
>> various compilers that target POSIX platforms.
>>
>> The first is not really important for me, I will probably use only
>> POSIX systems.
> 
> One factor is that Ada was designed for portability there if you do not care 
> about portability then do not use Ada!
> 
>> The seconds is not important neither, I will probably use only GNAT.
> 
> Wrappers defeat the purpose of use Ada, so do not use them!
> 
>> In other words - the focus for evaluation should go elsewhere.
>> Performance? Maintainability? Some other factors?
> 
> 
> Performance -- use the OS's core language. Which normally means 
> using C instead of writing code in Ada or using Wrappers.  But as the 
> performance of the code goes up the maintainability starts to drop. 
> This is due to the fact that performance alorithms are normally tied to 
> the hardware and as hardware is update the alorithms may need to be 
> rewritten just to maintain current performance levels which increases 
> the maintainability cost.

That's nonsense! An intern project comparing the "same" application
built with OpenMP/C++ and Ada shows that we have the same level of
performances. Ada is slightly better in fact. This is not one-to-one
kind of comparison as we wanted to use both technology as it should. So
in OpenMP/C++ we have parallel loops on the Ada side we have designed a
pipeline of tasks. The Ada architecture is then higher level, but gives
slightly better performances.

I'm fighting days after days the idea than low-level gives better
performances. This is just plain wrong. It has probably be true at some
point with tailored assembly applications. This is just not possible
those days as processors are so complex than only a compiler can
schedule the instruction properly. So no, C based languages, as
low-level as they seems, are not necessary faster.

Today discussion was about the C ternary operator being faster than a
standard if. The gain is three CPU cycles (well that's what the guy was
arguing). Who cares ? Especially when the algorithm is just a mess of
non optimal code :( How often people get swamped by low-level stuff
amaze me !

Now please this is ONE bench. It just shows that at least low level does
not necessary means faster, that's all. I have not said that Ada is
always faster right :)

Last but not least Mister Anon, it is polite on the Net to sign messages.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595