bddicken
Create loopy test program for PL/I
Add PL/I code identical to the COBOL pendant.
I have:
- [ x] Read the project README, including the benchmark descriptions
Description of changes
Directory PL1 added for the PL/I language. The code on loopy.pl1 was tested under z/OS ADCD , PL/I Enterprise Edition V3. ADCD run on a somewhate lame PC (Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz ); the CPU time was 46MIN 59.65SEC. An identical run on a "real" mainframe would be welcome.
Reason for reopen: pull request was not merged. @bddicken: Could you please review this pull request at your convenience? Thank you!
Hello. Thanks for contributing! 🙏
However, if this program can't be run in a benchmark together with the other languages, it doesn't really belong, I think.
The benchmark runs on whatever computers people choose to run them on. For both @bddicken and me that means MacOS. But any environment that can run compile.sh and run.sh will do. If you add entries to those files for this program, we can start preparing to merge. I would also need instructions (or just a link) on how to install the toolchain. Please also consider providing a hello-world implementation, because we use that to measure start-times for the various languages.
Thank you first; I will try my best. I wish you all a happy new year!
Peter Strömberg @.***> (időpont: 2024. dec. 31., K, 18:17) ezt írta:
The benchmark runs on whatever computers people choose to run them on. For both @bddicken https://github.com/bddicken and me that means MacOS. But any environment that can run compile.sh and run.sh will do. If you add entries to those files for this program, we can start preparing to merge. I would also need instructions (or just a link) on how to install the toolchain. Please also consider providing a hello-world implementation, because we use that to measure start-times for the various languages.
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2566604740, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3XFPQF4B7A7L63HSYL2ILGRRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWGYYDINZUGA . You are receiving this because you modified the open/close state.Message ID: @.***>
A little belatedly, I looked at compile.sh and was horrified. Does this mean that on a given machine, all the compilers of the programming languages listed in the script must be installed? I originally thought (wrongly, I guess) that the project was more or less a repository for benchmark programs. Unfortunately, in PL/I's "native" environment (=mainframe) this is nearly impossible. So I installed the Iron Spring PL/I compiler on the WSL Ubuntu under Windows, with Python for comparison. But installing all languages is a Sisyphean task. Would it be possible to install the Iron Spring compiler on a Unix machine where the other languages are already installed?
Does this mean that on a given machine, all the compilers of the programming languages listed in the script must be installed?
Oh, no. I'm sorry that it created that impression! What I mean is that it needs to fit in this “framework”. So, if you have a way to compile and run it on Ubuntu that can be added to compile.sh and run.sh, that is totally OK. Please add those entries and we will have this PR merged. (And I repeat my wish for a hello-world contribution as well to be included.)
Now that you have given me hints on what I may need to install on my Mac, that is great too.
installing all languages is a Sisyphean task
Tell me about it. It has taken me a lot of time to get to here: https://pez.github.io/languages-visualizations/
Looking forward to be able to include PL/I!
Hello Peter,
I have compiled, and tested my new version with the "official" scripts. Here the new code: languages/loops/PL1/loopy at main · markons/languages https://github.com/markons/languages/blob/main/loops/PL1/loopy
To enable the compile, one must install the Iron Spring Software - Documentation http://www.iron-spring.com/doc.html PL/I in a Unix environment. I have used it in my WSL Ubuntu installation. It took some time, but all because of my missing Unix experience. For an experienced one it is rather straightforward; perhaps the
Here the benchmarking FYI.
*Checking pl1output: 1955594 *1950000 (the second number is only a trace from me) Check passed Benchmarking pl1 Benchmark 1: ./pl1/code/loopy.exe 40
- Time (mean ± σ): 47.092 s ± 0.205 s [User: 45.871 s, System: 0.010 s]*
- Range (min … max): 46.899 s … 47.308 s 3 runs*
(On an IBM mainframe the results could be slightly better of course ;)
Is this information sufficient to include my PL/I in the project?
Best regards Gabor
On Fri, Jan 3, 2025 at 1:38 PM Peter Strömberg @.***> wrote:
Does this mean that on a given machine, all the compilers of the programming languages listed in the script must be installed?
Oh, no. I'm sorry that it created that impression! What I mean is that it needs to fit in this “framework”. So, if you have a way to compile and run it on Ubuntu that can be added to compile.sh and run.sh, that is totally OK. Please add those entries and we will have this PR merged. (And I repeat my wish for a hello-world contribution as well to be included.)
Now that you have given me hints on what I may need to install on my Mac, that is great too.
installing all languages is a Sisyphean task
Tell me about it. It has taken me a lot of time to get to here: https://pez.github.io/languages-visualizations/
Looking forward to be able to include PL/I!
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2569161730, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3QBXZ2N76ZHNNXOJOD2I2AFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRZGE3DCNZTGA . You are receiving this because you modified the open/close state.Message ID: @.***>
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every time you push new code to the branch on your fork.
Three things:
- The naming of the program file. For all other languages the code is always in a
<benchmark>/<language>/code.<extension>file. So for loops and C, this isloops/code.c. I don't even remember if file extensions are a thing on mainframes, but I imagine that loopy could be placed inloops/pl1/code.pl1, if.pl1is some extension that could be used? - Please update
compile.shandrun.shwith the commands necessary to compile and run the program. Here it will get evident for you why the program should be namedcode.pl1, because the same commands would be used if someone (you?) contribute other benchmark implementations. - Speaking about other benchmark implementations, I would very much like if you included an implementation of
hello-world. We use this for measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not had that, but I think it would be a good idea to include that somehow. How about we create a file hello-world/pl1/README.md where we say a few words about the language and also can link to the instructions on how to install the toolchain on a Unix machine? Then other languages can follow that model.
Hello Peter,
Thanks for the prompt feedback. I'll try to gather the infos you need.
Regards Gabor
On Thu, Jan 9, 2025 at 4:59 PM Peter Strömberg @.***> wrote:
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every time you push new code to the branch on your fork.
Three things:
- The naming of the program file. For all other languages the code is always in a
/ /code. file. So for loops and C, this is loops/code.c. I don't even remember if file extensions are a thing on mainframes, but I imagine that loopy could be placed in loops/pl1/code.pl1, if .pl1 is some extension that could be used? - Please update compile.sh and run.sh with the commands necessary to compile and run the program. Here it will get evident for you why the program should be named code.pl1, because the same commands would be used if someone (you?) contribute other benchmark implementations.
- Speaking about other benchmark implementations, I would very much like if you included an implementation of hello-world. We use this for measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not had that, but I think it would be a good idea to include that somehow. How about we create a file hello-world/pl1/README.md where we say a few words about the language and also can link to the instructions on how to install the toolchain on a Unix machine? Then other languages can follow that model.
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2580642352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3S5WVD6SXQ4QJTFRPT2J2MFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBQGY2DEMZVGI . You are receiving this because you modified the open/close state.Message ID: @.***>
On Thu, Jan 9, 2025 at 4:59 PM Peter Strömberg @.***> wrote:
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every time you push new code to the branch on your fork.
Three things:
The naming of the program file. For all other languages the code is always in a
/ /code. file. So for loops and C, this is loops/code.c. I don't even remember if file extensions are a thing on mainframes, but I imagine that loopy could be placed in loops/pl1/code.pl1, if .pl1 is some extension that could be used? OK, I have changed the program name in languages/loops/PL1/code.pli at main · markons/languages https://github.com/markons/languages/blob/main/loops/PL1/code.pli to code.pli As I run the program on Linux, using the IronSpring compiler, I can do this; the .pli extension (or alternatively the .pl1) is valid there. On the mainframes, there is no extension for program names. Still maximal 8 alphanumeric characters as for >50 years.
Please update compile.sh and run.sh with the commands necessary to compile and run the program. Here it will get evident for you why the program should be named code.pl1, because the same commands would be used if someone (you?) contribute other benchmark implementations.
I call compile.sh like this:
*compile 'pl1' 'plic pl1/code/loopy.pli -o pl1/loopy.obj && ld
-L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t -o pl1/code/loopy.exe pl1/loopy.obj -lprf -lc > pl1/loopy.map' *
I call run.sh as:
run "pl1" "./pl1/code/loopy.exe" "./pl1/code/loopy.exe" "40"
- Speaking about other benchmark implementations, I would very much like if you included an implementation of hello-world. We use this for measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not had that, but I think it would be a good idea to include that somehow. How about we create a file hello-world/pl1/README.md where we say a few words about the language and also can link to the instructions on how to install the toolchain on a Unix machine? Then other languages can follow that model.
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2580642352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3S5WVD6SXQ4QJTFRPT2J2MFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBQGY2DEMZVGI . You are receiving this because you modified the open/close state.Message ID: @.***>
Sorry I've sent the answer partially. Here a more complete answer. The naming of the program file. For all other languages the code is always in a
/ /code. file. So for loops and C, this is loops/code.c. I don't even remember if file extensions are a thing on mainframes, but I imagine that loopy could be placed in loops/pl1/code.pl1, if .pl1 is some extension that could be used?
OK, I have changed the program name in languages/loops/PL1/code.pli at main · markons/languages https://github.com/markons/languages/blob/main/loops/PL1/code.pli to code.pli As I run the program on Linux, using the IronSpring compiler, I can do this; the .pli extension (or alternatively the .pl1) is valid there. On the mainframes, there is no extension for program names. Still maximal 8 alphanumeric characters as for >50 years.
Please update compile.sh and run.sh with the commands necessary to compile and run the program. Here it will get evident for you why the program should be named code.pl1, because the same commands would be used if someone (you?) contribute other benchmark implementations.
* I call compile.sh like this:*
*compile 'pl1' 'plic pl1/code/loopy.pli -o pl1/loopy.obj && ld
-L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t -o pl1/code/loopy.exe pl1/loopy.obj -lprf -lc > pl1/loopy.map' *
- I call run.sh as:* run "pl1" "./pl1/code/loopy.exe" "./pl1/code/loopy.exe" "40"
Please rename "loopy" into "code" throughout if needed.
*Speaking about other benchmark implementations, I would very much like if
you included an implementation of hello-world. We use this for measuring start times of each program.*
OK, done.
As for instructions on how to install the toolchain. So far we have not had that, but I think it would be a good idea to include that somehow. How about we create a file hello-world/pl1/README.md where we say a few words about the language and also can link to the instructions on how to install the toolchain on a Unix machine? Then other languages can follow that model.
- Do I need to create a "hello-world/pl1" subdirectory under my "PL1" ?*
Regards Gabor
On Thu, Jan 9, 2025 at 4:59 PM Peter Strömberg @.***> wrote:
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every time you push new code to the branch on your fork.
Three things:
- The naming of the program file. For all other languages the code is always in a
/ /code. file. So for loops and C, this is loops/code.c. I don't even remember if file extensions are a thing on mainframes, but I imagine that loopy could be placed in loops/pl1/code.pl1, if .pl1 is some extension that could be used? - Please update compile.sh and run.sh with the commands necessary to compile and run the program. Here it will get evident for you why the program should be named code.pl1, because the same commands would be used if someone (you?) contribute other benchmark implementations.
- Speaking about other benchmark implementations, I would very much like if you included an implementation of hello-world. We use this for measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not had that, but I think it would be a good idea to include that somehow. How about we create a file hello-world/pl1/README.md where we say a few words about the language and also can link to the instructions on how to install the toolchain on a Unix machine? Then other languages can follow that model.
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2580642352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3S5WVD6SXQ4QJTFRPT2J2MFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBQGY2DEMZVGI . You are receiving this because you modified the open/close state.Message ID: @.***>
On the mainframes, there is no extension for program names. Still maximal 8 alphanumeric characters as for >50 years.*
😂
Thanks for updating! What we need for merging this PR is that compile.sh and run.sh are updated with the commands for compiling and running the PL1 benchmarks. Since both these scripts will be used for all PL1 programs, the commands need to be stripped of any references to loopy.
- Do I need to create a "hello-world/pl1" subdirectory under my "PL1"
The hello-world program should go under hello-world/PL1/code.pli, where hello-world is a sibling directory to loops.
When you have moved the code there you should be able to cd to hello-world and run
../compile.sh
to compile the program(s), and:
../run.sh
to run them.
And from the loops directory you should be able to do the same for that program.
Depending on how many toolchains you have on your machine it can take a while to compile and run everything. Unfortunately the only way, so far, to run only one language is to comment out all the rest.
Here's a guess of what should go into compile.sh:
compile 'pl1' 'plic pl1/code.pli -o pl1/code.obj && ld -L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t -o pl1/code.exe pl1/code.obj -lprf -lc > pl1/code.map'
This will be a bit too specific and only for 32-bit X86, but it's a start. 😄
And for run.sh
run "PL1" "./pl1/code.exe" "./pl1/code.exe" "${input}"
I hope this makes sense. The point is that the same script is used for compiling both loops and hello-world (and any other benchmark someone contributes) and that which one is compiled is determined from the directory from which compile.sh is run. Same for run.sh.
Dear Peter,
huh. I've succeeded in implementing the third sample "levenshtein algorithm" in Iron Spring's PL/I. It was not so trivial; it still has problems implementing dynamic size array allocation. I've changed the algorithm slightly by pre-allocate the "distance" matrix as a fixed size array. I've tested it on a couple of samples, and checked the results using Online calculator: Levenshtein Distance https://planetcalc.com/1721/ . Then I've had a look at 'input.txt' which generates the in 'check.sh' required values; it has a length of 3000 characters, which is too long as a runtime parameter in PL/I. It has a maximum length of 100 characters. My question: is it possible, my PL/I program reads the 'input.txt' file directly from the standard directory, instead of getting it as a runtime parameter? Alternatively, I forget the Levensthine algorithm, and develop only the hello and the loop textst for PL/I, similar to Cobol. Which one is suitable for the project? Honestly speaking, for me the first one is preferred.
Regards Gábor
On Thu, Jan 9, 2025 at 10:00 PM Peter Strömberg @.***> wrote:
On the mainframes, there is no extension for program names. Still maximal 8 alphanumeric characters as for >50 years.*
😂
Thanks for updating! What we need for merging this PR is that compile.sh and run.sh are updated with the commands for compiling and running the PL1 benchmarks. Since both these scripts will be used for all PL1 programs, the commands need to be stripped of any references to loopy.
- Do I need to create a "hello-world/pl1" subdirectory under my "PL1"
The hello-world program should go under hello-world/PL1/code.pli, where hello-world is a sibling directory to loops.
When you have moved the code there you should be able to cd to hello-world and run
../compile.sh
to compile the program(s), and:
../run.sh
to run them.
And from the loops directory you should be able to do the same for that program.
Depending on how many toolchains you have on your machine it can take a while to compile and run everything. Unfortunately the only way, so far, to run only one language is to comment out all the rest.
Here's a guess of what should go into compile.sh:
compile 'pl1' 'plic pl1/code.pli -o pl1/code.obj && ld -L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t -o pl1/code.exe pl1/code.obj -lprf -lc > pl1/code.map'
This will be a bit too specific and only for 32-bit X86, but it's a start. 😄
And for run.sh
run "PL1" "./pl1/code.exe" "./pl1/code.exe" "${input}"
I hope this makes sense. The point is that the same script is used for compiling both loops and hello-world (and any other benchmark someone contributes) and that which one is compiled is determined from the directory from which compile.sh is run. Same for run.sh.
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2581237143, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3RVFVW4YG7QRCFVDPD2J3PO3AVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBRGIZTOMJUGM . You are receiving this because you modified the open/close state.Message ID: @.***>
Hi!
Yes, let the program read from the file instead.
In this PR https://github.com/bddicken/languages/pull/365 I am actually proposing to change it so that all programs will read from a file instead of from the command line. (If we end up going with that proposal there will be some more work for the programs to also measure the run times and such, but you can disregard that for now.)
Hi! Now we have started moving over to the in-process runner (and thus a Levenshtein program that should read from file instead of from command line args).
To get the PL1 contributions over will involve writing a benchmarking utility that does the running and measuring of the benchmarked function. See the updated project README for more on this and to find reference implementations. Let me know if there are something unclear or if you think I can help in some way.
Hi! Sorry for the late reply. I was deep in the development of the PL/I implementation of the Levenhstein algorithm. Now I'm happy as it runs OK with the check. It was hard work, as the Iron Spring PL/I has some features which are not 100% compatible with the mainframe PL/I which I know. I hope I can next week deliver the commands for the compile/run steps. As I've said, the basis is the implementation of the Iron Spring compiler on your side, but it is a straightforward process for the Unix profis. Regards Gábor
On Sun, Jan 26, 2025 at 6:18 PM Peter Strömberg @.***> wrote:
Hi! Now we have started moving over to the in-process runner (and thus a Levenshtein program that should read from file instead of from command line args).
To get the PL1 contributions over will involve writing a benchmarking utility that does the running and measuring of the benchmarked function. See the updated project README for more on this and to find reference implementations. Let me know if there are something unclear or if you think I can help in some way.
— Reply to this email directly, view it on GitHub https://github.com/bddicken/languages/pull/311#issuecomment-2614513152, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEP3S7KQRZULXS4LXT2ZD2MUKE3AVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGUYTGMJVGI . You are receiving this because you modified the open/close state.Message ID: @.***>