Randy,

High nice work with HLA. Just 2 questions as it pertains to pattern matching.

I see that the UCR has some of the S*bol pattern matching features, but was wondering if you personally took it a step further and possibly implemented some HLA macros that might simulate S*bol.

Did you ever do some performance testing regarding the pattern matching using S*bol vs HLL/UCR. When does Disk IO negate the ASM advantage of speed compared to other languages.

Thanks,
Charlie
Posted on 2003-05-27 05:25:27 by C. Wardell

Randy,

High nice work with HLA. Just 2 questions as it pertains to pattern matching.

I see that the UCR has some of the S*bol pattern matching features, but was wondering if you personally took it a step further and possibly implemented some HLA macros that might simulate S*bol.

Did you ever do some performance testing regarding the pattern matching using S*bol vs HLL/UCR. When does Disk IO negate the ASM advantage of speed compared to other languages.

Thanks,
Charlie


HLA has the pattern matching library that does a *much* better job of "simulating" many of the SNOBOL statements than the UCR Stdlib did. In particular, the HLA pattern matching library does a much better job of backtracking the the UCR stdlib does.

The HLA Standard Library's "table" class does a real good job of simulating associative tables in S*bol (though the index is a string, not an arbitrary data type, see the next comment).

The big thing missing in HLA, with respect to better S*bol emulation, is dynamically typed objects. A "variant" type and supporting library routines is something I want to add someday, but there are higher priority things to take care of first. Adding a variant type would allow me to modify the tables module to use indexes other than strings to select a table entry.

As for performance comparisons, the HLA Standard Library has much better string processing functions, so that part will be faster. However, HLA's stdlib really supports backtracking (whereas the UCR stdlib had a half-hearted attempt, that didn't always work properly). As a result, I'd be surprised to find the HLA code runs faster (though it *is* correct, which is a plus!). I have not compared HLA's pattern matching routines against a HLL's, though I'd guess that HLA would be faster than SNOBOL (interpreted) but probably slower than Spitbol in some special cases; this is because a compiler like Spitbol can combine patterns at compile-time that HLA's macro implementation won't do.

As for disk I/O, my experience suggests that for most (well-written) code, assembly has about a 2:1 to 5:1 advantage over a decent C compiler (processing well-written C code). As long as the HLL file I/O library has a decent implementation (e.g., buffering or memory-mapped I/O), assembly won't improve things too much except for some special cases that a HLL standard library won't consider. The trick with file I/O in assembly is to make it as convenient to use as in a HLL (e.g., as the HLA stdlib does); it's not going to be a whole lot faster, so you may as well make it convenient.
Cheers,
Randy Hyde
Posted on 2003-05-27 12:27:31 by rhyde