[M3devel] modula3 fork and virtual timer
Jay K
jayk123 at hotmail.com
Wed Aug 16 04:08:38 CEST 2017
Upgrading gcc might be a good idea.
I won't remove LTO this time, but remember optimization and Modula-3 have a not great history.
I did go through an exercise of enabling lots of optimizations and searching out
which ones broke things, but not why or fixing them -- just changing Modula-3 to always
disable them. I also found in some cases, they were removed from later gcc anyway.
Note that the IR output by Modula-3 into gcc is more difficult for gcc to optimize
than normal C or C++, because it is lower level. It won't be able to do
type based alias analysis, and the amount of address-taken and cast is probably
more than "normal" and will defeat optimization.
Yes we are very far behind, like 7 years.
I have an idea that AVX et. al. should be mostly implementable as libraries and not
language extensions.
- Jay
________________________________
From: Peter McKinna <peter.mckinna at gmail.com>
Sent: Tuesday, August 15, 2017 8:03 AM
To: Jay K
Cc: m3devel
Subject: Re: [M3devel] modula3 fork and virtual timer
Well my interest in LTO was prompted in part when I converted a C module which implemented the Viola-Jones
facial detection algorithm. (I'll upload it to git some day as an example) Even with threads it seemed slower. And I think the difference was that they used some AVX code on some of the inner loops.
So I was thinking about the best way to get vector support. The harder way would be to add a new type to the language say VECTOR which is similar to ARRAY but with obvious restrictions that the element type would only be integer or float and the operations would
correspond to the AVX ops or if you look at the LLVM vector support something like that. Anyway a lot of work on the front end and all the backends.
But it would be simpler to just have an interface to the gcc compiler functions for AVX and for that you would need a C layer to do the actual calls. But to avoid the call/return to the C layer you could use LTO to do the inlining. (I think the inlining is only done at O3 so we would have to extend the simple cm3 optimisation flag to allow users to request the level they wanted)
And I for one would support an upgrade to the latest gcc. I think its about version 7 now.
Regards Peter
On Tue, Aug 15, 2017 at 5:25 PM, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:
Ah, I removed it in 2010. Head is much better than 5.8.6 here.
https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3
Revision 1.13: download<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?rev=1.13;content-type=text%2Fplain> - view: text<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?rev=1.13;content-type=text%2Fplain>, markup<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?rev=1.13;content-type=text%2Fx-cvsweb-markup>, annotated<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?annotate=1.13> - select for diffs<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?r1=1.13#rev1.13>
Sun Apr 11 13:01:43 2010 (7 years, 4 months ago) by jkrell
Branches: MAIN<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?only_with_tag=MAIN>
Diff to: previous 1.12: preferred<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3.diff?r1=1.12;r2=1.13>, unified<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3.diff?r1=1.12;r2=1.13;f=u>
Changes since revision 1.12: +1 -15 lines
There is no need to disable the interval timer around fork.
It doesn't get inherited by the child.
Revision 1.14: download<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?rev=1.14;content-type=text%2Fplain> - view: text<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?rev=1.14;content-type=text%2Fplain>, markup<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?rev=1.14;content-type=text%2Fx-cvsweb-markup>, annotated<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?annotate=1.14> - select for diffs<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?r1=1.14#rev1.14>
Sun Apr 11 13:04:38 2010 (7 years, 4 months ago) by jkrell
Branches: MAIN<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3?only_with_tag=MAIN>
Diff to: previous 1.13: preferred<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3.diff?r1=1.13;r2=1.14>, unified<https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3.diff?r1=1.13;r2=1.14;f=u>
Changes since revision 1.13: +1 -7 lines
There's also no need to disable/enable scheduling, ThreadPosix.m3 registers fork handlers to do that.
Do you have code that LTO will really help?
i.e. cross module inlining?
The gcc backend imho was just too large, so I cut out stuff that didn't seem worthwhile -- gmp, mpfr, mpc, lto...
I asked a while ago, I'll ask again -- port latest gcc?
Or what is the state of llvm? Would it be horrible if I started from scratch there?
I think I'd output the textual IR files.
I'm also somewhat keen on writing a Modula-3 IR JIT or interpreter, however I fear one or two of the files (in C++ and Cpreprocessor) I'd like to start from GPL2 and stuck there.
One wonders how good or bad our IR is for a JIT input -- it is backend input, sort of (gcc backend transforms it into gcc IR)
- Jay
________________________________
From: M3devel <m3devel-bounces at elegosoft.com<mailto:m3devel-bounces at elegosoft.com>> on behalf of Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>>
Sent: Tuesday, August 15, 2017 1:28 AM
To: Peter McKinna
Cc: m3devel
Subject: Re: [M3devel] modula3 fork and virtual timer
Huh I'll check head later.
No I probably removed LTO sorry, but C backend...
Or maybe llvm?
Or report latest gcc?
LTO doesn't scale in compile time but Llvm has ThinLTO now..
LTO requires linker support. A matching linker? I'm not sure.
- Jay
________________________________
From: Peter McKinna <peter.mckinna at gmail.com<mailto:peter.mckinna at gmail.com>>
Sent: Monday, August 14, 2017 6:21:15 PM
To: Jay K
Cc: m3devel
Subject: Re: [M3devel] modula3 fork and virtual timer
Hi Jay,
I can't see that code anywhere in that file on git. What version are you using?
By the way, you wouldnt happen to know if we can get LTO support in the backend would you?
Regards Peter
On Tue, Aug 15, 2017 at 8:20 AM, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:
/mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3
PROCEDURE Create_ForkExec:
.
.
.
(* Turn off the interval timer (so it won't be running in child). *)
nit := Utime.struct_itimerval {
it_interval := Utime.struct_timeval {0, 0},
it_value := Utime.struct_timeval {0, 0}};
IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN
<* ASSERT FALSE *>
END;
.
.
.
fork()
.
.
(* Enable scheduler. *)
Scheduler.EnableSwitching ();
(* Restore previous virtual timer. *)
IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN
<* ASSERT FALSE *>
END;
This code has a number of problems.
- It looks thread-unsafe -- another thread could be changing the timer.
- The comments are wrong in multiple ways.
The timer doesn't have to be turned off to not run in the child.
Timers except alarm() are not inherited by child.
It goes ahead and enables in the child anyway. Granted, after EnableSwitching,
which also enables it!
- Doesn't work on Microsoft's Windows Subsystem for Linux (WSL).
You get back -1/EINVAL.
- Is probably specific to user threads?
- Fails to put a useful message in the assert other than "FALSE"
Proposals:
1. Remove it.
2. Make it check for and ignore EINVAL, and possibly WSL, and not then enable in child.
3. Change it to get in parent and set in child if enabled.
4. Move it to Thread.AtFork in user threads. Though again, not clearly needed there.
5. Consider that fork+exec should work from C/C++ code in a process that is using Modula3.
6. Research posix_spawn and use it more.
We can probably just use it and forget about any system that lacks it.
Thoughts?
WSL can be detected by searching for "Microsoft" in /proc/sys/kernel/osrelease or /proc/version.
Or we can just accept -1/EINVAL here for any OS.
- Jay
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20170816/90069fd1/attachment-0001.html>
More information about the M3devel
mailing list