• Re: awkcc available, again

    From Ed Morton@mortonspam@gmail.com to comp.lang.awk on Tue Jan 11 16:35:40 2022
    From Newsgroup: comp.lang.awk

    On 1/11/2022 10:59 AM, Janis Papanagnou wrote:
    On 11.01.2022 15:05, Ed Morton wrote:

    Have you found much of a speed improvement after compiling the C version
    of the scripts that awkcc outputs? When I worked at AT&T in the 90s we
    used fairly large (1,000+ lines) awk scripts with nawk for some C code
    generation from a domain-specific language and tried using awkcc to let
    us compile our awk scripts to speed up the build process but didn't
    notice a difference.

    This observation astonishes me, I'd have expected at least *some*
    speed up for a compiled version, yet more so for the not too fast
    Nawk. - Is the generated code so bad?

    It's been about 30 years so I don't remember much about it other than
    that the generated code was pretty unreadable (which is not a problem as
    long as you don't have to read/modify it!) so we didn't bother trying to figure out if/where the issues were with it and instead just left the
    code as awk.

    Ed.


    Around 1999 there was the Awka Awk-compiler, and on it's web page[*]
    they have some performance data - not standard test cases, rather
    just measuring the runtime of Awk features - and that compiler works
    quite efficient, especially if compared to nawk (which incidentally
    was one of the tools used for comparison[**]).

    Janis

    [*] Still accessible: http://awka.sourceforge.net/compare.html

    [**] The used tools don't reflect the current tools' performance;
    at that time Gawk (for example) didn't use byte code, so current
    Gawk probably competes better than depicted in the these numbers.


    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From Janis Papanagnou@janis_papanagnou@hotmail.com to comp.lang.awk on Wed Jan 12 05:49:35 2022
    From Newsgroup: comp.lang.awk

    On 11.01.2022 18:37, Kaz Kylheku wrote:
    On 2022-01-11, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
    On 11.01.2022 15:05, Ed Morton wrote:

    Have you found much of a speed improvement after compiling the C version >>> of the scripts that awkcc outputs? When I worked at AT&T in the 90s we
    used fairly large (1,000+ lines) awk scripts with nawk for some C code
    generation from a domain-specific language and tried using awkcc to let
    us compile our awk scripts to speed up the build process but didn't
    notice a difference.

    This observation astonishes me, I'd have expected at least *some*
    speed up for a compiled version, yet more so for the not too fast
    Nawk. - Is the generated code so bad?

    If the Awk code is spending most of its time in the host
    implementation's run-time support code for input reading and field
    splitting, and the compiled Awk doesn't have that aspect well-optimized,
    it could end up slower.

    Yes, it was more a rhetorical question; I'd just expected that the core
    awk functions/code would be the first parts considered for optimization.
    With that in mind I'm wondering whether that would really be the reason
    in the case of awkcc. (Not that I'm too concerned about a tool that had
    been said to be "primarily of historical interest".)

    Janis

    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From arnold@arnold@skeeve.com (Aharon Robbins) to comp.lang.awk on Thu Jan 13 20:00:53 2022
    From Newsgroup: comp.lang.awk

    In article <srffnr$mbr$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
    On 09.01.2022 20:29, Aharon Robbins wrote:
    [...]
    https://github.com/nokia/awkcc.

    The code is primarily of historical interest; I think it would take
    a significant effort to build it on a more modern system, although I
    think it could be done.

    It compiles on my system with warnings but creates an awkcc executable.

    The strange thing is that calling it creates an error because it wants
    to run the awkcc.sh script (which is non-executable per default). It's,
    I think, the first time that I've seen such a design.

    What happens if you make awkcc.sh executable and put in your PATH?
    Do you end up being able to compile and awk program into C and
    then compile that and run it?

    Thanks,

    Arnold
    --
    Aharon (Arnold) Robbins arnold AT skeeve DOT com
    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From Janis Papanagnou@janis_papanagnou@hotmail.com to comp.lang.awk on Fri Jan 14 00:42:57 2022
    From Newsgroup: comp.lang.awk

    On 13.01.2022 21:00, Aharon Robbins wrote:
    In article <srffnr$mbr$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
    On 09.01.2022 20:29, Aharon Robbins wrote:
    [...]
    https://github.com/nokia/awkcc.

    The code is primarily of historical interest; I think it would take
    a significant effort to build it on a more modern system, although I
    think it could be done.

    It compiles on my system with warnings but creates an awkcc executable.

    The strange thing is that calling it creates an error because it wants
    to run the awkcc.sh script (which is non-executable per default). It's,
    I think, the first time that I've seen such a design.

    What happens if you make awkcc.sh executable and put in your PATH?
    Do you end up being able to compile and awk program into C and
    then compile that and run it?

    I didn't want to do that before understanding what I actually do and
    what that is that I'd execute. Instead I had looked into some of the
    created files and noticed still a couple of hard coded paths in some
    of the files which just don't exist (or don't need to exist) in that
    way. What I want to say here is that there's more amiss in the package
    than just a missing executable flag, and that you have been correct
    with your original statement "It'd also be an effort to bring it up
    to date", though not in the make process - a C-file had been created,
    IIRC - but in the faulty runtime (or its generation). Together with
    the arguable design philosophy I'd rather abstain from putting more
    effort in that tool.

    Janis


    Thanks,

    Arnold


    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From arnold@arnold@skeeve.com (Aharon Robbins) to comp.lang.awk on Fri Jan 14 10:34:09 2022
    From Newsgroup: comp.lang.awk

    In article <srqde2$u86$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
    What happens if you make awkcc.sh executable and put in your PATH?
    Do you end up being able to compile and awk program into C and
    then compile that and run it?

    I didn't want to do that before understanding what I actually do and
    what that is that I'd execute. Instead I had looked into some of the
    created files and noticed still a couple of hard coded paths in some
    of the files which just don't exist (or don't need to exist) in that
    way. What I want to say here is that there's more amiss in the package
    than just a missing executable flag, and that you have been correct
    with your original statement "It'd also be an effort to bring it up
    to date", though not in the make process - a C-file had been created,
    IIRC - but in the faulty runtime (or its generation). Together with
    the arguable design philosophy I'd rather abstain from putting more
    effort in that tool.

    OK, that's all understandable.

    The main point of getting it released was for the historical
    value. It was an interesting program that I didn't want to
    get lost in the sands of time.

    Thanks,

    Arnold
    --
    Aharon (Arnold) Robbins arnold AT skeeve DOT com
    --- Synchronet 3.19b-Linux NewsLink 1.113