Re: ada is getting spanked :(

[Georg Bauhaus <bauhaus@futureapps.de>]

On Sun, 2006-10-29 at 16:27 +0000, Björn Persson wrote:
> Georg Bauhaus wrote:
> > In order to optimize GNAT's standing, I have made a small
> > but quite effective change to one of Jim Rogers' programs
> > (regex-dna #2), the factor is 14 (fourteen).

The speed factor is now close to 18 :-). After some simplifications,
and after (I think) more closely reflecting the benchmark description.

http://home.arcor.de/bauhaus/Ada/

The program now also works more like the others (in my view).

> Ah, the one that uses Spitbol. Doesn't it really belong under 
> "interesting alternative programs"? The requirements clearly state that 
> regular expressions should be used.

The pattern strings in all programs all look regular to me,
including the GNAT.SPITBOL ones. But that doesn't mean
that the various programs' calls to RE routines such as
.findall, -all, m//g global subst(...) etc. imply "normal"
naive regular expression processing. So GNAT.SPITBOL is no
exception here. (In particular, I have left out obvious
standard SPITBOL improvements in order to reflect the benchmark
description.)
 I guess that the benchmark is also about how well an
implementation deals with just simple REs.

Anyway, I think that all of the RE, PCRE, and SPITBOL patterns
I've seen in many of the contributions reflect the spirit of the
benchmark, as is required (literally).
How could a notion of REs be both precise and precisely
applicable to the ways in which various PLs implement them?
 E.g. how can you turn off Boyer-Moore string searching when
one implementation has it, just so that only some specified
internal way of pattern matching is compared?

So my rule was: Simple patterns, no tricks.

> I fixed up the regex version some time ago and achieved a dramatic 
> improvement, but I didn't touch the Spitbol version. They were very 
> similar before that, and as I recall they had similar performance too.
> My changes are now in "regex-dna Ada 95 GNAT #3".

I did have a look at this program, however with program #3 as is
I keep getting segmentation faults due to the

  Sequence_Lines (1 .. 1_000_000) of type Unbounded_String.

ulimit -s 10000 didn't help, reducing the number of lines did.


regards,
Georg