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 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 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 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 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