I have added support to gp for compiling multiple files simultaneously (akin to the -j4 flag to make). Since I have a dual processor machine, this dropped the total compile time for Interarchy from 8.4 minutes to 6 minutes.
I basically replaced ProcessDependencies and CompileIfNecessary, and hardly touched any of the rest of gp. But the sections replaced are essentially complete rewrites. It's not the most elegant of code, is still full of debugging code, is not written in gp-style, and does not currently support a command line switch, is minimally tested, and perhaps not all that efficient, but if anyone is interested, I'm happy to send them the code.
Enjoy, Peter.
Peter N Lewis wrote:
I have added support to gp for compiling multiple files simultaneously (akin to the -j4 flag to make). Since I have a dual processor machine, this dropped the total compile time for Interarchy from 8.4 minutes to 6 minutes.
I basically replaced ProcessDependencies and CompileIfNecessary, and hardly touched any of the rest of gp. But the sections replaced are essentially complete rewrites. It's not the most elegant of code, is still full of debugging code, is not written in gp-style, and does not currently support a command line switch, is minimally tested, and perhaps not all that efficient, but if anyone is interested, I'm happy to send them the code.
I think the effort to rewrite it into a clean patch for gp, would be worth the time spent on it. I believe it is useful on one-processor boxes also. In a decent OS that one processor can do something more useful than falling into sleep when threads get blocked by asynchronous IO requests, caused by file IO or virtual memory page faults.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Peter N Lewis wrote:
I have added support to gp for compiling multiple files simultaneously (akin to the -j4 flag to make). Since I have a dual processor machine, this dropped the total compile time for Interarchy from 8.4 minutes to 6 minutes.
I basically replaced ProcessDependencies and CompileIfNecessary, and hardly touched any of the rest of gp. But the sections replaced are essentially complete rewrites. It's not the most elegant of code, is still full of debugging code, is not written in gp-style, and does not currently support a command line switch, is minimally tested, and perhaps not all that efficient, but if anyone is interested, I'm happy to send them the code.
I think the effort to rewrite it into a clean patch for gp, would be worth the time spent on it. I believe it is useful on one-processor boxes also. In a decent OS that one processor can do something more useful than falling into sleep when threads get blocked by asynchronous IO requests, caused by file IO or virtual memory page faults.
Indeed. FWIW, it's an item on my list, and if Peter can't/doesn't want to rewrite his patch, I'll eventually add the functionality. But if you want to help adding it in GP "properly", Peter, feel free to contact me privately to discuss the details. (I'd obviously prefer to start from existing GP code and make as small changes as necessary.)
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Peter N Lewis wrote:
I have added support to gp for compiling multiple files simultaneously (akin to the -j4 flag to make). Since I have a dual processor machine, this dropped the total compile time for Interarchy from 8.4 minutes to 6 minutes.
I basically replaced ProcessDependencies and CompileIfNecessary, and hardly touched any of the rest of gp. But the sections replaced are essentially complete rewrites. It's not the most elegant of code, is still full of debugging code, is not written in gp-style, and does not currently support a command line switch, is minimally tested, and perhaps not all that efficient, but if anyone is interested, I'm happy to send them the code.
I think the effort to rewrite it into a clean patch for gp, would be worth the time spent on it. I believe it is useful on one-processor boxes also. In a decent OS that one processor can do something more useful than falling into sleep when threads get blocked by asynchronous IO requests, caused by file IO or virtual memory page faults.
Indeed. FWIW, it's an item on my list, and if Peter can't/doesn't want to rewrite his patch, I'll eventually add the functionality. But if you want to help adding it in GP "properly", Peter, feel free to contact me privately to discuss the details. (I'd obviously prefer to start from existing GP code and make as small changes as necessary.)
The change is relatively localized, but it does change the entire compilation loop, unsurprisingly, with just a few changes elsewhere. One thing I've noticed is that I use some {$L file.c} directives in my code. gp (as shipped) indicates that these "included files" don't have any dependency issues, but as far as I can see, they in fact do have dependency issues in that they must be compiled before the source file that includes them or gpc will error out, so they act as an implementation dependency. Is that correct or am I confused about it?
I have gp in my own subversion repository now, so I can track my changes. I have essentially four changes:
* gp case insensitive issue. Causes needless recompiling on a case insensitive file system when source files have cased names (like MacTypes.p). This may become more of an issue if Apple actually moves to more emphasis on a case sensitive version of HFS+, because Mac Pascal programers generally do use such case names, and we'll have to come up with a solution that works with them even on a case sensitive file system, even if it means enforcing case sensitivity in unit names.
* --print-output output file. This adds support for outputing the --print-* data to a file. I use this as part of a Make depend process in that gp can output the list of dependencies to a file while still outputing progress information to stdout
* BasicProgress, which adds support for outputing Make-like progress, eg "Compiling MacTypes.p" at verbose level 1.
* -j4, which adds support for 4 simultaneous compiles during build, allowing the compiles to terminate cleanly after one of them errors, supporting dependency for $L files.
As I'm sure all of you know, it takes at least as much effort to clean up a change to distribution standard (especially to match someone elses coding style). I am happy to put the effort in on this if the changes are going to be incorporated, but there is no sense in wasting time doing that if the changes wont be incorporated. Because of the complexity of the -j4 patch, I had to use my own Pascal style while I wrote it to allow my brain to concentrate on the programming. I have attached the patch as it currently stands (just the -j4 changes). I am happy to go back and change the style of the code (ie, change from
if p^.IsUnit then begin WriteLn (f, Prefix, p^.InterfaceName, ' ', p^.FileName, ' ', MD5Str (p^.MD5)); end;
to
if p^.IsUnit then WriteLn (f, Prefix, p^.InterfaceName, ' ', p^.FileName, ' ', MD5Str (p^.MD5));
and
while p <> nil do begin if p^.Dep^.Compiling then begin any_compiling := True; leave; end; p := p^.Next end;
to
while p <> nil do begin if p^.Dep^.Compiling then begin any_compiling := True; leave; end; p := p^.Next end;
and whatever else is appropriate if that will get the patch incorporated. I'll need to add support for -jX switch (defaulting to 1).
Just tell me what other changes would be required, and I'll go make them all and send a replacement patch.
Enjoy, Peter.
Peter N Lewis wrote:
The change is relatively localized, but it does change the entire compilation loop, unsurprisingly, with just a few changes elsewhere. One thing I've noticed is that I use some {$L file.c} directives in my code. gp (as shipped) indicates that these "included files" don't have any dependency issues, but as far as I can see, they in fact do have dependency issues in that they must be compiled before the source file that includes them or gpc will error out, so they act as an implementation dependency. Is that correct or am I confused about it?
I have gp in my own subversion repository now, so I can track my changes. I have essentially four changes:
- gp case insensitive issue. Causes needless recompiling on a case
insensitive file system when source files have cased names (like MacTypes.p). This may become more of an issue if Apple actually moves to more emphasis on a case sensitive version of HFS+, because Mac Pascal programers generally do use such case names, and we'll have to come up with a solution that works with them even on a case sensitive file system, even if it means enforcing case sensitivity in unit names.
- --print-output output file. This adds support for outputing the
--print-* data to a file. I use this as part of a Make depend process in that gp can output the list of dependencies to a file while still outputing progress information to stdout
- BasicProgress, which adds support for outputing Make-like progress,
eg "Compiling MacTypes.p" at verbose level 1.
- -j4, which adds support for 4 simultaneous compiles during build,
allowing the compiles to terminate cleanly after one of them errors, supporting dependency for $L files.
The build time improvements that I see with Peter's gp are astonishing, here is an example:
* powerpc-apple-darwin7, single core, single CPU, 1.8 GHz PowerPC G5 build time with standard gp: 1 hour 30 minutes build time with Peter's gp (-j4): 37 minutes
* i686-apple-darwin8, dual core, single CPU, 3.6 GHz Pentium 4 build time with standard gp: 30 minutes build time with Peter's gp (-j4): 11 minutes
That's 2.4 to 2.7 times faster.
Regards,
Adriaan van Os