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?
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.
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.
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.
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
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.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 790 |
Nodes: | 10 (0 / 10) |
Uptime: | 193:19:14 |
Calls: | 11,043 |
Files: | 186,065 |
Messages: | 1,743,694 |