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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-30 16:44 -0700 |
| Message-ID | <87ms585509.fsf@example.invalid> |
| In reply to | #394985 |
bart <bc@freeuk.com> writes:
> 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.
I'll assume that was a serious question. Even if you don't care,
others might.
Let's say I'm working on a project that has a bunch of *.c and
*.h files.
If I modify just foo.c, then type "make", it will (if everything
is set up correctly) recompile "foo.c" generating "foo.o", and
then run a link step to recreate any executable that depends on
"foo.o". It knows it doesn't have to recompile "bar.c" because
"bar.o" sill exists and is newer than "bar.c".
Perhaps the project provides several executable programs, and
only two of them rely on foo.o. Then it can relink just those
two executables.
This is likely to give you working executables substantially
faster than if you did a full rebuild. It's more useful while
you're developing and updating a project than when you download
the source and build it once.
(I often tend to do full rebuilds anyway, for vague reasons I won't
get into.)
This depends on all relevant dependencies being reflected in the
Makefile, and on file timestamps being updated correctly when files
are edited. (In the distant past, I've run into problems with the
latter when the files are on an NFS server and the server and client
have their clocks set differently.)
(I'll just go ahead and acknowledge, so you don't have to, that
this might not be necessary if the build tools are infinitely fast.)
If I've done a "make clean" or "git clean", or started from scratch
by cloning a git repo or unpacking a .tar.gz file, then any generated
files will not be present, and typing "make" will have to rebuild
everything.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 00:15 +0000 |
| Message-ID | <10e0v3g$38ns$2@dont-email.me> |
| In reply to | #394986 |
On 30/10/2025 23:44, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> 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.
>
> I'll assume that was a serious question. Even if you don't care,
> others might.
>
> Let's say I'm working on a project that has a bunch of *.c and
> *.h files.
>
> If I modify just foo.c, then type "make", it will (if everything
> is set up correctly) recompile "foo.c" generating "foo.o", and
> then run a link step to recreate any executable that depends on
> "foo.o". It knows it doesn't have to recompile "bar.c" because
> "bar.o" sill exists and is newer than "bar.c".
>
> Perhaps the project provides several executable programs, and
> only two of them rely on foo.o. Then it can relink just those
> two executables.
>
> This is likely to give you working executables substantially
> faster than if you did a full rebuild. It's more useful while
> you're developing and updating a project than when you download
> the source and build it once.
I never came across any version of 'make' in the DEC OSes I used in the
1970s, in the 1980s did see it either.
In any case it wouldn't have worked with my compiler, as it was not a
discrete program: it was memory-resident together with an editor, as
part of my IDE.
This helped to get fast turnarounds even on floppy-based 8-bit systems.
Plus, I wouldn't have felt the issue was of any great importance:
When you're working intensely on a project for weeks or months, you will
be dealing with a thousand functions, variables and constants that you
have to keep organised in your mind.
Keeping track of which modules needed recompiling was child's play (and
I don't mean that literally!).
Anyway, with the language I was using at that time, modules had a
particular organisation:
* Most were modules containing code
* Some were classed as headers (only vaguely related to C headers),
which contained shared, project-wide declarations
* All modules shared the same set of headers (on compilation, all the
headers were treated as one, via an IDE-synthesised header that
included the rest)
Edits to code modules only needed that module recompiled. A change to
any header could require all to be recompiled, but that was at your
discretion.
> (I often tend to do full rebuilds anyway, for vague reasons I won't
> get into.)
>
> This depends on all relevant dependencies being reflected in the
> Makefile, and on file timestamps being updated correctly when files
> are edited. (In the distant past, I've run into problems with the
> latter when the files are on an NFS server and the server and client
> have their clocks set differently.)
>
> (I'll just go ahead and acknowledge, so you don't have to, that
> this might not be necessary if the build tools are infinitely fast.)
>
> If I've done a "make clean" or "git clean", or started from scratch
> by cloning a git repo or unpacking a .tar.gz file, then any generated
> files will not be present, and typing "make" will have to rebuild
> everything.
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-30 18:16 -0700 |
| Message-ID | <87ikfv6fb8.fsf@example.invalid> |
| In reply to | #394988 |
bart <bc@freeuk.com> writes:
> On 30/10/2025 23:44, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
[...]
>>> 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.
>> I'll assume that was a serious question. Even if you don't care,
>> others might.
[...]
>
> I never came across any version of 'make' in the DEC OSes I used in
> the 1970s, in the 1980s did see it either.
>
> In any case it wouldn't have worked with my compiler, as it was not a
> discrete program: it was memory-resident together with an editor, as
> part of my IDE.
>
> This helped to get fast turnarounds even on floppy-based 8-bit systems.
>
> Plus, I wouldn't have felt the issue was of any great importance:
[...]
You asked what incremental building means. I told you. Your only
response is to let us all know that you don't find it useful.
I think we all already knew that.
I assumed (a) that you didn't already know what incremental building
means and (b) that you wanted to know. That's why I posted my answer to
your question.
I don't recall ever seeing you react positively to someone giving you
information that you've asked for. Instead, you tend to use the answer
as an opportunity to tell us all that whatever concept you were asking
about is not useful to you.
Did you ask what incremental building means because you wanted to know?
Should I assume that every question you ask is rhetorical?
And a minor point: In the quoted text in your followup, the blank lines
between paragraphs in what I wrote were deleted. Please don't do that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 01:36 +0000 |
| Message-ID | <10e13r4$4j89$2@dont-email.me> |
| In reply to | #394992 |
On 31/10/2025 01:16, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 30/10/2025 23:44, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: > [...] >>>> 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. >>> I'll assume that was a serious question. Even if you don't care, >>> others might. > [...] >> >> I never came across any version of 'make' in the DEC OSes I used in >> the 1970s, in the 1980s did see it either. >> >> In any case it wouldn't have worked with my compiler, as it was not a >> discrete program: it was memory-resident together with an editor, as >> part of my IDE. >> >> This helped to get fast turnarounds even on floppy-based 8-bit systems. >> >> Plus, I wouldn't have felt the issue was of any great importance: > [...] > > You asked what incremental building means. I told you. Your only > response is to let us all know that you don't find it useful. Actually I didn't mention 'make'. I said what I thought it meant, and I expanded on that in my reply to you. You mentioned 'make', and I also explained why it wouldn't have been any good to me. In any case, you still have to give that dependency information to 'make', and maintain it, as well as all info about the constituent files of the project. Since I used project files from a very early stage, much of that information is already present (and is used to browse the source files and to do full compiles and linking). If I wanted automatic dependency handling, then it would have made sense to add that to the project file, than use an external tool with arcane syntax. The project file also had the task of doing test runs of the application, applying suitable inputs, and at one point, also dealing with overlays. Sometimes, the generated program was downloaded to a separate microprocessor to in other to test on bare hardware. The picture I'm giving is that there was lots going on, centrally controlled, compared with the minor aspects that a makefile could help with, but which would have needed a duplicate lot of information.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-30 19:13 -0700 |
| Message-ID | <87bjln6coy.fsf@example.invalid> |
| In reply to | #394994 |
bart <bc@freeuk.com> writes:
> On 31/10/2025 01:16, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 30/10/2025 23:44, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>> [...]
>>>>> 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.
>>>> I'll assume that was a serious question. Even if you don't care,
>>>> others might.
>> [...]
>>>
>>> I never came across any version of 'make' in the DEC OSes I used in
>>> the 1970s, in the 1980s did see it either.
>>>
>>> In any case it wouldn't have worked with my compiler, as it was not a
>>> discrete program: it was memory-resident together with an editor, as
>>> part of my IDE.
>>>
>>> This helped to get fast turnarounds even on floppy-based 8-bit systems.
>>>
>>> Plus, I wouldn't have felt the issue was of any great importance:
>> [...]
>> You asked what incremental building means. I told you. Your only
>> response is to let us all know that you don't find it useful.
>
> Actually I didn't mention 'make'. I said what I thought it meant, and
> I expanded on that in my reply to you.
>
> You mentioned 'make', and I also explained why it wouldn't have been
> any good to me.
"make" is probably the most common tool that supports incremental
building, and certainly the one I'm most familiar with. There
are other tools that have similar support (many of them are built on top
of "make"). The idea of incremental building isn't as tightly tied to
"make" as I might have suggested.
> In any case, you still have to give that dependency information to
> 'make', and maintain it, as well as all info about the constituent
> files of the project.
Makefiles are commonly generated automatically.
I asked you several questions, that you quietly snipped. I'll assume
you refuse to answer them.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-31 13:43 +0000 |
| Message-ID | <Y13NQ.229704$RB68.196263@fx39.iad> |
| In reply to | #394988 |
bart <bc@freeuk.com> writes: >On 30/10/2025 23:44, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: <snip accurate description of make(1) semantics> >> This is likely to give you working executables substantially >> faster than if you did a full rebuild. It's more useful while >> you're developing and updating a project than when you download >> the source and build it once. > >I never came across any version of 'make' in the DEC OSes I used in the >1970s, in the 1980s did see it either. Unix provided make in the 1970s, on DEC hardware. > >In any case it wouldn't have worked with my compiler, as it was not a >discrete program: it was memory-resident together with an editor, as >part of my IDE. > >This helped to get fast turnarounds even on floppy-based 8-bit systems. The programs[*] I worked on in the 70 and 80's couldn't have been compiled on floppy-based 8-bit systems. [*] Master Control Program (MCP), for example. We had a program called WFL (Work Flow Language) which could be used to automate MCP builds, which would rebuild only the modules that changed then run the binder (linker) to create the MCP binary.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-31 13:10 +0100 |
| Message-ID | <10e28vv$f6ll$1@dont-email.me> |
| In reply to | #394985 |
On 31/10/2025 00:23, bart wrote: > 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. > You live in a world of x86 (with brief visits to 64-bit ARM). You used to work with smaller processors and lower level code, but seem to have forgotten that long ago. A prime characteristic of modern x86 processors is that they are extremely good at running extremely bad code. They are targeted at systems where being able to run old binaries is essential. A great deal of the hardware in an x86 cpu core is there to handle poorly optimised code - lots of jumps and function calls get predicted and speculated, data that is pushed onto and pulled off the stack gets all kinds of fast paths and short-circuits, and so on. And then there is the memory - if code has to wait for data from ram, the cpu can happily execute hundreds of cycles of unnecessary unoptimised code without making any difference to the final speed. Big ARM processors - such as on Pi's - have the same effects, though to a somewhat lesser extent. A prime characteristic of user programs on PC's and other "big" systems is that a lot of the time is spent doing things other than running the user code - file I/O, screen display, OS calls, or code in static libraries, DLLs (or SOs), etc. That stuff is completely unaffected by the efficiency of the user code - that's why interpreted or VM code is fast enough for a very wide range of use-cases. And if you are working with Windows systems with an MS DLL for the C runtime library (as used by some C toolchains on Windows, but not all), then you can get more distortions. If you have a call to memcpy that uses an external DLL, that is going to take perhaps 500 clock cycles even for a small fixed size of memcpy (assuming all code and data is in cache). The user code for the call might be 10 cycles or 20 cycles depending on the optimisation - compiler optimisation makes no measurable difference here. But if the toolchain uses a static library for memcpy and can optimise locally to replace the call, the static call to general memcpy code might take 200 cycles while the local code takes 10 cycles. Suddenly the difference between optimising and non-optimising is huge. Then there is the type of code you are dealing with. Some code is very cpu intensive and can benefit from optimisations, other code is not. And optimisation is not just a matter of choosing -O0 or -O2 flags. It can mean thought and changes in the source code (some standard C changes, like use of "restrict" parameters, some compiler-specific changes like gcc attributes or builtins, and some target specific like organising data to fit cache usage). And it can mean careful flag choices - different specific optimisations suitable for the code at hand, and target related flags for enabling more target features. I am entirely confident that you have done nothing of these things when testing. That's not necessarily a bad thing in itself, when looking at widely portable source compiled to generic binaries, but it gives a very unrealistic picture of compiler optimisations and what can be achieved by someone who knows how to work with their compiler. All this conspires to give you this 2:1 ratio that you regularly state for the difference between optimised code and unoptimised code - gcc -O2 and gcc -O0. In reality, people can often achieve far greater ratios for the type of code where performance matters and where it is is achievable. Someone working on game engines on an x86 would probably expect at least 10 times difference between the flags they use, and no optimisation flags. For the targets I use, which are (generally) not super-scaler, out-of-order, etc., five to ten times difference is not uncommon. And when you throw C++ or other modern languages into the mix (remember, gcc and clang/llvm are not simple C compilers), the benefits of inlining and other inter-procedural optimisations can easily be an order of magnitude. (This is one reason why gcc and clang enable a number of optimisations, including at least inlining of functions marked appropriately, even with no optimisation flags specified.) You can continue to believe that high-end toolchains are no more than twice as good as your own compiler or tcc, if you like. (And they give you all the performance and features that you need, fine.) Those of us who want more from our tools, and know how to get it, know better.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 16:34 +0000 |
| Message-ID | <10e2oef$ks1i$1@dont-email.me> |
| In reply to | #395005 |
On 31/10/2025 12:10, David Brown wrote:
> On 31/10/2025 00:23, bart wrote:
>
>> 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.
>>
>
> You live in a world of x86 (with brief visits to 64-bit ARM). You used
> to work with smaller processors and lower level code, but seem to have
> forgotten that long ago.
>
> A prime characteristic of modern x86 processors is that they are
> extremely good at running extremely bad code.
Yes. And? That means compilers don't need to be so clever!
> They are targeted at
> systems where being able to run old binaries is essential. A great deal
> of the hardware in an x86 cpu core is there to handle poorly optimised
> code - lots of jumps and function calls get predicted and speculated,
> data that is pushed onto and pulled off the stack gets all kinds of fast
> paths and short-circuits, and so on. And then there is the memory - if
> code has to wait for data from ram, the cpu can happily execute hundreds
> of cycles of unnecessary unoptimised code without making any difference
> to the final speed.
>
> Big ARM processors - such as on Pi's - have the same effects, though to
> a somewhat lesser extent.
>
> A prime characteristic of user programs on PC's and other "big" systems
> is that a lot of the time is spent doing things other than running the
> user code - file I/O, screen display, OS calls, or code in static
> libraries, DLLs (or SOs), etc. That stuff is completely unaffected by
> the efficiency of the user code - that's why interpreted or VM code is
> fast enough for a very wide range of use-cases.
Yes. That's why interpreted/dynamic languages (those usually go
together) are viable.
When I first introduced interpreted scripting to my apps (35 years ago),
I had a rough guideline in that an interpreted version of a task should
ideally be no worse than half the speed of 100% native code.
My everyday text-editor is interpreted, and I routinely edit 1-million
line files without noticing any lag.
> And if you are working with Windows systems with an MS DLL for the C
> runtime library (as used by some C toolchains on Windows, but not all),
> then you can get more distortions. If you have a call to memcpy that
> uses an external DLL, that is going to take perhaps 500 clock cycles
> even for a small fixed size of memcpy (assuming all code and data is in
> cache). The user code for the call might be 10 cycles or 20 cycles
> depending on the optimisation - compiler optimisation makes no
> measurable difference here. But if the toolchain uses a static library
> for memcpy and can optimise locally to replace the call, the static call
> to general memcpy code might take 200 cycles while the local code takes
> 10 cycles. Suddenly the difference between optimising and non-
> optimising is huge.
(My language has a 'clear' operator. Then inline code is generated for
fixed-size objects.)
>
> Then there is the type of code you are dealing with. Some code is very
> cpu intensive and can benefit from optimisations, other code is not.
>
> And optimisation is not just a matter of choosing -O0 or -O2 flags.
To me, 'compiler'-optimisation means getting my program faster /without
changing the source/. All I want to do is either enable or disable the
option.
A lot of my optimisations are to do with design choices in my language,
special features it might provide, and design choices in the application.
Anything that can be done in the compiler is a bonus, but I don't rely
on it (other than the special case of generated C, see below).
> It
> can mean thought and changes in the source code (some standard C
> changes, like use of "restrict" parameters, some compiler-specific
> changes like gcc attributes or builtins, and some target specific like
> organising data to fit cache usage).
> And it can mean careful flag
> choices - different specific optimisations suitable for the code at
> hand, and target related flags for enabling more target features.
It sounds a lot of work. I used to just use inline assembly and be done
with it!
> I am
> entirely confident that you have done nothing of these things when
> testing. That's not necessarily a bad thing in itself, when looking at
> widely portable source compiled to generic binaries, but it gives a very
> unrealistic picture of compiler optimisations and what can be achieved
> by someone who knows how to work with their compiler.
>
>
> All this conspires to give you this 2:1 ratio that you regularly state
> for the difference between optimised code and unoptimised code - gcc -O2
> and gcc -O0.
If I'm giving figures that compare gcc-O0 to gcc-O2, then clearly,
everything else must remain the same. Otherwise why not compare two
entirely different algorithms while we're about it.
Anyway, I assume all that stuff you've mentioned has been incorporated
into the A68G makefiles, and it's still a pretty slow interpreter!
(Although probably the advanced features of the language don't help.)
However, one thing I did try the other day was to take the generated
makefile, and change the -O2 flag to -O0. Building it was a little
faster (60s instead of 90s), but my benchmark ran in 13s instead of 5s,
so 2.6:1.
You seem to be suggesting the difference should be greater, but this is
someone else's codebase, and someone else's set of compiler flags, other
than the choice of -O0/-O2.
So, while I understand what you're saying, that doesn't apply if you are
building, running and measuring an existing codebase created by someone
else.
I *am* seeing figures of 2:1, or sometimes 3:1 or 4:1; the latter
usually when someone is trying to be too clever with intensive use of
macros that may hide too many nested function, so that it needs inlining
to get a respectable speed.
>
> In reality, people can often achieve far greater ratios for the type of
> code where performance matters and where it is is achievable. Someone
> working on game engines on an x86 would probably expect at least 10
> times difference between the flags they use, and no optimisation flags.
> For the targets I use, which are (generally) not super-scaler, out-of-
> order, etc., five to ten times difference is not uncommon.
For the /applications/ I write (not silly benchmarks), and for x64, 2:1
is typical, but this is comparing my compilers (a little better than
gcc-O0), with gcc-O2.
These are apps like compilers, assemblers and interpreters, which are
computationally intensive (most code executed is within the program I've
generated). On those, I usually get better than 2:1 for /programs I've
written/, such as 1.5:1.
It can be worse than 2:1 for C programs, especially other people's.
But I have also seen up to 10:1 for my generated C code (18:1 below),
which currently is very poor, where I /require/ optimisation to clean up
redundancies.
> And when you
> throw C++ or other modern languages into the mix (remember, gcc and
> clang/llvm are not simple C compilers), the benefits of inlining and
> other inter-procedural optimisations can easily be an order of
> magnitude. (This is one reason why gcc and clang enable a number of
> optimisations, including at least inlining of functions marked
> appropriately, even with no optimisation flags specified.)
> You can continue to believe that high-end toolchains are no more than
> twice as good as your own compiler or tcc, if you like.
Here are examples of two C libraries:
Jpeg decoder on 94MB image:
Ratio
gcc -O2 4.4 seconds
bcc 6.4 seconds 1.45 : 1
tcc 10.6 seconds 2.41 : 1
(The input file has been cached. Stopping after loading via fread takes
0.08 seconds.)
Calculate N digits of pi via my bignum library:
gcc -O2 0.7 seconds
bcc 1.6 seconds 2.3 : 1 (C version ported from M)
mm 1.2 seconds 1.7 : 1 (using version in my language)
tcc 1.9 seconds 2.7 : 1
And here is the Lua interpreter running Fibonacci:
gcc -O2 3.2 seconds
gcc -O0 11.4 seconds 3.6 : 1
bcc 7.3 seconds 2.3 : 1
tcc 10.2 seconds 3.2 : 1
This one is my interpreter also running the same Fibonacci test:
gcc -O2 1.2 seconds (from low-level transpiled C)
gcc -O0 22.3 seconds 18.6 : 1
mm 1.3 seconds 1.1 : 1
Here, gcc's optimiser is earning its keep.
The ratios involving my own products are 1.45, 2.3, 1.7, 2.3, 1.1. The
average is 1.77:1 slowdown compared to gcc-O2.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 23:01 +0100 |
| Message-ID | <10e0n7t$1d1v$1@dont-email.me> |
| In reply to | #394976 |
On 30/10/2025 18:49, bart 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. > 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? > If I were developing a compiler, I would not advertise any kind of lines-per-second value. It is a totally useless metric - as useless as measuring developer performance on the lines of code he/she writes per day. >> >> 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. OK. I realise that's how you feel. > >> 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. If gcc ran at 1 Mlps, the developers would be doing something wrong - there are optimisations already understood that could give significant benefits to generated code but are impractical to implement or use because they scale badly and become too slow in practice. It would be better to prioritise these than meaningless speeds. > > 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.) > No method of avoiding headers has been found to be worth the effort in C. In C++, it's a different matter, and one of the key motivators for the development of C++ modules is build times. >>> 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. It's a Swiss army knife, not a hammer. > > 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. > You haven't a clue about make and makefiles, but you insist on judging them - and on judging people who use the tool. It's okay for you not to use make, but it is not okay to be self-righteous about it as though your prejudice from ignorance is a good thing.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-31 00:28 +0000 |
| Message-ID | <20251030172415.416@kylheku.com> |
| In reply to | #394982 |
On 2025-10-30, David Brown <david.brown@hesbynett.no> wrote: > If I were developing a compiler, I would not advertise any kind of > lines-per-second value. It is a totally useless metric - as useless as > measuring developer performance on the lines of code he/she writes per day. If that were your only advantage, you'd have to flout it. "[[ Our compiler emits lousy code, emits only half the required ISO diagnostics (and those are all there are), and is compatible with only 75% of your system's header files, and 80% of the ABI, but ...]] have you seen the raw speed in lines per second?" -- 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-31 01:22 +0000 |
| Message-ID | <10e130m$4j89$1@dont-email.me> |
| In reply to | #394990 |
On 31/10/2025 00:28, Kaz Kylheku wrote: > On 2025-10-30, David Brown <david.brown@hesbynett.no> wrote: >> If I were developing a compiler, I would not advertise any kind of >> lines-per-second value. It is a totally useless metric - as useless as >> measuring developer performance on the lines of code he/she writes per day. > > If that were your only advantage, you'd have to flout it. > > "[[ Our compiler emits lousy code, emits only half the required ISO > diagnostics (and those are all there are), and is compatible with only > 75% of your system's header files, and 80% of the ABI, but ...]] have you > seen the raw speed in lines per second?" > How would Turbo C compare then? Anyway, C is often used as a target for compilers of other languages. There, it should be validated code, and so needs little error checking. It might not even use any headers (my generated C doesn't). The main requirement is that after the front-end compiler has generated the C, taking some fraction of a second, it doesn't immediately hit a brick wall if it tried to use a substantial product like gcc for the next stage. Here, optimisation is less important (unless the generated is hopelessy poor). But it's quite possible to choose between a fast backend compiler for routine builds, and a slower optimising one for production. In fact, you can use this approach anyway even if directly coding in C: use a fast compiler most of the time, and a slower one for a periodic check or when you need the better code.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2025-10-31 10:29 +0100 |
| Message-ID | <10e1vh8$10tg$1@news.gegeweb.eu> |
| In reply to | #394993 |
On 10/31/25 02:22, bart wrote:
>
> Anyway, C is often used as a target for compilers of other languages.
>
> There, it should be validated code, and so needs little error checking.
> It might not even use any headers (my generated C doesn't).
s/should/MUST/
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-31 13:15 +0200 |
| Message-ID | <20251031131505.00006dd1@yahoo.com> |
| In reply to | #394993 |
On Fri, 31 Oct 2025 01:22:30 +0000 bart <bc@freeuk.com> wrote: > On 31/10/2025 00:28, Kaz Kylheku wrote: > > On 2025-10-30, David Brown <david.brown@hesbynett.no> wrote: > >> If I were developing a compiler, I would not advertise any kind of > >> lines-per-second value. It is a totally useless metric - as > >> useless as measuring developer performance on the lines of code > >> he/she writes per day. > > > > If that were your only advantage, you'd have to flout it. > > > > "[[ Our compiler emits lousy code, emits only half the required ISO > > diagnostics (and those are all there are), and is compatible with > > only 75% of your system's header files, and 80% of the ABI, but > > ...]] have you seen the raw speed in lines per second?" > > > > How would Turbo C compare then? > Turbo C implented majority of C89/C90 years (like 3-5 years in some cases) ahead of many of so-called "serious" C compilers.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-31 21:39 +0000 |
| Message-ID | <10e3aap$bm9d$1@paganini.bofh.team> |
| In reply to | #394993 |
bart <bc@freeuk.com> wrote:
> On 31/10/2025 00:28, Kaz Kylheku wrote:
>> On 2025-10-30, David Brown <david.brown@hesbynett.no> wrote:
>>> If I were developing a compiler, I would not advertise any kind of
>>> lines-per-second value. It is a totally useless metric - as useless as
>>> measuring developer performance on the lines of code he/she writes per day.
>>
>> If that were your only advantage, you'd have to flout it.
>>
>> "[[ Our compiler emits lousy code, emits only half the required ISO
>> diagnostics (and those are all there are), and is compatible with only
>> 75% of your system's header files, and 80% of the ABI, but ...]] have you
>> seen the raw speed in lines per second?"
>>
>
> How would Turbo C compare then?
I probably used Turbo C once (to compile a C program fetched from
the net). But I used Turbo Pascal and later Borland C (which was
supposed to be an optimizing compiler). AFAICS main attraction
of Turbo family in general was fast compilation. But generated
code was poor, much bigger and slower than code from optimizing
compilers. I used Borland C to deliver a few programs for
Windows (I developed them using gcc on Linux, Borland C was
just for final tests and delivery). But later I have set up
Mingw cross compiler and testing showed that gcc compiled code
was significantly faster than output from Borland C.
It seems that "professionals" preferred other compilers, like
Microsoft one or Watcom (or possibly others, there were quite
a lot of different compilers in this period).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2025-10-31 11:43 +0000 |
| Message-ID | <10e27di$bb7$1@artemis.inf.ed.ac.uk> |
| In reply to | #394990 |
In article <20251030172415.416@kylheku.com>, Kaz Kylheku <643-408-1753@kylheku.com> wrote: >If that were your only advantage, you'd have to flout it. Flaunt. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-31 22:47 +0000 |
| Message-ID | <20251031154648.883@kylheku.com> |
| In reply to | #395004 |
On 2025-10-31, Richard Tobin <richard@cogsci.ed.ac.uk> wrote: > In article <20251030172415.416@kylheku.com>, > Kaz Kylheku <643-408-1753@kylheku.com> wrote: > >>If that were your only advantage, you'd have to flout it. > > Flaunt. *rubeyes* I can't believe I wrote that! -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-31 13:16 +0100 |
| Message-ID | <10e29bc$f6o8$1@dont-email.me> |
| In reply to | #394990 |
On 31/10/2025 01:28, Kaz Kylheku wrote: > On 2025-10-30, David Brown <david.brown@hesbynett.no> wrote: >> If I were developing a compiler, I would not advertise any kind of >> lines-per-second value. It is a totally useless metric - as useless as >> measuring developer performance on the lines of code he/she writes per day. > > If that were your only advantage, you'd have to flout it. > > "[[ Our compiler emits lousy code, emits only half the required ISO > diagnostics (and those are all there are), and is compatible with only > 75% of your system's header files, and 80% of the ABI, but ...]] have you > seen the raw speed in lines per second?" > I have seen, and even used, compilers that would fit that description quite well :-( Usually, however, the flouted advantage is not the raw speed, but support for a microcontroller target that no one else supports. Oh, and generally they could add "costs a ridiculous price" to the list.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 23:40 +0000 |
| Message-ID | <10e3hcj$rndf$2@dont-email.me> |
| In reply to | #394990 |
On 31/10/2025 00:28, Kaz Kylheku wrote: > On 2025-10-30, David Brown <david.brown@hesbynett.no> wrote: >> If I were developing a compiler, I would not advertise any kind of >> lines-per-second value. It is a totally useless metric - as useless as >> measuring developer performance on the lines of code he/she writes per day. > > If that were your only advantage, you'd have to flout it. > > "[[ Our compiler emits lousy code, emits only half the required ISO > diagnostics (and those are all there are), and is compatible with only > 75% of your system's header files, and 80% of the ABI, but ...]] Those incompatibilities anyway, even on big compilers, and people are tolerant of them. How many headers have you seen which multiple conditional blocks which pander to different compilers, for example (from SDL2): # if defined(HAVE_ALLOCA_H) # include <alloca.h> # elif defined(__GNUC__) # define alloca __builtin_alloca # elif defined(_MSC_VER) # include <malloc.h> # define alloca _alloca # elif defined(__WATCOMC__) # include <malloc.h> # elif defined(__BORLANDC__) # include <malloc.h> # elif defined(__DMC__) # include <stdlib.h> # elif defined(__AIX__) #pragma alloca # elif defined(__MRC__) void *alloca(unsigned); # else char *alloca(); # endif #endif (If you are writing your own compiler, where is it going to fit in?) In fact, half of configure scripts seem to be about testing the capabilities of the C compiler, so it is apparently expected that any of those features can be missing. And as for diagnostics, it seems that you have actively know about them and explicitly enable checking for them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-31 17:14 -0700 |
| Message-ID | <877bwa6231.fsf@example.invalid> |
| In reply to | #395020 |
bart <bc@freeuk.com> writes:
[...]
> And as for diagnostics, it seems that you have actively know about
> them and explicitly enable checking for them.
It "seems"?
Yes. Most C compilers, and gcc in particular, are not fully
conforming by default, and do not produce all the diagnostics
required by the ISO C standard. Most C compilers have options
that tell them to attempt to do so. For gcc or clang, you can use
"-std=c17 -pedantic". Replace "c17" by whatever edition of the
standard hou prefer to use. Replace "-pedantic" by "-pedantic-errors"
if you want fatal diagnostics. Replace "-pedantic" by "-Wpedantic"
if you're fond of the letter 'W'.
I've been telling you this for well over a decade, and it still only
"seems" to be the case? How does that work?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-31 09:31 +0100 |
| Message-ID | <10e1s53$bacd$1@dont-email.me> |
| In reply to | #394982 |
On 30.10.2025 23:01, David Brown wrote: > On 30/10/2025 18:49, bart wrote: >> [...] > > If I were developing a compiler, I would not advertise any kind of > lines-per-second value. It is a totally useless metric - It's good enough for marketing. > as useless as measuring developer performance on the lines of code > he/she writes per day. Which sadly had been done (maybe still?) by the less enlightened instances of management. Janis
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web