Re: Ada Shootout program for K-Nucleotide (patches)

[Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>]

Isaac Gouy wrote:
> On Aug 4, 10:08 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
>> Isaac Gouy schrieb:
>>
>>
>>
>>> On Aug 4, 8:43 am, Isaac Gouy <igo...@yahoo.com> wrote:
>>>> On Aug 3, 1:29 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>>>>> Isaac Gouy <igo...@yahoo.com> writes:
>>>>>> On Aug 3, 5:36 am, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
>>>>>>> If we interpret this as the choice of the implementer, then there is
>>>>>>> no problem.  If the programs have to be able to read from stdin, then
>>>>>>> memory mapped files aren't of much use.
>>>>>> "read line-by-line a redirected FASTA format file from stdin"
>>>>>> http://shootout.alioth.debian.org/u32/benchmark.php?test=knucleotide&...
>>>>> What exactly does that mean?
>>>>> Would it be "cheating" to read all of stdin until reaching end-of-file,
>>>>> and then break the result up into lines (by whatever means)?
>>>> iirc the default buffer size for Java reader is 8192 bytes - use that.
>>> Better yet, the C++ programn seems to do just fine with this:
>>> char buffer[128];
>> But the more pressing question is, to me at least---others
>> will have better ideas---what functionality may we use for
>> reading, say, 128 char values?  Can we import OS functions?
>> Or the POSIX library? I have already install libflorist in
>> a new testing VM, in order to compare Text_IO agains POSIX
>> input.
> 
> 
> And was that an improvement?

Yes.

Using GNAT's binding to C streams improves running time
of fasta 25000000 from ~14s to ~10s on Ubuntu 9.04 64bit
running in VMware. ($ time ./fasta 25000000 > /dev/null)
The result is even more noticeable when either version's
output is redirected into a fresh (new) file on disk.
(~42s versus ~20s).
Using Florist should end up making similar calls,
so I expect similar improvements (TBD, soon).

The change is small (to fasta #1 as is):

1 - Add a small Print procedure that takes an Ada string,
copies it into a C string with \n and \0, and sends that
to fputs(3).

2 - Print then replaces every occurence of Text_IO.Put_Line

(I.e., even when building new strings from Ada strings for
the C functions the speedup seems quite noticeable.  There
are no occurrences of unchecked conversions or other high
speed techniques in the change (yet?).)

Might a change like this be acceptable?  (Obviously, fgets
could similarly be used when reading input in other programs.)

*** fasta.ada	old
--- fasta.ada	new
***************
*** 23 ****
! with Ada.Text_IO; use Ada.Text_IO;
--- 23,25 ----
! with Interfaces.C_Streams;  use Interfaces.C_Streams;
! with Interfaces.C;  use Interfaces.C;
! with Ada.IO_Exceptions;
***************
*** 74 ****
--- 77,84 ----
+    procedure Print (Item : String) is
+       Data : char_array renames To_C (Item & ASCII.LF);
+    begin
+       if fputs (Data'Address, stdout) < 0 then
+          raise Ada.IO_Exceptions.Device_Error;
+       end if;
+    end Print;
+
***************
*** 82 ****
!       Put_Line (">" & Id & ' ' & Desc);
--- 92 ----
!       Print (">" & Id & ' ' & Desc);
***************
*** 91 ****
!          Put_Line (Pick (1 .. M));
--- 101 ----
!          Print (Pick (1 .. M));
***************
*** 101 ****
!       Put_Line (">" & Id & ' ' & Desc);
--- 111 ----
!       Print (">" & Id & ' ' & Desc);
***************
*** 104 ****
!          Put_Line (S_App (K .. K + Integer'Min(Todo, Line_Length) - 1));
--- 114 ----
!          Print (S_App (K .. K + Integer'Min(Todo, Line_Length) - 1));