Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394664 > unrolled thread
| Started by | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| First post | 2025-10-22 14:39 -0700 |
| Last post | 2025-10-27 11:51 -0700 |
| Articles | 20 on this page of 196 — 19 participants |
Back to article view | Back to comp.lang.c
New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-22 14:39 -0700
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 22:19 -0300
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 02:42 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 03:04 +0000
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 15:05 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-23 11:36 +0100
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-23 07:59 -0300
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 16:04 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 01:44 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 19:00 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 14:27 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-24 19:35 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 19:50 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-24 18:59 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:20 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 23:18 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:25 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 11:26 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 13:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:07 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 17:03 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:04 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 16:58 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 17:27 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 22:49 +0200
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 23:07 +0200
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 18:01 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-29 20:33 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:29 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:07 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 03:08 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:50 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:58 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:45 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:48 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:23 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 22:39 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 15:59 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 16:05 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:00 +0200
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 18:28 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:49 +0200
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-29 21:30 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:32 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:14 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 16:36 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 17:24 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:39 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 11:16 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 14:59 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 23:14 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 18:48 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 19:24 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 15:10 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:19 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 18:03 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 09:02 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 08:06 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 11:20 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 17:12 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 21:21 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 00:04 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 16:47 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 00:36 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 03:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 21:24 -0700
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 04:52 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 05:38 +0000
Re: New and improved version of cdecl Richard Heathfield <rjh@cpax.org.uk> - 2025-10-30 07:45 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 16:41 +0200
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 16:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 17:30 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 18:29 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 18:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:21 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:44 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:49 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 12:50 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 00:27 +0000
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 17:35 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 14:13 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 14:32 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 16:22 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:40 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 12:39 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 14:55 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 17:18 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 17:52 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-30 05:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 11:15 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:07 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 16:04 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 18:30 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:49 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 18:59 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:23 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 16:44 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 00:15 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 18:16 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:36 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 19:13 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:43 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:10 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 16:34 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:01 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 00:28 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:22 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 10:29 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-31 13:15 +0200
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 21:39 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-31 11:43 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 22:47 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:16 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 23:40 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-31 17:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 09:31 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 23:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:49 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 02:14 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 22:01 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 11:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 14:56 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:37 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:37 +0100
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 11:52 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:48 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-29 23:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 06:57 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-29 14:17 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 14:40 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-29 16:09 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 16:47 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 05:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:56 +0000
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-28 17:34 -0400
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 04:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:31 -0700
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 20:52 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 17:30 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:11 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 19:59 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:45 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 10:27 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 01:22 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 17:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 22:26 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-29 00:04 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 14:56 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 00:34 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:45 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 01:12 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:15 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 14:56 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 13:18 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 15:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 16:16 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:04 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 13:51 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 17:18 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 15:12 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 10:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 11:22 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 17:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 17:44 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:10 +0100
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:47 -0700
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-27 22:33 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:23 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 16:20 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:48 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:41 +0100
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-25 11:40 -0400
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 16:48 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 19:14 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-25 15:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 08:07 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-24 21:36 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:07 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:01 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-24 15:01 -0700
Re: New and improved version of cdecl Andrey Tarasevich <noone@noone.net> - 2025-10-26 12:09 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:36 -0700
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 07:31 -0800
Re: New and improved version of cdecl Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:38 +0000
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 16:46 -0800
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 17:51 -0800
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 14:44 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:38 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:51 -0700
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 12:50 +0100 |
| Message-ID | <10dvjea$3l9fp$1@dont-email.me> |
| In reply to | #394956 |
On 30/10/2025 05:24, Keith Thompson wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
> [...]
>> Assuming that you have enough RAM you should try at least using
>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote
>> at least, because AFAIK cheapest PC CPU-s of reasonable age
>> have at least 2 cores, so to fully utilize the machine you
>> need at least 2 jobs. 3 is better, because some jobs may wait
>> for I/O.
>
> I haven't been using make's "-j" option for most of my builds.
> I'm going to start doing so now (updating my wrapper script).
>
> I initially tried replacing "make" by "make -j", with no numeric
> argument. The result was that my system nearly froze (the load
> average went up to nearly 200). It even invoked the infamous OOM
> killer. "make -j" tells make to use as many parallel processes
> as possible.
>
> "make -j $(nproc)" is much better. The "nproc" command reports the
> number of available processing units. Experiments with a fairly
> large build show that arguments to "-j" larger than $(nproc) do
> not speed things up (on a fairly old machine with nproc=4). I had
> speculated that "make -n 5" might be worthwhile of some processes
> were I/O-bound, but that doesn't appear to be the case.
>
> This applies to GNU make. There are other "make" implementations
> which may or may not have a similar feature.
>
Sometimes "make -j" can be problematic, yes. I don't know if newer
versions of GNU make have got better at avoiding being too enthusiastic
about starting jobs, but certainly if you have a project where a very
large number of compile tasks could be started in parallel, but you
don't have the ram to handle them all, things can go badly wrong. I've
seen that myself too on occasion. (In the case of cdecl, there are not
that many parallel compiles for it to be a risk, at least not on my
machine.)
Using "make -j ${nproc}" - or using "make -j 4" or "make -j 8" if you
know your core count - can be a safer starting point. The ideal number
for a given build can vary quite a lot, however. More parallel
processes take more ram - great up to a point, but it can mean less ram
for disk and file caching and thus slower results overall. And often
cores are not all created equal - with SMT, half your cores might not be
"real" cores, and on some processors you have a mix of fast cores and
slow low-power cores. On my work machine with 4 "real" cores and 4 SMT
cores, "make -j 6" is usually optimal for bigger builds. And then you
have to consider that sometimes builds require significant other work
than just compiling, and the ideal balance for those tasks may be
different. Of course such fine-tuning it only really matters if you are
doing the builds a lot.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-31 00:27 +0000 |
| Message-ID | <10e0vpm$7p7j$1@paganini.bofh.team> |
| In reply to | #394956 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
> [...]
>> Assuming that you have enough RAM you should try at least using
>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote
>> at least, because AFAIK cheapest PC CPU-s of reasonable age
>> have at least 2 cores, so to fully utilize the machine you
>> need at least 2 jobs. 3 is better, because some jobs may wait
>> for I/O.
>
> I haven't been using make's "-j" option for most of my builds.
> I'm going to start doing so now (updating my wrapper script).
>
> I initially tried replacing "make" by "make -j", with no numeric
> argument. The result was that my system nearly froze (the load
> average went up to nearly 200). It even invoked the infamous OOM
> killer. "make -j" tells make to use as many parallel processes
> as possible.
>
> "make -j $(nproc)" is much better. The "nproc" command reports the
> number of available processing units. Experiments with a fairly
> large build show that arguments to "-j" larger than $(nproc) do
> not speed things up (on a fairly old machine with nproc=4). I had
> speculated that "make -n 5" might be worthwhile of some processes
> were I/O-bound, but that doesn't appear to be the case.
I frequently build my project on a few different machines. My
machines typically are generously (compared to compiler need)
equipped with RAM. Measuring several builds '-j 3' gave me
fastest build on 2 core machine (no hyperthreading), '-j 7'
gave me fastest build on old 4 core machine with hyperthreading
(so 'nproc' reported 8 cores). In general, increasing number
of jobs I see increasing total CPU time, but real time may go
down because more jobs can use time where CPU(s) would be
otherwise idle. At some number of jobs I get best real time
and with larger number of jobs overheads due to multiple jobs
seem to dominate leading to increase in real time. If number
of jobs is too high I get slowdown due to lack of real memory.
On 12 core machine (24 logical cores) I use '-j 20'. Increasing
number of jobs give sligtly faster build, but difference is
small, so I prefer to have more cores availble for interactive
use.
Of course, that is balancing tradeoffs, your builds may have
different characteristics than mine. I just wanted to say
that _sometimes_ going beyond number of cores is useful.
IIUC what Bart wrote he got 3 times speedup using '-j 3'
on two core machine, which is unusually good speedup. IME
normally 3 jobs on 2 core machine is neutral or gives small
speedup. OTOH with hyperthreading activationg logical core
my slow down its twin. Consequently using less jobs than
logical cores may be better.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-30 17:35 -0700 |
| Message-ID | <10e108l$465s$1@dont-email.me> |
| In reply to | #394989 |
On 10/30/2025 5:27 PM, Waldek Hebisch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >> [...] >>> Assuming that you have enough RAM you should try at least using >>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote >>> at least, because AFAIK cheapest PC CPU-s of reasonable age >>> have at least 2 cores, so to fully utilize the machine you >>> need at least 2 jobs. 3 is better, because some jobs may wait >>> for I/O. >> >> I haven't been using make's "-j" option for most of my builds. >> I'm going to start doing so now (updating my wrapper script). >> >> I initially tried replacing "make" by "make -j", with no numeric >> argument. The result was that my system nearly froze (the load >> average went up to nearly 200). It even invoked the infamous OOM >> killer. "make -j" tells make to use as many parallel processes >> as possible. >> >> "make -j $(nproc)" is much better. The "nproc" command reports the >> number of available processing units. Experiments with a fairly >> large build show that arguments to "-j" larger than $(nproc) do >> not speed things up (on a fairly old machine with nproc=4). I had >> speculated that "make -n 5" might be worthwhile of some processes >> were I/O-bound, but that doesn't appear to be the case. > > I frequently build my project on a few different machines. My > machines typically are generously (compared to compiler need) > equipped with RAM. Measuring several builds '-j 3' gave me > fastest build on 2 core machine (no hyperthreading), '-j 7' > gave me fastest build on old 4 core machine with hyperthreading > (so 'nproc' reported 8 cores). In general, increasing number > of jobs I see increasing total CPU time, but real time may go > down because more jobs can use time where CPU(s) would be > otherwise idle. At some number of jobs I get best real time > and with larger number of jobs overheads due to multiple jobs > seem to dominate leading to increase in real time. If number > of jobs is too high I get slowdown due to lack of real memory. > > On 12 core machine (24 logical cores) I use '-j 20'. Increasing > number of jobs give sligtly faster build, but difference is > small, so I prefer to have more cores availble for interactive > use. > > Of course, that is balancing tradeoffs, your builds may have > different characteristics than mine. I just wanted to say > that _sometimes_ going beyond number of cores is useful. > IIUC what Bart wrote he got 3 times speedup using '-j 3' > on two core machine, which is unusually good speedup. IME > normally 3 jobs on 2 core machine is neutral or gives small > speedup. OTOH with hyperthreading activationg logical core Make sure to avoid false sharing when using hyperthreading... :^o > my slow down its twin. Consequently using less jobs than > logical cores may be better. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-30 14:13 +0000 |
| Message-ID | <BoKMQ.86734$P8zb.44840@fx04.iad> |
| In reply to | #394954 |
antispam@fricas.org (Waldek Hebisch) writes: >bart <bc@freeuk.com> wrote: >> On 29/10/2025 23:04, David Brown wrote: >>> On 29/10/2025 22:21, bart wrote: >> >> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are: >> >> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make >>>output >> <warnings> >> real 0m49.512s >> user 0m19.033s >> sys 0m3.911s > >Those numbers indicate that there is something wrong with your >machine. Sum of second and third line above give CPU time. >Real time is twice as large, so something is slowing down things. >One possible trouble is having too small RAM, then OS is swaping >data to/from disc. Some programs do a lot of random I/O, that >can be slow on spinning disc, but SSD-s usually are much >faster at random I/O. > >Assuming that you have enough RAM you should try at least using >'make -j 3', that is allow make to use up to 3 jobs. I wrote >at least, because AFAIK cheapest PC CPU-s of reasonable age >have at least 2 cores, so to fully utilize the machine you >need at least 2 jobs. 3 is better, because some jobs may wait >for I/O. > >FYI, reasonably typical report for normal make (without -j >option) on my machine is: > >real 0m4.981s >user 0m3.712s >sys 0m0.963s > Just for grins, here's a report for a full rebuild of a real-world project that I build regularly. Granted most builds are partial (e.g. one or two source files touched) and take far less time (15 seconds or so, most of which is make calling stat(2) on a few hundred source files on an NFS filesystem). Close to three million SLOC, mostly in header files. C++. $ time make -s -j96 real 9m10.38s user 3h50m15.59s sys 9m58.20s I'd challenge Bart to match that with a similarly sized project using his compiler and toolset, but I seriously doubt that this project could be effectively implemented using his personal language and toolset.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 14:32 +0000 |
| Message-ID | <10dvsu3$3nsa8$1@dont-email.me> |
| In reply to | #394966 |
On 30/10/2025 14:13, Scott Lurndal wrote: > antispam@fricas.org (Waldek Hebisch) writes: >> bart <bc@freeuk.com> wrote: >>> On 29/10/2025 23:04, David Brown wrote: >>>> On 29/10/2025 22:21, bart wrote: > >>> >>> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are: >>> >>> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make >>>> output >>> <warnings> >>> real 0m49.512s >>> user 0m19.033s >>> sys 0m3.911s >> >> Those numbers indicate that there is something wrong with your >> machine. Sum of second and third line above give CPU time. >> Real time is twice as large, so something is slowing down things. >> One possible trouble is having too small RAM, then OS is swaping >> data to/from disc. Some programs do a lot of random I/O, that >> can be slow on spinning disc, but SSD-s usually are much >> faster at random I/O. >> >> Assuming that you have enough RAM you should try at least using >> 'make -j 3', that is allow make to use up to 3 jobs. I wrote >> at least, because AFAIK cheapest PC CPU-s of reasonable age >> have at least 2 cores, so to fully utilize the machine you >> need at least 2 jobs. 3 is better, because some jobs may wait >> for I/O. >> >> FYI, reasonably typical report for normal make (without -j >> option) on my machine is: >> >> real 0m4.981s >> user 0m3.712s >> sys 0m0.963s >> > > Just for grins, here's a report for a full rebuild of a real-world project > that I build regularly. Granted most builds are partial (e.g. one or > two source files touched) and take far less time (15 seconds or so, > most of which is make calling stat(2) on a few hundred source files > on an NFS filesystem). Close to three million SLOC, mostly in header > files. C++. What is the total size of the produced binaries? That will me an idea of the true LoC for the project. How many source files (can include headers) does it involve? How many binaries does it actually produce? > $ time make -s -j96 > real 9m10.38s > user 3h50m15.59s > sys 9m58.20s > > I'd challenge Bart to match that with a similarly sized project using > his compiler and toolset, but I seriously doubt that this project could > be effectively implemented using his personal language and toolset. If what you are asking is how my toolset can cope with a project on this scale, then I can have a go at emulating it, given the information above. I can tell you that over 4 hours, and working at generating 3-5MB per second, my compiler could produce 40-70GB of binary code in that time, although not in one file due to memory. I guess the size is somewhat smaller than that.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-30 16:22 +0000 |
| Message-ID | <BhMMQ.879700$7Ika.785149@fx17.iad> |
| In reply to | #394967 |
bart <bc@freeuk.com> writes: >On 30/10/2025 14:13, Scott Lurndal wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >>> bart <bc@freeuk.com> wrote: >>>> On 29/10/2025 23:04, David Brown wrote: >>>>> On 29/10/2025 22:21, bart wrote: >> >>>> >>>> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are: >>>> >>>> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make >>>>> output >>>> <warnings> >>>> real 0m49.512s >>>> user 0m19.033s >>>> sys 0m3.911s >>> >>> Those numbers indicate that there is something wrong with your >>> machine. Sum of second and third line above give CPU time. >>> Real time is twice as large, so something is slowing down things. >>> One possible trouble is having too small RAM, then OS is swaping >>> data to/from disc. Some programs do a lot of random I/O, that >>> can be slow on spinning disc, but SSD-s usually are much >>> faster at random I/O. >>> >>> Assuming that you have enough RAM you should try at least using >>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote >>> at least, because AFAIK cheapest PC CPU-s of reasonable age >>> have at least 2 cores, so to fully utilize the machine you >>> need at least 2 jobs. 3 is better, because some jobs may wait >>> for I/O. >>> >>> FYI, reasonably typical report for normal make (without -j >>> option) on my machine is: >>> >>> real 0m4.981s >>> user 0m3.712s >>> sys 0m0.963s >>> >> >> Just for grins, here's a report for a full rebuild of a real-world project >> that I build regularly. Granted most builds are partial (e.g. one or >> two source files touched) and take far less time (15 seconds or so, >> most of which is make calling stat(2) on a few hundred source files >> on an NFS filesystem). Close to three million SLOC, mostly in header >> files. C++. > > >What is the total size of the produced binaries? There are 181 shared objects (DLL in windows speak) and six binaries produced by the build. The binaries are all quite small since they dynamically link at runtime with the necessary shared objects, the set of which can vary from run-to-run. The largest shared object is 7.5MB. text data bss dec hex filename 6902921 109640 1861744 8874305 876941 lib/libXXX.so > That will me an idea of >the true LoC for the project. There is really no relationship between SLoC and binary size. There are about 16 million SLOC (it's been a while since I last run sloccount against this codebase). $ sloccount . Totals grouped by language (dominant language first): ansic: 11905053 (72.22%) python: 2506984 (15.21%) cpp: 1922112 (11.66%) tcl: 87725 (0.53%) asm: 42745 (0.26%) sh: 14333 (0.09%) Total Physical Source Lines of Code (SLOC) = 16,484,351 Development Effort Estimate, Person-Years (Person-Months) = 5,357.42 (64,289.00) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 13.99 (167.89) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 382.92 Total Estimated Cost to Develop = $ 723,714,160 (average salary = $56,286/year, overhead = 2.40). The bulk of the ANSI C code are header files generated from YAML, likewise most of the python code (used for unit testing). The primary functionality is in the C++ (cpp) code. The application is highly multithreaded (circa 100 threads in an average run). > >How many source files (can include headers) does it involve? How many >binaries does it actually produce? > >> $ time make -s -j96 >> real 9m10.38s >> user 3h50m15.59s >> sys 9m58.20s >> >> I'd challenge Bart to match that with a similarly sized project using >> his compiler and toolset, but I seriously doubt that this project could >> be effectively implemented using his personal language and toolset. > >If what you are asking is how my toolset can cope with a project on this >scale, then I can have a go at emulating it, given the information above. > >I can tell you that over 4 hours, and working at generating 3-5MB per >second, my compiler could produce 40-70GB of binary code in that time, That's a completely irrelevent metric.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 17:40 +0000 |
| Message-ID | <10e07tg$3rpt2$1@dont-email.me> |
| In reply to | #394971 |
On 30/10/2025 16:22, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 30/10/2025 14:13, Scott Lurndal wrote: >>> antispam@fricas.org (Waldek Hebisch) writes: >>>> bart <bc@freeuk.com> wrote: >>>>> On 29/10/2025 23:04, David Brown wrote: >>>>>> On 29/10/2025 22:21, bart wrote: >>> >>>>> >>>>> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are: >>>>> >>>>> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make >>>>>> output >>>>> <warnings> >>>>> real 0m49.512s >>>>> user 0m19.033s >>>>> sys 0m3.911s >>>> >>>> Those numbers indicate that there is something wrong with your >>>> machine. Sum of second and third line above give CPU time. >>>> Real time is twice as large, so something is slowing down things. >>>> One possible trouble is having too small RAM, then OS is swaping >>>> data to/from disc. Some programs do a lot of random I/O, that >>>> can be slow on spinning disc, but SSD-s usually are much >>>> faster at random I/O. >>>> >>>> Assuming that you have enough RAM you should try at least using >>>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote >>>> at least, because AFAIK cheapest PC CPU-s of reasonable age >>>> have at least 2 cores, so to fully utilize the machine you >>>> need at least 2 jobs. 3 is better, because some jobs may wait >>>> for I/O. >>>> >>>> FYI, reasonably typical report for normal make (without -j >>>> option) on my machine is: >>>> >>>> real 0m4.981s >>>> user 0m3.712s >>>> sys 0m0.963s >>>> >>> >>> Just for grins, here's a report for a full rebuild of a real-world project >>> that I build regularly. Granted most builds are partial (e.g. one or >>> two source files touched) and take far less time (15 seconds or so, >>> most of which is make calling stat(2) on a few hundred source files >>> on an NFS filesystem). Close to three million SLOC, mostly in header >>> files. C++. >> >> >> What is the total size of the produced binaries? > > There are 181 shared objects (DLL in windows speak) and > six binaries produced by the build. The binaries are all quite small since > they dynamically link at runtime with the necessary > shared objects, the set of which can vary from run-to-run. > > The largest shared object is 7.5MB. > > text data bss dec hex filename > 6902921 109640 1861744 8874305 876941 lib/libXXX.so > > >> That will me an idea of >> the true LoC for the project. > > There is really no relationship between SLoC and binary size. Yes, there is: a rule of thumb for x64 is 10 bytes of code for line of C source. But disproportional use of header files may affect that. > There are about 16 million SLOC (it's been a while since I > last run sloccount against this codebase). > > $ sloccount . > Totals grouped by language (dominant language first): > ansic: 11905053 (72.22%) > python: 2506984 (15.21%) > cpp: 1922112 (11.66%) > tcl: 87725 (0.53%) > asm: 42745 (0.26%) > sh: 14333 (0.09%) > > Total Physical Source Lines of Code (SLOC) = 16,484,351 > Development Effort Estimate, Person-Years (Person-Months) = 5,357.42 (64,289.00) > (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) > Schedule Estimate, Years (Months) = 13.99 (167.89) > (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) > Estimated Average Number of Developers (Effort/Schedule) = 382.92 > Total Estimated Cost to Develop = $ 723,714,160 > (average salary = $56,286/year, overhead = 2.40). > > The bulk of the ANSI C code are header files generated from > YAML, likewise most of the python code (used for unit testing). > The primary functionality is in the C++ (cpp) code. > The application is highly multithreaded (circa 100 threads in > an average run). > >> >> How many source files (can include headers) does it involve? How many >> binaries does it actually produce? >> >>> $ time make -s -j96 >>> real 9m10.38s >>> user 3h50m15.59s >>> sys 9m58.20s >>> >>> I'd challenge Bart to match that with a similarly sized project using >>> his compiler and toolset, but I seriously doubt that this project could >>> be effectively implemented using his personal language and toolset. >> >> If what you are asking is how my toolset can cope with a project on this >> scale, then I can have a go at emulating it, given the information above. >> >> I can tell you that over 4 hours, and working at generating 3-5MB per >> second, my compiler could produce 40-70GB of binary code in that time, > > That's a completely irrelevent metric. > For me it is entirely relevant, as the tools I use are linear. If my car averages 60mph, then after 4 hours I expect to do 240 miles.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 12:39 +0000 |
| Message-ID | <10e2amv$dkef$1@dont-email.me> |
| In reply to | #394971 |
On 30/10/2025 16:22, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 30/10/2025 14:13, Scott Lurndal wrote:
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>>> bart <bc@freeuk.com> wrote:
>>>>> On 29/10/2025 23:04, David Brown wrote:
>>>>>> On 29/10/2025 22:21, bart wrote:
>>>
>>>>>
>>>>> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are:
>>>>>
>>>>> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make
>>>>>> output
>>>>> <warnings>
>>>>> real 0m49.512s
>>>>> user 0m19.033s
>>>>> sys 0m3.911s
>>>>
>>>> Those numbers indicate that there is something wrong with your
>>>> machine. Sum of second and third line above give CPU time.
>>>> Real time is twice as large, so something is slowing down things.
>>>> One possible trouble is having too small RAM, then OS is swaping
>>>> data to/from disc. Some programs do a lot of random I/O, that
>>>> can be slow on spinning disc, but SSD-s usually are much
>>>> faster at random I/O.
>>>>
>>>> Assuming that you have enough RAM you should try at least using
>>>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote
>>>> at least, because AFAIK cheapest PC CPU-s of reasonable age
>>>> have at least 2 cores, so to fully utilize the machine you
>>>> need at least 2 jobs. 3 is better, because some jobs may wait
>>>> for I/O.
>>>>
>>>> FYI, reasonably typical report for normal make (without -j
>>>> option) on my machine is:
>>>>
>>>> real 0m4.981s
>>>> user 0m3.712s
>>>> sys 0m0.963s
>>>>
>>>
>>> Just for grins, here's a report for a full rebuild of a real-world project
>>> that I build regularly. Granted most builds are partial (e.g. one or
>>> two source files touched) and take far less time (15 seconds or so,
>>> most of which is make calling stat(2) on a few hundred source files
>>> on an NFS filesystem). Close to three million SLOC, mostly in header
>>> files. C++.
>>
>>
>> What is the total size of the produced binaries?
>
> There are 181 shared objects (DLL in windows speak) and
> six binaries produced by the build. The binaries are all quite small since
> they dynamically link at runtime with the necessary
> shared objects, the set of which can vary from run-to-run.
>
> The largest shared object is 7.5MB.
>
> text data bss dec hex filename
> 6902921 109640 1861744 8874305 876941 lib/libXXX.so
Well, I've done a couple of small tests.
The first was in generating 200 'small' DLLs - duplicates of the same
library. This took 6 seconds to produce 200 libraries of 50KB each (10MB
total). Each library is 5KB as it includes my language's standard libs.
The second was to compile a single program of 7.5MB. This was done by
taking one 300KB project and duplicating one of the bigger source
modules a large number of times (130 copies for the 4.5MB result).
However that ran into some problems; possibly, running out of memory (I
have 6GB available), or something. In any case it's not worth my time
looking at it right now.
I did manage to produce a 4.5MB executable, and that took about 1
second. The total source code was 500K (about 9 bytes per source line;
how about that!)
To summarise:
Generate 200 x 50KB DLLS: 6 seconds (1.7MB/s) (1000Kloc so 170Klps)
Generate 1 x 4.5MB EXE: 1 second (4.5MB/s) (500Kloc so 500Klps)
This is on a machine that David Brown suggested was hopelessly old and
slow. All source code compiled was in my language.
I then did the same test using an existing C port of that library, with:
gcc -O0 -s -shared libnnn.c -o libnnn.dll
It took 72 seconds, with each DLL now being 100KB. Source code is the
bare library so only 1.7Lloc, giving a throughput of 4.7Klps.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-31 13:57 +0000 |
| Message-ID | <4f3NQ.229706$RB68.85389@fx39.iad> |
| In reply to | #395007 |
bart <bc@freeuk.com> writes: >On 30/10/2025 16:22, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> >>> What is the total size of the produced binaries? >> >> There are 181 shared objects (DLL in windows speak) and >> six binaries produced by the build. The binaries are all quite small since >> they dynamically link at runtime with the necessary >> shared objects, the set of which can vary from run-to-run. >> >> The largest shared object is 7.5MB. >> >> text data bss dec hex filename >> 6902921 109640 1861744 8874305 876941 lib/libXXX.so > >Well, I've done a couple of small tests. Pointlessly. > >The first was in generating 200 'small' DLLs - duplicates of the same >library. This took 6 seconds to produce 200 libraries of 50KB each (10MB >total). Each library is 5KB as it includes my language's standard libs. The shared object 'text' size ranges from 500KB to 14MB. Your toy projects aren't representative of real world application development. Can you not understand that?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 14:55 +0000 |
| Message-ID | <10e2ill$ic0h$1@dont-email.me> |
| In reply to | #395010 |
On 31/10/2025 13:57, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 30/10/2025 16:22, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: > >>>> >>>> What is the total size of the produced binaries? >>> >>> There are 181 shared objects (DLL in windows speak) and >>> six binaries produced by the build. The binaries are all quite small since >>> they dynamically link at runtime with the necessary >>> shared objects, the set of which can vary from run-to-run. >>> >>> The largest shared object is 7.5MB. >>> >>> text data bss dec hex filename >>> 6902921 109640 1861744 8874305 876941 lib/libXXX.so >> >> Well, I've done a couple of small tests. > > Pointlessly. > >> >> The first was in generating 200 'small' DLLs - duplicates of the same >> library. This took 6 seconds to produce 200 libraries of 50KB each (10MB >> total). Each library is 5KB as it includes my language's standard libs. > > The shared object 'text' size ranges from 500KB to 14MB. Well, I asked for some figures, and they were lacking. And here, the 14MB figure contradicts the 7.5MB you mentioned above as the largest object. > Your toy projects aren't representative of real world application > development. Can you not understand that? I don't believe you. Clearly my tests show that basic conversion of HLL code to native code can be easily done at several MB per second even on my low-end hardware - per core. If your tests have a effective throughput far below that, then either you have very slow compilers, or are doing a mountain of work unrelated to compiling, or the orchestration of the whole process is poor, or some combination. (You mentioned there are nearly 400 developers involved? It sounds like a management problem. Perhaps you should employ someone whose job it is to look at the big picture, and to get those iteration times down.) In any case, the tasks I want to build are nothing like that, yet there is at least 2 magnitudes difference in build-time between my 'toy' tools, and all that Unix stuff that you are all trying to force down my throat.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-31 17:18 +0000 |
| Message-ID | <1c6NQ.86735$P8zb.24318@fx04.iad> |
| In reply to | #395011 |
bart <bc@freeuk.com> writes: >On 31/10/2025 13:57, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 30/10/2025 16:22, Scott Lurndal wrote: >>>> bart <bc@freeuk.com> writes: >> >>>>> >>>>> What is the total size of the produced binaries? >>>> >>>> There are 181 shared objects (DLL in windows speak) and >>>> six binaries produced by the build. The binaries are all quite small since >>>> they dynamically link at runtime with the necessary >>>> shared objects, the set of which can vary from run-to-run. >>>> >>>> The largest shared object is 7.5MB. >>>> >>>> text data bss dec hex filename >>>> 6902921 109640 1861744 8874305 876941 lib/libXXX.so >>> >>> Well, I've done a couple of small tests. >> >> Pointlessly. >> >>> >>> The first was in generating 200 'small' DLLs - duplicates of the same >>> library. This took 6 seconds to produce 200 libraries of 50KB each (10MB >>> total). Each library is 5KB as it includes my language's standard libs. >> >> The shared object 'text' size ranges from 500KB to 14MB. > >Well, I asked for some figures, and they were lacking. And here, the >14MB figure contradicts the 7.5MB you mentioned above as the largest object. The 7.5MB was the shared object containing the main code. 14MB was one outlier that I hadn't expected to be so large a text region (am actually looking into that now, I suspect the gcc optimizer doesn't handle a particular bit of generated data structure initialization sequence very well). $ size lib/*.so | cut -f 1 text 367395 8053916 8053916 8053916 22385 134993 6902921 719346 33698635 36084944 19501560 3869694 73570 211384 126472 44610 90992 69081 287447 5308581 12213437 11228898 6166468 116563 63242 71842 480359 30823 315595 552362 111956 111956 951445 1457999 29053 2388204 348969 150472 219346 49420 750129 120295 138622 868002 117492 142438 489431 595478 151900 265009 112371 234140 52977 1152928 567153 614616 151578 181964 14798814 657231 29984 145595 90394 46204 276076 38248 25649 81913 93313 328478 70278 31539 387492 1885298 144763 51537 37037 44668 167946 4726570 2472426 95714 29547 24790 55887 76059 47813 78769 136931 65500 323558 2757388 465288 707782 240259 69803 109695 91664 47862 629404 738060 155033 281246 397902 66721 49279 124507 148506 320033 81491 131769 252140 156101 118933 1777033 353799 534605 96492 143886 254192 26850 54655 106790 56512 87201 230382 792823 314391 37951 274781 1149389 25851 131519 108052 96303 338036 175900 61630 138460 189483 116789 340759 31324 25293 32149 26870 78069 1494212 427356 237699 30062440 577998 14611 57346 8724 12007 16053 429021 25367738 35760664 593138 30982 10087 6552 20032 6539 6738 6738 15262923 145335 4997 42188 11129 11321 7671 8521 8521 11756 15872 11076 23053 A couple are third-party libraries distributed in binary form (e.g. the ones with 30+Mbytes of text). > > >> Your toy projects aren't representative of real world application >> development. Can you not understand that? > >I don't believe you. Clearly my tests show that basic conversion of HLL >code to native code can be easily done at several MB per second even on >my low-end hardware - per core. > >If your tests have a effective throughput far below that, then either >you have very slow compilers, or are doing a mountain of work unrelated >to compiling, or the orchestration of the whole process is poor, or some >combination. Or your tools are not capable of building a project of this size and complexity. If they were, they'd likely take even _more_ time to run. > >(You mentioned there are nearly 400 developers involved? It sounds like >a management problem. I said nothing about the number of developers (perhaps you were looking at the output of the 'sloccount' command?) Between 2 and 8 developers have worked on this project at any one time over the last 15 years.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 17:52 +0000 |
| Message-ID | <10e2t0n$lsc5$1@dont-email.me> |
| In reply to | #395014 |
On 31/10/2025 17:18, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 31/10/2025 13:57, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >>>> On 30/10/2025 16:22, Scott Lurndal wrote: >>>>> bart <bc@freeuk.com> writes: >>> >>>>>> >>>>>> What is the total size of the produced binaries? >>>>> >>>>> There are 181 shared objects (DLL in windows speak) and >>>>> six binaries produced by the build. The binaries are all quite small since >>>>> they dynamically link at runtime with the necessary >>>>> shared objects, the set of which can vary from run-to-run. >>>>> >>>>> The largest shared object is 7.5MB. >>>>> >>>>> text data bss dec hex filename >>>>> 6902921 109640 1861744 8874305 876941 lib/libXXX.so >>>> >>>> Well, I've done a couple of small tests. >>> >>> Pointlessly. >>> >>>> >>>> The first was in generating 200 'small' DLLs - duplicates of the same >>>> library. This took 6 seconds to produce 200 libraries of 50KB each (10MB >>>> total). Each library is 5KB as it includes my language's standard libs. >>> >>> The shared object 'text' size ranges from 500KB to 14MB. >> >> Well, I asked for some figures, and they were lacking. And here, the >> 14MB figure contradicts the 7.5MB you mentioned above as the largest object. > > The 7.5MB was the shared object containing the main code. 14MB > was one outlier that I hadn't expected to be so large a text region (am > actually looking into that now, I suspect the gcc optimizer doesn't handle > a particular bit of generated data structure initialization sequence very well). > > $ size lib/*.so | cut -f 1 > > text > 367395 > 8053916 > > A couple are third-party libraries distributed > in binary form (e.g. the ones with 30+Mbytes of text). In sorted form: 1 4,997 bytes 2 6,539 3 6,552 ... 178 30,062,440 179 33,698,635 180 35,760,664 181 36,084,944 About 330MB, or 260MB if disregarding the two biggest. That's quite substantial, but still, going with my test which built 4.5MB in one second, 60 such builds would take a minute, totalling a 260MB. Say add a bit more if split into 180 separate builds. And that is if done one at a time. So I still contend that the basic translation can still be done in a reasonable time, /if/ you really had to rebuild everything. (When I rebuild everything, it's because a module is part of one executable, so that whole binary must be rebuilt.) >> If your tests have a effective throughput far below that, then either >> you have very slow compilers, or are doing a mountain of work unrelated >> to compiling, or the orchestration of the whole process is poor, or some >> combination. > > Or your tools are not capable of building a project of this size > and complexity. If they were, they'd likely take even _more_ time > to run. Perhaps not, but so what? I've always developed tools according to the tasks and circumstances that were relevant to me. And usually, for building my own software. They just happen to also be a great deal zippier in operation when compared with other tools for building the same codebases. I'm pretty certain they have inefficiences that someone could address if they wanted to, or could choose to find streamlined paths if a fast turnaround was desirable. That's why I said it should be somebody's job to do that, in the same way that I considered it part of my job to ensure my development process wasn't slow enough to slow me down. If I'm twiddling my thumbs, then something's wrong! >> >> (You mentioned there are nearly 400 developers involved? It sounds like >> a management problem. > > I said nothing about the number of developers (perhaps you were looking > at the output of the 'sloccount' command?) Yes. (I'm not sure what that was about.) > Between 2 and 8 developers have worked on this project > at any one time over the last 15 years. You might want to clear out some cruft then.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2025-10-30 05:00 +0100 |
| Message-ID | <10dunsf$1rp3$1@news.gegeweb.eu> |
| In reply to | #394952 |
On 10/30/25 01:36, bart wrote:
>
> You'd probably dismiss it as irrelevant, but lots of such improvements
> build up. At least it is good that some people are looking at such aspects.
>
> https://cppalliance.org/mizvekov,/clang/2025/10/20/Making-Clang-AST-
> Leaner-Faster.html)
>
This page is about C++, not C. It was irrelevant in
this newsgroup. Try again, Bart.
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 11:15 +0100 |
| Message-ID | <10dvdrr$3jh71$1@dont-email.me> |
| In reply to | #394952 |
On 30/10/2025 01:36, bart wrote: > On 29/10/2025 23:04, David Brown wrote: >> On 29/10/2025 22:21, bart wrote: > >>> It was certainly an issue here: the 'make' part of building CDECL and >>> A68G, I considered slow for the scale of the task given that the apps >>> are 68 and 78Kloc (static total of .c and .h files). >>> >> >> I have no interest in A68G. I have no stake in cdecl or knowledge (or >> particular interest) in how it was written, and how appropriate the >> number of lines of code are for the task in hand. I am confident it >> could have been written in a different way with less code - but not at >> all confident that doing so would be in any way better for the author >> of the program. I am also confident that you know far too little >> about what the program can do, or why it was written the way it was, >> to judge whether it has a "reasonable" number of lines of code, or not. >> >> However, it's easy to look at the facts. The "src" directory from the >> github clone has about 50,000 lines of code in .c files, and 18,000 >> lines of code in .h files. The total is therefore about 68 kloc of >> source. This does not at all mean that compilation processes exactly >> 68 thousand lines of code - it will be significantly more than that as >> headers are included by multiple files, and lots of other headers from >> the C standard library and other libraries are included. Let's guess >> 100 kloc. > > Yes, that's why I said the 'static' line counts are 68 and 78K. Maybe > the slowdown is due to some large headers that lie outside the problem > (not the standard headers), but so what? (That would be a shortcoming of > the C language.) > > The A68G sources also contain lots of upper-case content, so perhaps > macro expansion is going on too. > > The bottom line is this is an 80Kloc app that takes that long to buidld. No, the bottom line is that this program took longer to build than you expected or wanted. Did the build time affect whether or not you use A68G ? If not, then it does /not/ take too long to build, even on your system. Of course you might feel it takes longer than you expect, or frustratingly long - that's up to you, your opinions, and your expectations. > >> >> The build process takes 8 seconds on my decade-old machine, much of >> which is something other than running the compiler. (Don't ask me >> what it is doing - I did not write this software, design its build >> process, or determine how the program is structured and how it is >> generated by yacc or related tools. This is not my area of >> expertise.) If for some strange reason I choose to run "make" rather >> than "make -j", thus wasting much of my computer's power, it takes 16 >> seconds. Some of these non-compilation steps do not appear to be able >> to run in parallel, and a couple of the compilations (like "parser.c", >> which appears to be from a parser generator rather than specifically >> written) are large and take a couple of seconds to compile. My guess >> is that the actual compilations are perhaps 4 seconds. Overall, I >> make it 25 kloc per second. While I don't think that is a >> particularly relevant measure of anything useful, it does show that >> either you are measuring the wrong thing, using a wildly inappropriate >> or limited build environment, or are unaware of how to use your >> computer to build code. > > Tell me then how I should do it to get single-figure build times for a > fresh build. But whatever it is, why doesn't it just do that anyway?! > Try "make -j" rather than "make" to build in parallel. That is not the default mode for make, because you don't lightly change the default behaviour of a program that millions use regularly and have used over many decades. Some build setups (especially very old ones) are not designed to work well with parallel building, so having the "safe" single task build as the default for make is a good idea. I would also, of course, recommend Linux for these things. Or get a cheap second-hand machine and install Linux on that - you don't need anything fancy. As you enjoy comparative benchmarks, the ideal would be duplicate hardware with one system running Windows, the other Linux. (Dual boot is a PITA, and I am not suggesting you mess up your normal daily use system.) Raspberry Pi's are great for lots of things, but they are not fast for building software - most models have too little memory to support all the cores in big parallel builds, they can overheat when pushed too far, and their "disks" are very slow. If you have a Pi 5 with lots of ram, and use a tmpfs filesystem for the build, it can be a good deal faster. >> (And my computer cpu was about 30% busy doing other productive tasks, >> such as playing a game, while I was doing those builds.) >> >> >> So, you are exaggerating, mismeasuring or misusing your system to get >> build times that are well over an order of magnitude worse than >> expected. This follows your well-established practice. > > So, what exactly did I do wrong here (for A68G): > > root@DESKTOP-11:/mnt/c/a68g/algol68g-3.10.5# time make >output > real 1m32.205s > user 0m40.813s > sys 0m7.269s > > This 90 seconds is the actual time I had to hang about waiting. I'd be > interested in how I managed to manipulate those figures! Try "time make -j" as a simple step. > > BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are: > > root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make > >output > <warnings> > real 0m49.512s > user 0m19.033s > sys 0m3.911s > > On the RPi4 (usually 1/3 the speed of my PC), the make-time for A68G was > 137 seconds (using SD storage; the PC uses SSD), so perhaps 40 seconds > on the PC, suggesting that the underlying Windows file system may be > slowing things down, but I don't know. > > However the same PC, under actual Windows, manages this: > > c:\qx>tim mm qq > Compiling qq.m to qq.exe (500KB but half is data; A68G is 1MB?) > Time: 0.084 > > And this: > > c:\cx>tim tcc lua.c (250-400KB) > Time: 0.124 > Windows is a fine system in some ways, but it has different strengths and weaknesses compared to Linux. There are plenty of things Windows handles better than Linux in a very general sense. Here, however, there are two things that Linux (and all *nix style OS's) does significantly better than Windows - it has much more efficient filesystems, especially when dealing with lots of files at once, and it is much more efficient at starting and stopping processes and running lots of processes at once. gcc, make, and other tools used in the build of ccdecl (again, I have not looked at A68G) come from a world where big tasks are broken down into many little tasks. When you run a "gcc" command, even just for a compile (without linking), it will run a number of different programs - starting and stopping multiple processes. That is cheap on Linux, but a significant overhead on Windows. They communicate with temporary files - cheap on Linux (they are never written to a disk), but expensive on Windows. Similarly, the typical C libraries on Linux are happy to use multiple files because doing so is cheap on Linux - but much more expensive on Windows. (A single "#include <stdio.h>" C file on my Linux system uses 20 headers, totalling 3536 lines.) There are good reasons for breaking things into small parts like this, for better maintainability, scalability, portability and flexibility. However, it means that these things are all slower on Windows systems. Software that originates in the Windows world tends to be more monolithic - you make one big program that does everything, you make C library headers that are combined to avoid extra includes, and so on. Portability and scalability don't matter so much in a monoculture, and flexibility and reuse don't matter when toolchain developers are closed companies. (By that I mean that in the *nix world, some of the headers will be shared across multiple different C standard libraries, different C compilers, different OS's, and different target architectures in any combination.) I am not saying that one way is "right" and the other way is "wrong" - I am saying they are significantly different, and this can be a reason why certain kinds of big software systems can have very different performance characteristics on *nix systems and Windows. >> And you claim your own tools would be 1000 times faster. > > In this case, yes. The figure is more typically around 100 if the other > compiler is optimising, however that would be representations of the > same program. A68G is somewhat bigger than my product. > >> Maybe they would be. Certainly there have been tools in the past >> that are much smaller and faster than modern tools, and were useful at >> the time. Modern tools do so much more, however. A tool that doesn't >> do the job needed is of no use for a given task, even if it could >> handle other tasks quickly. > > It ran my test program; that's what counts! If a tool does the job you need, and does so efficiently, that's great. > > > > >> >> But the crux of the matter, and I can't stress this enough as it never >> seems to get through to you, is that fast enough is fast enough. No >> one cares how long cdecl takes to build. > > I don't care either; I just wanted to try it. > > But I pick up things that nobody else seems to: this particular build > was unusually slow; why was that? Perhaps there's a bottleneck in the > process that needs to be fixed, or a bug, that would give benefits when > it does matter. Do you think there is a reason why /you/ get fixated on these things, and no one else in this group appears to be particularly bothered? Could it be that these things are not actually a problem to other people? You have never given any indication that you are interested in identifying bottlenecks or slowdowns, and have certainly shown no interest in fixing them or even just reporting them to anyone of relevance (like the guy who wrote cdecl, or the authors of autotools, or the gcc developers, or whoever might be at least vaguely connected with the process). I am sure there are lots of people here who - if they bothered to build cdecl at all - might think the build took longer than they would have guessed. But no one else has whined about it. Usually when a person thinks that they are seeing something no one else sees, they are wrong. (Look at Olcott for an extreme example.) And if if there had ever been a regular in comp.lang.c who was once unaware that there are C compilers that can compile faster than gcc, or that autotools is outdated and probably unnecessary in most cases, you can be sure they have heard your message enough times already. > > (An article posted in Reddit detailed how a small change in how Clang > worked made a 5-7% difference in build times for large projects. > > You'd probably dismiss it as irrelevant, but lots of such improvements > build up. At least it is good that some people are looking at such aspects. > > https://cppalliance.org/mizvekov,/clang/2025/10/20/Making-Clang-AST-Leaner-Faster.html) > I am very happy that people make compilers faster. For me, personally, the biggest benefit clang has brought to my work is that the competition and cooperation with gcc has encouraged improvements to gcc - functional improvements such as better static warnings, and faster compilation. And I fully understand that build times for large projects are important, especially during development. But I do not share your obsession that compile and build times are the critical factor or the defining feature for a compiler (or toolchain in general). In my experience - /my/ experience - compile times for C code has never been an issue. I have never felt the urge to use a different compiler because the one I am using is too slow. I have never felt it made sense to use -O0 rather than -O2 (or whatever I choose as appropriate for the task in hand) because of compiler speed. I have never felt that I won't use a particular piece of software because the build step took too long. I have certainly found that it can be /nicer/ to have faster compiles or builds. I have certainly found it worth the effort to do builds efficiently - if I had to recompile all code for all files in my projects every time I made a small change, then build speed would become a problem. And I have occasionally done builds (such as full builds of embedded Linux systems) that take a long time - these would be frustrating if I had to do them regularly. And again, I am always glad when my tools run faster - but that does not mean I have a problem with them being too slow. I know you find it very difficult to understand that concept. > >> Of course everyone agrees that smaller and faster is better, all >> things being equal - but all things are usually /not/ equal, and once >> something is fast enough to be acceptable, making it faster is not a >> priority. > > My compilers have already reached that threshold (most stuff builds in > the time it takes to take my finger off the Enter button). But most > mainstream compilers are a LONG way off. > This is not a goal most compiler vendors have. When people are not particularly bothered about the speed of compilation for their files, the speed is good enough - people are more interested in other things. They are more interested in features like better checks, more helpful warnings or information, support for newer standards, better optimisation, and so on. Mainstream compiler vendors do care about speed - but not about the speed of the little C programs you write and compile. They put a huge amount of effort into the speed for situations where it matters, such as for building very large projects, or building big projects with advanced optimisations (like link-time optimisations across large numbers of files and modules), or working with code that is inherently slow to compile (like C++ code with complex templates or significant compile-time compilation).
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 12:07 +0000 |
| Message-ID | <10dvkek$3lk42$1@dont-email.me> |
| In reply to | #394962 |
On 30/10/2025 10:15, David Brown wrote:
> On 30/10/2025 01:36, bart wrote:
> Try "make -j" rather than "make" to build in parallel. That is not the
> default mode for make, because you don't lightly change the default
> behaviour of a program that millions use regularly and have used over
> many decades. Some build setups (especially very old ones) are not
> designed to work well with parallel building, so having the "safe"
> single task build as the default for make is a good idea.
>
> I would also, of course, recommend Linux for these things. Or get a
> cheap second-hand machine and install Linux on that - you don't need
> anything fancy. As you enjoy comparative benchmarks, the ideal would be
> duplicate hardware with one system running Windows, the other Linux.
> (Dual boot is a PITA, and I am not suggesting you mess up your normal
> daily use system.)
>
> Raspberry Pi's are great for lots of things, but they are not fast for
> building software - most models have too little memory to support all
> the cores in big parallel builds, they can overheat when pushed too far,
> and their "disks" are very slow. If you have a Pi 5 with lots of ram,
> and use a tmpfs filesystem for the build, it can be a good deal faster.
>
>>> (And my computer cpu was about 30% busy doing other productive tasks,
>>> such as playing a game, while I was doing those builds.)
>>>
>>>
>>> So, you are exaggerating, mismeasuring or misusing your system to get
>>> build times that are well over an order of magnitude worse than
>>> expected. This follows your well-established practice.
>>
>> So, what exactly did I do wrong here (for A68G):
>>
>> root@DESKTOP-11:/mnt/c/a68g/algol68g-3.10.5# time make >output
>> real 1m32.205s
>> user 0m40.813s
>> sys 0m7.269s
>>
>> This 90 seconds is the actual time I had to hang about waiting. I'd be
>> interested in how I managed to manipulate those figures!
>
> Try "time make -j" as a simple step.
OK, "make -j" gave a real time of 30s, about three times faster. (Not
quite sure how that works, given that my machine has only two cores.)
However, I don't view "-j", and parallelisation, as a solution to slow
compilation. It is just a workaround, something you do when you've
exhausted other possibilities.
You have to get raw compilation fast enough first.
Suppose I had the task of transporting N people from A to B in my car,
but I can only take four at a time and have to get them there by a
certain time.
One way of helping out is to use "-j": get multiple drivers with their
own cars to transport them in parallel.
Imagine however that my car and all those others can only go at walking
pace: 3mph instead of 30mph. Then sure, you can recruit enough
volunteers to get the task done in the necessary time (putting aside the
practical details).
But can you a see a fundamental problem that really ought to be fixed first?
>> But I pick up things that nobody else seems to: this particular build
>> was unusually slow; why was that? Perhaps there's a bottleneck in the
>> process that needs to be fixed, or a bug, that would give benefits
>> when it does matter.
>
> Do you think there is a reason why /you/ get fixated on these things,
> and no one else in this group appears to be particularly bothered?
> Usually when a person thinks that they are seeing something no one else
> sees, they are wrong.
Quite a few people have suggested that there is something amiss about my
1:32 and 0:49 timings. One has even said there is something wrong with
my machine.
You have even suggested I have manipulated the figures!
So was I right in sensing something was off, or not?
> And I fully understand that build times for large projects are
> important, especially during development.
>
> But I do not share your obsession that compile and build times are the
> critical factor or the defining feature for a compiler (or toolchain in
> general).
I find fast compile-times useful for several reasons:
*I develop whole-program compilers* This means all sources have to be
compiled at the same time, as there is no independent compilation at the
module level.
The advantage is that I don't need the complexity of makefiles to help
decide which dependent modules need recompiling.
*It can allow programs to be run directly from source* This is something
that is being explored via complex JIT approaches. But my AOT compiler
is fast enough that that is not necessary
*It also allow programs to be interpreted* This is like run from source,
but the compilation is faster as it can stop at the IL. (Eg. sqlite3
compiles in 150ms instead of 250ms.)
*It can allow whole-program optimisation* This is not something I take
advantage of much yet. But it allows a simpler approach than either LTO,
so somehow figuring out to create a one-file amalgamation.
So it enables interesting new approaches. Imagine if you download the
CDECL bundle and then just run it without needing to configure anything,
or having to do 'make', or 'make -j'.
This is a demo which runs my C compiler instead of a CDECL. The C
compiler source bundle is the file cc.ma (created using 'mm -ma cc'):
c:\demo>dir
30/10/2025 11:31 648,000 cc.ma
26/09/2025 14:44 60 hello.c
Now I run my C compiler from source:
c:\demo>mm -r cc hello
Compiling cc.m to cc.(run)
Compiling hello.c to hello.exe
Magic! Or, since 'cc' also shares the same backend as 'mm', it can also
run stuff from source (but is limited to single file C programs):
c:\demo>mm -r cc -r hello
Compiling cc.m to cc.(run)
Compiling hello.c to hello.(run)
Hello, World!
Forget ./configure, forget make. Of course you can do the same thing,
maybe there is 'make -run', the difference is that the above is instant.
> This is not a goal most compiler vendors have. When people are not
> particularly bothered about the speed of compilation for their files,
> the speed is good enough - people are more interested in other things.
> They are more interested in features like better checks, more helpful
> warnings or information, support for newer standards, better
> optimisation, and so on.
See the post from Richard Heathfield where he is pleasantly surprised
that he can get a 60x speedup in build-time.
People like fast tools!
> Mainstream compiler vendors do care about speed - but not about the
> speed of the little C programs you write and compile. They put a huge
> amount of effort into the speed for situations where it matters, such as
> for building very large projects, or building big projects with advanced
> optimisations (like link-time optimisations across large numbers of
> files and modules), or working with code that is inherently slow to
> compile (like C++ code with complex templates or significant compile-
> time compilation).
I think some 90% at least of the EXE/DLL files in my Windows\System32
folder are under 1MB in size. That would be approx 100Kloc of C, or under.
We've seen how long programs of 1MB and 0.6GB (apparent stripped sizes
of A68G and CDECL) can take to build. Or do those count as 'little'?
Anyway, the approaches used to speed up compilation of smaller programs
can also help larger ones.
(A few years ago, my main compiler was written in my intepreted
scripting language, so it was very slow IMV. However it was still double
the speed of gcc -O0! While generating equally indifferent code.
So I say something is wrong.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 16:04 +0100 |
| Message-ID | <10dvuqk$3oop2$1@dont-email.me> |
| In reply to | #394964 |
On 30/10/2025 13:07, bart wrote: > On 30/10/2025 10:15, David Brown wrote: >> On 30/10/2025 01:36, bart wrote: > >> Try "make -j" rather than "make" to build in parallel. That is not >> the default mode for make, because you don't lightly change the >> default behaviour of a program that millions use regularly and have >> used over many decades. Some build setups (especially very old ones) >> are not designed to work well with parallel building, so having the >> "safe" single task build as the default for make is a good idea. >> >> I would also, of course, recommend Linux for these things. Or get a >> cheap second-hand machine and install Linux on that - you don't need >> anything fancy. As you enjoy comparative benchmarks, the ideal would >> be duplicate hardware with one system running Windows, the other >> Linux. (Dual boot is a PITA, and I am not suggesting you mess up your >> normal daily use system.) >> >> Raspberry Pi's are great for lots of things, but they are not fast for >> building software - most models have too little memory to support all >> the cores in big parallel builds, they can overheat when pushed too >> far, and their "disks" are very slow. If you have a Pi 5 with lots of >> ram, and use a tmpfs filesystem for the build, it can be a good deal >> faster. >> >>>> (And my computer cpu was about 30% busy doing other productive >>>> tasks, such as playing a game, while I was doing those builds.) >>>> >>>> >>>> So, you are exaggerating, mismeasuring or misusing your system to >>>> get build times that are well over an order of magnitude worse than >>>> expected. This follows your well-established practice. >>> >>> So, what exactly did I do wrong here (for A68G): >>> >>> root@DESKTOP-11:/mnt/c/a68g/algol68g-3.10.5# time make >output >>> real 1m32.205s >>> user 0m40.813s >>> sys 0m7.269s >>> >>> This 90 seconds is the actual time I had to hang about waiting. I'd >>> be interested in how I managed to manipulate those figures! >> >> Try "time make -j" as a simple step. > > > OK, "make -j" gave a real time of 30s, about three times faster. (Not > quite sure how that works, given that my machine has only two cores.) You presumably understand how multi-tasking works when there are more processes than there are cores to run them. Sometimes you have more processes ready to run, in which case some have to wait. But sometimes processes are already waiting for something else (typically disk I/O here, but it could be networking or other things). So while one compile task is waiting for the disk, another one can be running. It's not common for the speedup from "make -j" or "make -j N" for some number N to be greater than the number of cores, but it can happen for small numbers of cores and slow disk. > > However, I don't view "-j", and parallelisation, as a solution to slow > compilation. It is just a workaround, something you do when you've > exhausted other possibilities. You moan that compiles are too slow. Yet doing them in parallel is a "workaround". Avoiding compiling unnecessarily is a "workaround". Caching compilation work is a "workaround". Using a computer from this century is a "workaround". Using a decent OS is a "workaround". Is /everything/ that would reduce your scope for complaining loudly to the wrong people a workaround? Of course this kind of thing does not change the fundamental speed of the compiler, but it is very much a solution to problems, frustration or issues that people might have from compilers being slower than they might want. "make -j" does not make the compiler faster, but it does mean that the speed of the compiler is less of an issue. > > You have to get raw compilation fast enough first. Why? And - again - the "raw" compilation of gcc on C code, for my usage, is already more than fast enough for my needs. If it were faster, I would still use make. If it ran at 1 MLOC per second, I'd still use make, and I'd still structure my code the same way, and I'd still run on Linux. I would be happy to see gcc run at that speed, but it would not change how I work. > > Suppose I had the task of transporting N people from A to B in my car, > but I can only take four at a time and have to get them there by a > certain time. > > One way of helping out is to use "-j": get multiple drivers with their > own cars to transport them in parallel. > > Imagine however that my car and all those others can only go at walking > pace: 3mph instead of 30mph. Then sure, you can recruit enough > volunteers to get the task done in the necessary time (putting aside the > practical details). > > But can you a see a fundamental problem that really ought to be fixed > first? Sure - if that were realistic. But a more accurate model is that the cars go at 30 mph - the people will all get there safely, comfortably and in a reasonable time, and if there are lots of people you can scale by using more cars in parallel so that the real-world time taken is not much different. Your alternative is an electric scooter trimmed to go at 600 mph. Yes, it is faster for an individual, but is it really /better/? I'm sure we'd all be pleased if the car went at 60 mph rather than 30 mph, but the speed of the vehicle is not the only thing that affects the throughput of your transport system. There is no logical reason to focus solely on speed of one individual part of a large process when there are other ways to improve the speed of the process as a whole. > > >>> But I pick up things that nobody else seems to: this particular build >>> was unusually slow; why was that? Perhaps there's a bottleneck in the >>> process that needs to be fixed, or a bug, that would give benefits >>> when it does matter. >> >> Do you think there is a reason why /you/ get fixated on these things, >> and no one else in this group appears to be particularly bothered? > >> Usually when a person thinks that they are seeing something no one >> else sees, they are wrong. > > Quite a few people have suggested that there is something amiss about my > 1:32 and 0:49 timings. One has even said there is something wrong with > my machine. > Maybe there /is/ something wrong with your machine or setup. If you have a 2 core machine, it is presumably a low-end budget machine from perhaps 15 years ago. I'm all in favour of keeping working systems and I strongly disapprove of some people's two or three year cycles for swapping out computers, but there is a balance somewhere. With such an old system, I presume you also have old Windows (my office Windows machine is Windows 7), and thus the old and very slow style of WSL. That, I think, could explain the oddities in your timings. > You have even suggested I have manipulated the figures! No, I did not. I have at various times suggested that you cherry-pick, that you might have poor methodology and that you sometimes benchmark in an unrealistic way in order to give yourself a bigger windmill for your tilting. (Timing a build on an old slow WSL layer on Windows on old slow hardware is an example of this - the typical user who would compile something like cdecl from source will be using some flavour of *nix and a computer suitable for software development.) > > So was I right in sensing something was off, or not? > You were wrong in thinking something was off about cdecl or its build. And it should not be news to you that there is something very suboptimal about your computer environment, as this is not exactly the first time it has been discussed. >> And I fully understand that build times for large projects are >> important, especially during development. >> >> But I do not share your obsession that compile and build times are the >> critical factor or the defining feature for a compiler (or toolchain >> in general). > > I find fast compile-times useful for several reasons: Everyone who compiles code finds faster compile times nicer than slower compile times. That is not the point. The issue is about fast /enough/ compiles, and fast /enough/ builds. But of course I am quite happy to accept that fast compile times are important to you - your preferences and opinions are your own. The issue is that you can't accept other people have different priorities and experiences. > > *I develop whole-program compilers* This means all sources have to be > compiled at the same time, as there is no independent compilation at the > module level. OK. I have sometimes used whole-program compilation. It is naturally slower, but is helped by good tools (such as toolchains that support so-called "link-time optimisation"). And improving the speed of LTO - particularly by improving the parallelisation of the task across multiple cores - is a key focus for gcc and clang/llvm for speed. > > The advantage is that I don't need the complexity of makefiles to help > decide which dependent modules need recompiling. People use make for many reasons - incremental building and dependency management is just one (albeit important) aspect. You mentioned in another post that "Python does not need make" - I have Python projects that are organised by makefiles. And honestly, if you had taken 1% of the time and effort you have spend complaining in c.l.c. about "make" and instead learned about it, you'd be writing makefiles in your sleep. It really is not that hard, and you will never convince me you are not smart enough to understand it quickly and easily. > > *It can allow programs to be run directly from source* This is something > that is being explored via complex JIT approaches. But my AOT compiler > is fast enough that that is not necessary I don't see what that is at all important for C programming. Why would someone want to use C for scripting? If I had a C file "test.c" that was short enough to be realistic for use as a script, and did not care about optimisation or static checking, I could just type "make test && ./test" to run it pretty much instantly. > > *It also allow programs to be interpreted* This is like run from source, > but the compilation is faster as it can stop at the IL. (Eg. sqlite3 > compiles in 150ms instead of 250ms.) Faster compiles do not change anything fundamental about a language. They do not mean that C programs are interpreted, they mean that C programs compile faster. > > *It can allow whole-program optimisation* This is not something I take > advantage of much yet. But it allows a simpler approach than either LTO, > so somehow figuring out to create a one-file amalgamation. > I can fully appreciate that as a compiler /writer/, you want a simpler system than LTO. As a compiler /user/, like the vast majority of programmers, I don't really care how complicated the compiler is. That is someone else's job. > So it enables interesting new approaches. Imagine if you download the > CDECL bundle and then just run it without needing to configure anything, > or having to do 'make', or 'make -j'. Almost everyone who uses cdecl does that already. Enthusiasts living on the cutting edge need to spend a couple of minutes downloading and building the latest versions, but other people will use pre-built binaries. And those people are already very familiar with the "./configure && make -j 8 && sudo make install" sequence. > > Forget ./configure, forget make. Of course you can do the same thing, > maybe there is 'make -run', the difference is that the above is instant. To be clear - I do think autotools is usually unnecessary, overly complex, slow, and long outdated. There are some kinds of projects where it could be a definite benefit - typically those for which there are a lot of configuration options that people might want in their builds, and it gives a lot of them out of the box. But I think there's a lot of potential at least for skipping almost all ./configure tests on almost all systems without losing the advantages and features of autotools. However, it's up to the project authors to decide if they want to use autotools or not, and the cost of ten seconds of my time does not bother me here. > >> This is not a goal most compiler vendors have. When people are not >> particularly bothered about the speed of compilation for their files, >> the speed is good enough - people are more interested in other things. >> They are more interested in features like better checks, more helpful >> warnings or information, support for newer standards, better >> optimisation, and so on. > > See the post from Richard Heathfield where he is pleasantly surprised > that he can get a 60x speedup in build-time. > There were no details in that post - I suspect it was not /entirely/ serious. > People like fast tools! Sure. I haven't seen anyone suggest otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-30 18:30 +0200 |
| Message-ID | <20251030183001.00000129@yahoo.com> |
| In reply to | #394970 |
On Thu, 30 Oct 2025 16:04:51 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 30/10/2025 13:07, bart wrote: > > > > > > OK, "make -j" gave a real time of 30s, about three times faster. > > (Not quite sure how that works, given that my machine has only two > > cores.) > > You presumably understand how multi-tasking works when there are more > processes than there are cores to run them. Sometimes you have more > processes ready to run, in which case some have to wait. But > sometimes processes are already waiting for something else (typically > disk I/O here, but it could be networking or other things). So while > one compile task is waiting for the disk, another one can be running. > It's not common for the speedup from "make -j" or "make -j N" for > some number N to be greater than the number of cores, but it can > happen for small numbers of cores and slow disk. > It *can* give much higher speedup than the number of cores. Measurements taken at relatively small MCU project: 33 modules, size: text data bss dec hex filename 26953 156 28028 55137 d761 Compiled on my corporate desktop. Good hardware (Intel i7-17700, 8 P cores, 12 E cores, 28 logical CPUs, competent SSD : Samsung PM9F1). Bad software environment - very aggressive antivirus + 2 other "management" crapware agents. msys2, arm-none-eabi-gcc 13.3.0 2nd column: execution time with all cores enabled. 3rd column: execution time with compilation locked to single logical CPU (P-core). 4th column: execution time with compilation locked to single logical CPU (E-core). flags tm-all tm-one-P tm-one-E none 0m20.689s 0m21.162s 0m44.608s -j 2 0m9.464s 0m11.199s 0m34.154s -j 3 0m6.855s 0m8.695s -j 4 0m4.970s 0m7.992s 0m21.895s -j 5 0m4.429s 0m7.632s -j 6 0m4.016s 0m7.340s -j 7 0m3.766s 0m7.296s -j 8 0m3.564s 0m7.248s -j 9 0m3.439s 0m7.245s 0m20.323s -j 10 0m3.562s 0m7.324s -j 28 0m3.741s 0m7.295s -j 33 0m3.623s 0m7.128s 0m18.098s -j 0m3.843s 0m7.187s 0m19.365s So, on P-core I see almost 3x speed up from simultaneity even with no actual parallelism.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 17:49 +0000 |
| Message-ID | <10e08fa$3rtue$1@dont-email.me> |
| In reply to | #394970 |
On 30/10/2025 15:04, David Brown wrote: > On 30/10/2025 13:07, bart wrote: > You moan that compiles are too slow. Yet doing them in parallel is a > "workaround". Avoiding compiling unnecessarily is a "workaround". > Caching compilation work is a "workaround". Using a computer from this > century is a "workaround". Using a decent OS is a "workaround". Is / > everything/ that would reduce your scope for complaining loudly to the > wrong people a workaround? Yes, they are all workarounds to cope with unreasonably slow compilers. They in fact all come across as excuses for your favorite compiler being slow. Which one of these methods would you use to advertise the LPS throughput of a compiler that you develop? > > Of course this kind of thing does not change the fundamental speed of > the compiler, but it is very much a solution to problems, frustration or > issues that people might have from compilers being slower than they > might want. "make -j" does not make the compiler faster, but it does > mean that the speed of the compiler is less of an issue. > >> >> You have to get raw compilation fast enough first. > > Why? And - again - the "raw" compilation of gcc on C code, for my > usage, is already more than fast enough for my needs. Not for mine, sorry. > If it were > faster, I would still use make. If it ran at 1 MLOC per second, I'd > still use make, and I'd still structure my code the same way, and I'd > still run on Linux. If it ran 1Mlps, then half of make would be pointless. However, with C, it would run into other problems, like heavy include files, which would normally be repeatedly processed per-module. (This is something my language solves, but I also suggested, elsewhere in the thread, a way it could be mitigated in C.) >> But can you a see a fundamental problem that really ought to be fixed >> first? > > Sure - if that were realistic. But a more accurate model is that the > cars go at 30 mph No, I contend that big compilers do seem to go at 3mph, or worse. We can argue about how much extra work your compilers do than mine, so let's look at a slightly different tool: assemblers. Assembly is a straightforward task: there is no deep analysis, no optimisation, so it should be very quick, yes? Well have a look this survey I did from a couple of years ago: https://www.reddit.com/r/Compilers/comments/1c41y6d/assembler_survey/ There are quite a range of speeds! So what are those slow products up to that take so long? > People use make for many reasons - incremental building and dependency > management is just one (albeit important) aspect. You mentioned in > another post that "Python does not need make" - I have Python projects > that are organised by makefiles. Makefiles sound to me like your 'hammer' then. And honestly, if you had taken 1% of > the time and effort you have spend complaining in c.l.c. about "make" > and instead learned about it, you'd be writing makefiles in your sleep. > It really is not that hard, and you will never convince me you are not > smart enough to understand it quickly and easily. I simply don't like them; sorry. Everything they might do, is taken care of by language design, or by my compiler, or by scripting in a proper scripting language. And they are ugly. >> >> *It can allow programs to be run directly from source* This is >> something that is being explored via complex JIT approaches. But my >> AOT compiler is fast enough that that is not necessary > > I don't see what that is at all important for C programming. Why would > someone want to use C for scripting? If I had a C file "test.c" that > was short enough to be realistic for use as a script, and did not care > about optimisation or static checking, I could just type "make test > && ./test" to run it pretty much instantly. By 'scripting' people have certain expectations. Here is my example of C run like a script: c:\cx>cs sql SQLite version 3.25.3/MCC 2018-11-05 20:37:38 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> Here, there is 1/4 second delay as it compiles sql.c (some 250Kloc), so a bit heavy for scripting. But another option is: c:\cx>ci sql SQLite version 3.25.3/MCC 2018-11-05 20:37:38 ... 'ci' will interpret from source, and 'cs' will run from source as native code. (ci/cs are the same EXE with a different name. The compiler looks at the name to apply different default options, eg. -r -q for 'cs'.) So, there is little start-up delay; there is no discernible build-step; there is no unreasonable limit on size; there are no messy files left lying around; no files are written so could run on read-only media; for C, can run at native-code speeds if possible. Otherwise we would have had 'scripting' for C for ever, if you definition of it is simpler being able to invoke a program on the same line that you've just built it! But I accept that using a 'shebang' line, plus the use of tcc, will work in many cases. > Almost everyone who uses cdecl does that already. Enthusiasts living on > the cutting edge need to spend a couple of minutes downloading and > building the latest versions, but other people will use pre-built > binaries. And those people are already very familiar with the "./ > configure && make -j 8 && sudo make install" sequence. This is all Unix-Linux specific. There are other ways of building programs. I've used some of those over the course of some 49 years. >> Forget ./configure, forget make. Of course you can do the same thing, >> maybe there is 'make -run', the difference is that the above is instant. > > To be clear - I do think autotools is usually unnecessary, overly > complex, slow, and long outdated. What?! After being accused of baseless moaning, you know also agree that something might be pointlessly slow?! What about the argument that 'you only have to run it once'? > There were no details in that post - I suspect it was not /entirely/ > serious. He wouldn't have made up the figures, but someone said they may have been erroneous.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-30 18:59 +0000 |
| Message-ID | <20251030110447.954@kylheku.com> |
| In reply to | #394976 |
On 2025-10-30, bart <bc@freeuk.com> wrote: > On 30/10/2025 15:04, David Brown wrote: >> On 30/10/2025 13:07, bart wrote: > >> You moan that compiles are too slow. Yet doing them in parallel is a >> "workaround". Avoiding compiling unnecessarily is a "workaround". >> Caching compilation work is a "workaround". Using a computer from this >> century is a "workaround". Using a decent OS is a "workaround". Is / >> everything/ that would reduce your scope for complaining loudly to the >> wrong people a workaround? > > Yes, they are all workarounds to cope with unreasonably slow compilers. The idea of incremental rebuilding goes back to a time when compilers were fast, but machines were slow. If you had /those/ exact compilers today, and used them for even a pretty large project, you could likely do a full rebuild every time. But incremental building didn't go away because we already had it, and we took that into account when maintaining compilers. Basically, decades ago, we accepted the idea that it can take several seconds to compile the average file, and that we have incremental building to help with that. And so, unsurprisingly, as machines got several orders of magnitude faster, people we have made compilers do more and become more bloated, so that it can still take seconds to do one file, and you use make to avoid doing it. A lot of is it the optimization. Disable optimization and GCC is something like 15X faster. Optimization exhibits diminshing returns. It takes more and more work for less and less gain. It's really easy to make optimization take 10X longer for a fraction of a percent increase in speed. Yet, it tends to be done because of the reasoning that the program is compiled once, and then millions of instances of the program are run all over the world. One problem in optimization is that it is expensive to look for the conditions that enable a certain optimization. It is more expensive than doing the optimization, because the optimization is often a conceptually simple code transformation that can be done quickly, when the conditions are identified. But compiler has to look for those conditions everywhere, in every segment of code, every basic block. But it may turn out that there is a "hit" for those conditions in something like one file out of every hundred, or even more rarely. When there is no "hit" for the optimization's conditions, then it doesn't take place, and all that time spent looking for it is just making the compiler slower. The problem is that to get the best possible optimization, you have to look for numerous such rare conditions. When one of them doesn't "hit", one of the others might. The costs of these add up. Over time, compiler developers tend to add optimizatons much more than remove them. > They in fact all come across as excuses for your favorite compiler being > slow. Well, yes. Since we've had incremental rebuilding since the time VLSI machines were measured in single digit Mhz, we've taken it for granted that it will be used and so, to reiterate, that excuses the idea of a compiler taking several seconds to do one file. > Which one of these methods would you use to advertise the LPS throughput > of a compiler that you develop? It would be a lie to measure lines per second on anything but a single-core, complete rebuild of the benchmark program. High LPS compilers are somehow not winning in the programming marketplace, or at least some segments. That field is open! Once upon a time it seemed that GCC would remain unchallenged. Then Clang came along: but it too got huge, fat and slow within a bunch of years. This is mainly due to trying to have good optimizations. You will never get a C compiler that has very high LSP throughput, but doesn't optimize as well as the "leading brand", to make inroads into the ecosystem dominated by the "leading brand". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 23:23 +0000 |
| Message-ID | <10e0s13$30mn$1@dont-email.me> |
| In reply to | #394979 |
On 30/10/2025 18:59, Kaz Kylheku wrote: > On 2025-10-30, bart <bc@freeuk.com> wrote: >> On 30/10/2025 15:04, David Brown wrote: >>> On 30/10/2025 13:07, bart wrote: >> >>> You moan that compiles are too slow. Yet doing them in parallel is a >>> "workaround". Avoiding compiling unnecessarily is a "workaround". >>> Caching compilation work is a "workaround". Using a computer from this >>> century is a "workaround". Using a decent OS is a "workaround". Is / >>> everything/ that would reduce your scope for complaining loudly to the >>> wrong people a workaround? >> >> Yes, they are all workarounds to cope with unreasonably slow compilers. > > The idea of incremental rebuilding goes back to a time when compilers > were fast, but machines were slow. What do you mean by incremental rebuilding? I usually talk about /independent/ compilation. Then incremental builds might be about deciding which modules to recompile, except that that is so obvious, you didn't give it a name. Compile the one file you've just edited. If it might impact on any others (you work on a project for months, you will know it intimately), then you just compile the lot. > > If you had /those/ exact compilers today, and used them for even a pretty > large project, you could likely do a full rebuild every time. > > But incremental building didn't go away because we already had it, > and we took that into account when maintaining compilers. > > Basically, decades ago, we accepted the idea that it can take several > seconds to compile the average file, and that we have incremental > building to help with that. > > And so, unsurprisingly, as machines got several orders of magnitude > faster, people we have made compilers do more and become more bloated, > so that it can still take seconds to do one file, and you use make to > avoid doing it. > > A lot of is it the optimization. Disable optimization and GCC is > something like 15X faster. I don't think so. Not for C anyway, or that level of language. It's usually about 3-5 times between -O0 and -O3, and even less between -O0 and -O2. (The difference tends to greater for compiling bigger modules, but you also get more global optimisations.) > Optimization exhibits diminshing returns. It takes more and more > work for less and less gain. It's really easy to make optimization > take 10X longer for a fraction of a percent increase in speed. > > Yet, it tends to be done because of the reasoning that the program is > compiled once, and then millions of instances of the program are run > all over the world. > > One problem in optimization is that it is expensive to look for the > conditions that enable a certain optimization. It is more expensive > than doing the optimization, because the optimization is often > a conceptually simple code transformation that can be done quickly, > when the conditions are identified. But compiler has to look for those > conditions everywhere, in every segment of code, every basic block. > But it may turn out that there is a "hit" for those conditions in > something like one file out of every hundred, or even more rarely. > > When there is no "hit" for the optimization's conditions, then it > doesn't take place, and all that time spent looking for it is just > making the compiler slower. > > The problem is that to get the best possible optimization, you have to > look for numerous such rare conditions. When one of them doesn't "hit", > one of the others might. The costs of these add up. Over time, > compiler developers tend to add optimizatons much more than remove them. > >> They in fact all come across as excuses for your favorite compiler being >> slow. The problem is that there is no fast path for -O0: c:\cx>tim gcc -O2 -s sql.c Time: 39.685 c:\cx>tim gcc -O0 -s sql.c Time: 7.819 ** That 8s vs 40s is welcome, but it can be also be: c:\cx>tim bcc sql Compiling sql.c to sql.exe Time: 0.245 (** Note that this test uses windows.h, and gcc's version is much bigger than mine, and accounts for 1.3s of that timing.) So -O0 is still 25 slower than my product. (Tcc would be even faster, but it's not working for this app ATM. I'm sometimes considered whether gcc should just secretly bundle tcc.exe, and run it for O-1.) > Well, yes. Since we've had incremental rebuilding since the time VLSI > machines were measured in single digit Mhz, we've taken it for granted > that it will be used and so, to reiterate, that excuses the idea of > a compiler taking several seconds to do one file. > >> Which one of these methods would you use to advertise the LPS throughput >> of a compiler that you develop? > > It would be a lie to measure lines per second on anything but > a single-core, complete rebuild of the benchmark program. Exactly. But also, you really need to do comparisons with other products on the same hardware, as LPS will be tied to the machine. (My friend's ordinary laptop, used for ordinary consumer stuff, is 70% faster than my PC. But I'm happy to give benchmark results on the PC.) > High LPS compilers are somehow not winning in the programming > marketplace, or at least some segments. > > That field is open! > > Once upon a time it seemed that GCC would remain unchallenged. Then > Clang came along: but it too got huge, fat and slow within a bunch of > years. This is mainly due to trying to have good optimizations. It had to keep up with gcc. But it is not helped by being based around LLVM which has grown into a monstrosity. > You will never get a C compiler that has very high LSP throughput, but > doesn't optimize as well as the "leading brand", to make inroads into > the ecosystem dominated by the "leading brand". People into compilers are obsessed with optimisation. It can be a necessity for languages that generate lots of redundant code that needs to be cleaned up, but not so much for C. Typical differences of between -O0 and -O2 compiled code can be 2:1. However even the most terrible native code will be a magnitude faster than interpreted code.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web