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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-30 23:11 +0000 |
| Message-ID | <10e0rbd$2e05$1@paganini.bofh.team> |
| In reply to | #394970 |
David Brown <david.brown@hesbynett.no> wrote:
> On 30/10/2025 13:07, bart wrote:
>>
>> 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.
My laptop which is 6 years old now has two rather slow cores. I
bought it because I use it when I am "on move", that is I carry
it to places where I use it. I wanted laptop with light, hence
small battery. And compute power needs appropriate electric
power, faster/more cores would drain batteries faster.
I have rather new (I bought it year ago) mini-PC. It has two cores,
significantly faster than my laptop but only two. Again, its adantage
is low power use, I did not do exact measurements but its power use
should be comparable with newest Raspberry Pi. It is fine as a low
end personal machine.
More generally, my impression is that 15 years ago there was limited
choice on x86 cores. Now there are chips optimized for low power
and speed of CPU can vary quite a lot. In desktop I have 12
fast cores (24 logical cores with hyperthreading). Some people
here mentioned machines with mixture of fast and slow cores.
There are machines having a lot of slower cores. And low end
machines like my laptor or mini-PC. I did not met any new 1 core
x86 CPU in last several years, but 2 core ones are reasonably
popular.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 23:49 +0000 |
| Message-ID | <10e0tj0$38ns$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: > 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. The machine is from 2021. It has an SSD, 8GB, and runs Windows 11. It uses WSL version 2. It is fast enough for my 40Kloc compiler to self-host itself repeatedly at about 15Hz (ie. produce 15 new generations per second). And that is using unoptimised x64 code: c:\mx2>tim ms ms ms ms ms ms ms ms ms ms ms ms ms ms ms hello Hello, World Time: 1.017 Hmm, I'm only counting 14 'ms' after the first. So apologies, it is only 14Hz! > >> 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. You said this: DB: >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. But this is also very interesting: right from the start, I've been making the point that the figures I got were far slower than expected for the task. Here it seems you are saying the same thing. Yet I'm the one who gets repeatedly castigated. >> 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. There's nothing wrong with my environment. My PC is a supercomputer compared with even 1970s mainframes and certainly compared to 1980s PCs.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-31 02:14 +0000 |
| Message-ID | <10e1618$5abc$1@dont-email.me> |
| In reply to | #394987 |
On 30/10/2025 23:49, bart wrote: > On 30/10/2025 15:04, David Brown wrote: >> On 30/10/2025 13:07, bart wrote: > >> 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. > > The machine is from 2021. It has an SSD, 8GB, and runs Windows 11. It > uses WSL version 2. > > It is fast enough for my 40Kloc compiler to self-host itself repeatedly > at about 15Hz (ie. produce 15 new generations per second). And that is > using unoptimised x64 code: > > c:\mx2>tim ms ms ms ms ms ms ms ms ms ms ms ms ms ms ms hello > Hello, World > Time: 1.017 > > Hmm, I'm only counting 14 'ms' after the first. So apologies, it is only > 14Hz! That timing is from the current compiler. The more streamlined one I'm working on now (where the IL plays a smaller role) can manage 16Hz; 14% faster. There are a few sluggish areas I want to look at. And yes it is more of a sport now than a real need. My compilers ought to be slow as they have so many passes. Tcc supposedly has only one. So another project I might have a go at is a single-pass C compiler that is faster than Tcc. Just to see how fast I can go at producing native code. However, if the code is too poor, there will be lots of it, and it will slow down the latter stages. I'll have to see.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-31 22:01 +0000 |
| Message-ID | <10e3bji$bm9d$2@paganini.bofh.team> |
| In reply to | #394964 |
bart <bc@freeuk.com> wrote:
> On 30/10/2025 10:15, David Brown wrote:
>> On 30/10/2025 01:36, bart wrote:
>
>>> 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.
<snip>
>
> 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.
Yes, I wrote this. 90 seconds in itself could be OK, your machine
just could be slow. But the numbers you gave clearly show that
that only about 50% of time on _one_ core is used to do the build.
So something is slowing down your machine. And this is specific to
your setup, as other people running build on Linux get better than
90% CPU utilization. You apparently get offended by this statement.
If you are realy interested if fast tools you should investigate
what is causing this.
Anyway, there could be a lot of different reasons for slowdown.
Fact that you get 3 times faster build using 'make -j' suggests
that some other program is competing for CPU and using more jobs
allows getting higher share of CPU. If that affects only programs
running under WSL, than your numbers may or may not be relevant to
WSL experience, but are incomparable to Linux timings. If slowdown
affects all programs on your machine, then you should be interested
in eliminating it, because it would also make your compiler faster.
But that is your machine, if you not curious what happens that
is OK.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-01 11:57 +0000 |
| Message-ID | <10e4sk6$181fu$1@dont-email.me> |
| In reply to | #395018 |
On 31/10/2025 22:01, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 30/10/2025 10:15, David Brown wrote:
>>> On 30/10/2025 01:36, bart wrote:
>>
>>>> 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.
> <snip>
>>
>> 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.
>
> Yes, I wrote this. 90 seconds in itself could be OK, your machine
> just could be slow. But the numbers you gave clearly show that
> that only about 50% of time on _one_ core is used to do the build.
> So something is slowing down your machine. And this is specific to
> your setup, as other people running build on Linux get better than
> 90% CPU utilization. You apparently get offended by this statement.
> If you are realy interested if fast tools you should investigate
> what is causing this.
>
> Anyway, there could be a lot of different reasons for slowdown.
> Fact that you get 3 times faster build using 'make -j' suggests
> that some other program is competing for CPU and using more jobs
> allows getting higher share of CPU. If that affects only programs
> running under WSL, than your numbers may or may not be relevant to
> WSL experience, but are incomparable to Linux timings. If slowdown
> affects all programs on your machine, then you should be interested
> in eliminating it, because it would also make your compiler faster.
> But that is your machine, if you not curious what happens that
> is OK.
I'm really not interested in finding out the ins and outs of my Linux
system or messing about with it.
All I know is that I followed the instructions and the built-time for a
particular project WAS 90 seconds elapsed, after that configure stuff.
It shouldn't be job to fix any shortcomings.
I wasn't that happy either with using '-j'. Yes I got a faster time, but
that looks to me like brushing things under the carpet. What is really
going on? It's hard to tell because it's all so complicated.
I had a go anyway. I logged the output of a full 'make'. The output
(sans some make-lines at each end) was 213 lines: 107 invocations of
gcc, and 106 uses of 'mv'.
I was able to use that output file as a script (and I didn't need
'clean' before each run).
It still took 92 seconds. I got rid of the 'mv' lines, it was now 85
seconds. I added some commands, 'echo n' before each compile, and
'time', to track each invocation.
It looks like there are 106 files compiled, and last use of gcc is for
linking, which took 3.x seconds. Most compiles were 0.5-0.8 seconds,
with a few taking 1-2 seconds, all elapsed 'real' time.
In each case, the user time was a fraction of the real time. One that
caught my eye was file # 4: 0.450s real, 0.08s user.
I tried to extract the invocation and simplify it, but it was too
complicated. It looks like this (line breaks added):
gcc -DHAVE_CONFIG_H -I. -I./src/include -D_GNU_SOURCE
-DBINDIR='"/usr/local/bin"' -DINCLUDEDIR='"/usr/local/include"'
-g -O2 --std=c17 -Wall -Wshadow -Wunused-variable -Wunused-parameter
-Wno-long-long -MT ./src/a68g/a68g-a68g-conversion.o
-MD -MP -MF ./src/a68g/.deps/a68g-a68g-conversion.Tpo -c
-o ./src/a68g/a68g-a68g-conversion.o
`test -f './src/a68g/a68g-conversion.c' ||
echo './'`./src/a68g/a68g-conversion.c
I've no idea what this is up to. But here, I managed to compile that
file my way (I copied it to a place where the relevant headers were all
in one place):
gcc -O2 -c a68g-conversion.c
Now real time is 0.14 seconds (recall it was 0.45). User time is still
0.08s.
So, what is all that crap that is making it 3 times slower? And do we
need all those -Wall checks, given that this is a working, debugged program?
I suggest a better approach would be to get rid of that rubbish and
simplify it, rather than keep it in but having to call in reinforcements
by employing extra cores, don't you think?
> If slowdown
> affects all programs on your machine, then you should be interested
> in eliminating it, because it would also make your compiler faster.
That would be interesting. My already heavy 6-pass compiler can manage a
sustained 0.5Mlps on the same machine, /and/ under Windows. How much
faster can it be?
OK, I have a way to run my C compiler under Linux. It would be a
cross-compiler for Windows, and wouldn't be able to generate EXEs (needs
access to actual Windows DLLS), but it can generate OBJ files.
It's done via C transpilation, and I compared such versions on both
Windows and WSL:
c:\cx>tim cc -c sql
Compiling sql.c to sql.obj
Time: 0.187
root@DESKTOP-11:/mnt/c/cx# time ./cu -c sql.c
Compiling sql.c to sql.obj
real 0m0.316s
user 0m0.170s
sys 0m0.075s
The 'user' time looks about the same as what I get on Windows. I just
get a longer elapsed time on Linux!
(Note: the 'tim' utility on Windows is written to exclude the shell
process start overheads, since I want actual compile-time. Normally my
compilers are invoked from an IDE program - not using 'system' - so that
overhead is not relevant.
If included, the Windows timing would be 0.21 seconds.)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-01 14:56 +0000 |
| Message-ID | <10e573q$1aj22$1@dont-email.me> |
| In reply to | #395027 |
On 01/11/2025 11:57, bart wrote: > On 31/10/2025 22:01, Waldek Hebisch wrote: >> Anyway, there could be a lot of different reasons for slowdown. >> Fact that you get 3 times faster build using 'make -j' suggests >> that some other program is competing for CPU and using more jobs >> allows getting higher share of CPU. If that affects only programs >> running under WSL, than your numbers may or may not be relevant to >> WSL experience, but are incomparable to Linux timings. If slowdown >> affects all programs on your machine, then you should be interested >> in eliminating it, because it would also make your compiler faster. >> But that is your machine, if you not curious what happens that >> is OK. > I've no idea what this is up to. But here, I managed to compile that > file my way (I copied it to a place where the relevant headers were all > in one place): > > gcc -O2 -c a68g-conversion.c > > Now real time is 0.14 seconds (recall it was 0.45). User time is still > 0.08s. > > So, what is all that crap that is making it 3 times slower? And do we > need all those -Wall checks, given that this is a working, debugged > program? > > I suggest a better approach would be to get rid of that rubbish and > simplify it, rather than keep it in but having to call in reinforcements > by employing extra cores, don't you think? I can now compile and link the 106 C modules of A68G into an executable, using my simple approach. The @ file below is invoked as 'gcc -O2 @file'. For this test, all relevant files are in one place for simplicity. Only a single invocation of gcc is used (multiple invocations would be needed to parallise, assuming gcc doesn't have such abilities itself). It took 38 seconds (30 seconds user) on a single core. Using -O0, it took 18/10 seconds. The generated A68 binary is 1.7MB. If I use -Os instead of -O2, the size is just 1MB, and build time is 35s elapsed. The benchmark is only slightly slower. It appears that the purpose of './configure' is to generate a 440-line header called 'a68g-config.h'. The BINDIR macro is needed only for plugin-script.c. ----------------------------- -o a68 -s -DBINDIR='"/usr/local/bin"' --std=c17 a68g-apropos.c a68g-bits.c a68g-conversion.c a68g-diagnostics.c a68g-io.c a68g-keywords.c a68g-listing.c a68g-mem.c a68g-non-terminal.c a68g-options.c a68g-path.c a68g-postulates.c a68g-pretty.c a68g.c double-gamic.c double-math.c double.c genie-assign.c genie-call.c genie-coerce.c genie-declaration.c genie-denotation.c genie-enclosed.c genie-formula.c genie-hip.c genie-identifier.c genie-misc.c genie-regex.c genie-rows.c genie-stowed.c genie-unix.c genie.c moids-diagnostics.c moids-misc.c moids-size.c moids-to-string.c mp-bits.c mp-complex.c mp-gamic.c mp-gamma.c mp-genie.c mp-math.c mp-mpfr.c mp-pi.c mp.c parser-annotate.c parser-bottom-up.c parser-brackets.c parser-extract.c parser-modes.c parser-moids-check.c parser-moids-coerce.c parser-moids-equivalence.c parser-refinement.c parser-scanner.c parser-scope.c parser-taxes.c parser-top-down.c parser-victal.c parser.c plugin-basic.c plugin-driver.c plugin-folder.c plugin-gen.c plugin-inline.c plugin-script.c plugin-tables.c plugin.c prelude-bits.c prelude-gsl.c prelude-mathlib.c prelude.c rts-bool.c rts-char.c rts-curl.c rts-curses.c rts-enquiries.c rts-formatted.c rts-heap.c rts-int128.c rts-internal.c rts-mach.c rts-monitor.c rts-parallel.c rts-plotutils.c rts-postgresql.c rts-sounds.c rts-stowed.c rts-transput.c rts-unformatted.c single-blas.c single-decomposition.c single-fft.c single-gamic.c single-gsl.c single-laplace.c single-math.c single-multivariate.c single-physics.c single-python.c single-r-math.c single-rnd.c single-svd.c single-torrix-gsl.c single-torrix.c single.c -lncursesw -ldl -lpthread -lgmp -lquadmath -lrt -lm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-30 13:37 -0700 |
| Message-ID | <87qzuk5dnu.fsf@example.invalid> |
| In reply to | #394962 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Try "time make -j" as a simple step.
[...]
In my recent testing, "make -j" without a numeric argument (which
tells make to run as many parallel steps as possible) caused my
system to bog down badly. This was on a fairly large project (I used
vim); it might not be as much of a problem with a smaller project.
I've found that "make -j $(nproc)" is safer. The "nproc" command
is likely to be available on any system that has a "make" command.
It occurs to me that "make -j N" can fail if the Makefile does
not correctly reflect all the dependencies. I suspect this is
less likely to be a problem if the Makefile is generated rather
than hand-written.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 23:37 +0100 |
| Message-ID | <10e0par$1d23$1@dont-email.me> |
| In reply to | #394981 |
On 30/10/2025 21:37, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Try "time make -j" as a simple step. > [...] > > In my recent testing, "make -j" without a numeric argument (which > tells make to run as many parallel steps as possible) caused my > system to bog down badly. This was on a fairly large project (I used > vim); it might not be as much of a problem with a smaller project. > > I've found that "make -j $(nproc)" is safer. The "nproc" command > is likely to be available on any system that has a "make" command. > > It occurs to me that "make -j N" can fail if the Makefile does > not correctly reflect all the dependencies. I suspect this is > less likely to be a problem if the Makefile is generated rather > than hand-written. > There certainly are makefile builds that might not work correctly with parallel builds. And I think you are right that this is typically a dependency specification issue, and that generating dependencies automatically in some way should have lower risk of problems. I think it is also typically on older makefiles - from the days of single core machines where "make -j N" was not considered - that had such issues.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2025-10-31 11:52 +0100 |
| Message-ID | <10e24e9$16dt$1@news.gegeweb.eu> |
| In reply to | #394983 |
On 10/30/25 23:37, David Brown wrote:
> There certainly are makefile builds that might not work correctly with
> parallel builds. And I think you are right that this is typically a
> dependency specification issue, and that generating dependencies
> automatically in some way should have lower risk of problems.
I have encountered a case where to actions run in parallel
overwrite a badly named temp file, same file for two process
is definitively wrong :(
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-31 13:48 +0000 |
| Message-ID | <F63NQ.229705$RB68.25615@fx39.iad> |
| In reply to | #394983 |
David Brown <david.brown@hesbynett.no> writes: >On 30/10/2025 21:37, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> Try "time make -j" as a simple step. >> [...] >> >> In my recent testing, "make -j" without a numeric argument (which >> tells make to run as many parallel steps as possible) caused my >> system to bog down badly. This was on a fairly large project (I used >> vim); it might not be as much of a problem with a smaller project. >> >> I've found that "make -j $(nproc)" is safer. The "nproc" command >> is likely to be available on any system that has a "make" command. >> >> It occurs to me that "make -j N" can fail if the Makefile does >> not correctly reflect all the dependencies. I suspect this is >> less likely to be a problem if the Makefile is generated rather >> than hand-written. >> > >There certainly are makefile builds that might not work correctly with >parallel builds. And I think you are right that this is typically a >dependency specification issue, and that generating dependencies >automatically in some way should have lower risk of problems. I think >it is also typically on older makefiles - from the days of single core >machines where "make -j N" was not considered - that had such issues. > Hence the development of tools like 'mkdepend' (from X11, IIRC). Modern gcc includes all the support necessary to generate dependency files used by make(1) to reduce [re-]build times.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@vallor.earth> |
|---|---|
| Date | 2025-10-29 23:11 +0000 |
| Message-ID | <10du6v8$39i9v$1@dont-email.me> |
| In reply to | #394942 |
At Wed, 29 Oct 2025 21:21:34 +0000, bart <bc@freeuk.com> wrote: > On 29/10/2025 16:12, David Brown wrote: > > On 29/10/2025 00:14, bart wrote: > >> On 28/10/2025 21:59, Keith Thompson wrote: > >>> bart <bc@freeuk.com> writes: > >>>> On 28/10/2025 02:35, Janis Papanagnou wrote: > >>>>> On 27.10.2025 16:11, bart wrote: > >>> [...] > >>>>>> If speed wasn't an issue then we'd all be using easy dynamic > >>>>>> languages > >>>>> Huh? - Certainly not. > >>>> > >>>> *I* would! That's why I made my scripting languages as fast and > >>>> capable as possible, so they could be used for more tasks. > >>>> > >>>> However, if I dare to suggest that even one other person in the world > >>>> might also have the same desire, you'd say that I can't possibly know > >>>> that. > >>>> > >>>> And yet here you are: you say 'certainly not'. Obviously *you* know > >>>> everyone else's mindset! > >>> > >>> I'll give this one more try. > >>> > >>> This kind of thing makes it difficult to communicate with you. > >> > >> You're talking to the wrong guy. It's JP who's difficult to talk to. > >> > >> He (I assume) always dismisses every single one of my arguments out of > >> hand: > >> > >> Build speed is never a problem - ever. The speed of any language > >> implemention is never a concern either. > >> > > > > Bart, I think this all comes down to some basic logic that you get wrong > > regularly : > > > > The opposite of "X is always true" is /not/ "X is always false" or that > > "(not X) is always true". It is that "X is /sometimes/ false", or that > > "(not X) is /sometimes/ true". > > > > You get this wrong repeatedly when you and I are in disagreement, and I > > see it again and again with other people - such as with both Janis and > > Keith. > > > > No one, in any of the posts I have read in c.l.c. in countless years, > > has ever claimed that "build speed is /never/ a problem". People have > > regularly said that it /often/ is not a problem, or it is not a problem > > in their own work, or that slow compile times can often be dealt with in > > various ways so that it is not a problem. People don't disagree that > > build speed can be an issue - they disagree with your claims that it > > is /always/ an issue (except when using /your/ tools, or perhaps tcc). > > 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). Not sure if it's worth it, but my 2 cents: You can throw more processors at your "make" with the "-j" switch, something like: $ make -j $(nproc) Where $(nproc) substitutes the number of processors on your system for a parallel make. > > A68G I know takes 90 seconds to build (since I've just tried it again; > it took long enough that I had an ice-cream while waiting, so that's > something). > > That's under 1Kloc per second; not great. > > But at least all the optimising would have produced a super-fast > executable? Well, that's disappointing too; no-one can say that A68G is > fast. > > I said that my equivalent product was 1000 times faster to build (don't > forget the configure nonsense) and it ran 10 times faster on the same test. > > That is a quite remarkable difference. VERY remarkable. Only some of it > is due to my product being smaller (but it's not 1000 times smaller!). > > This was stated to demonstrate how different my world was. > > My view is that there is something very wrong with the build systems > everyone here uses. But I can understand that no one wants to admit that > they're that bad. > > You find ways around it, you get inured to it, but you just have to use > much more powerful machines than mine, but I would go round the bend if > I had to work with something so unresponsive. > -- -v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G OS: Linux 6.17.5 D: Mint 22.2 DE: Xfce 4.18 NVIDIA: 580.95.05 Mem: 258G "Let's split up, we can do more damage that way."
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-29 06:57 +0100 |
| Message-ID | <10dsabo$2monf$1@dont-email.me> |
| In reply to | #394879 |
On 28.10.2025 12:16, bart wrote: > On 28/10/2025 02:35, Janis Papanagnou wrote: >> On 27.10.2025 16:11, bart wrote: > >> That's meaningless, but if you're interested to know... >> Mostly (including my professional work) I've probably used C++. >> But also other languages, depending on either projects' requirements >> or, where there was a choice, what appeared to be fitting best (and >> "best" sadly includes also bad languages if there's no alternative). > > Which bad languages are these? Are you hunting for a language war discussion? - I won't start it here. If you want, please start an appropriate topic in comp.lang.misc or so. > [...] > > That CDECL took, what, 49 seconds on my machine, to process 68Kloc of C? > That's a whopping 1400 lines per second! > > If we go back 45 years to machines that were 1000 times slower, We are not in these days any more. Nowadays there's much more complex software; some inherently bad designed software, and in other cases they might not care about tweaking the last second out of a process (for various reasons). So this comparison isn't really contributing anything here. > the same > process would only manage 1.4 lines per second, and it would take 13 > HOURS, to create an interactive program that explained what 'int > (*(*(*)))[]()' (whatever it was) might mean. If that's the sole task of the program the speed is not very appealing. But I had not looked into the code, the algorithms implemented, or the features it supports. Criticism may be justified, maybe not. But you're creating a tool just once, and then use it arbitrary times. This is as a user of the tool. So why you care so much is beyond me. As a developer of the tool the used algorithms and the build process is under your control. > > So, yeah, build-time is a problem, even on the ultra-fast hardware we > have now. What problem? - That you don't want to wait a few seconds? - Or that you cannot use that tool when time-traveling "back 45 years"? > > Bear in mind that CDECL (like every finished product you build from > source) is a working, debugged program. You shouldn't need to do that > much analysis of it. And here, its performance is not critical either: > you don't even need fast code from it. (Erm.. - so after the rant you're now agreeing?) > >> (I recall you were unfamiliar with make >> files, or am I misremembering?) > > I know makefiles. Never used them, never will. (Do what you prefer. - After all you're not cooperating with others in your personal projects, as I understood, so there's no need to "learn" [or just use!] things you don't like. If you think it's a good idea to spend time in writing own code for already solved tasks, I'm fine with that.) > You might recall that I create my own solutions. I don't recall, to be honest. But let's rather say; I'm not astonished that you have "created your own solutions". (Where other folks would just use an already existing, flexibly and simply usable, working and supported solution.) - So that's your problem not anyone else's. > >>> >>> Now imagine further if the CPython interpreter was inself written and >>> executed with CPython. >>> >>> So, the 'speed' of a language (ie. of its typical implementation, which >>> also depends on the language design) does matter. >>> >>> If speed wasn't an issue then we'd all be using easy dynamic languages >> >> Huh? - Certainly not. > > *I* would! That's why I made my scripting languages as fast and capable > as possible, so they could be used for more tasks. Sure, you would. Obviously. - You've never been the widely accepted standard source for sensible general purpose solutions, though. > > However, if I dare to suggest that even one other person in the world > might also have the same desire, you'd say that I can't possibly know that. You had presented your statement as if there'd be a pressing logical decision route. It is not. > > And yet here you are: you say 'certainly not'. Obviously *you* know > everyone else's mindset! No. I neither said nor implied that. (I suggest to re-read what you said and what I wrote.) > >> Speed is a topic, but as I wrote you have to put it in context > > Actually, the real topic is slowness. I'm constantly coming across > things which I know (from half a century working with computers) are far > slower than they ought to be. Fair enough. > > But I'm also coming across people who seem to accept that slowness as > just how things are. They should question things more! I also think that there a not few people that accept inferior quality; how else could the success of, say, DOS, Windows, and off-the-shelf MS office software, be explained. Or some persistent deficiencies in some GNU/Linux tools and runtime system. Or services presented per Web interface. Speed is one factor. (I said that before.) > >> I can't tell about the "many" that you have in mind, and about their >> mindset; I'm sure you either can't tell. > > I'm pretty sure there are quite a few million users of scripting languages. This is of no doubt, I'd say. What was arguable was the made-up _decision step_ concerning speed and "scripting languages". > >> >> I'm using for very specific types of tasks "scripting languages" - >> and keep in mind that there's no clean definition of that! > > They have typical characteristics as I'm quite sure you're aware. For > example: Yes, you're right, since I mentioned them I'm aware of them. But they are not serving a clear definition of "scripting languages"; they are basically just hints. > > * Dynamic typing Marcel van der Veer is advertising Genie (his Algol 68 interpreter) as a system usable for scripting. (With no dynamic but static typing.) > * Run from source How about JIT, how about intermediate languages? > * Instant edit-run cycle > * Possible REPL > * Uncluttered syntax Have a look at the syntax of (e.g.) the Unix shell "scripting language". > * Higher level features Not a distinguished characteristic of scripting languages. > * Extensive libraries so that you can quickly 'script' most tasks Awk (for example) is a stand-alone scripting language. > > So, interactivity and spontaneity. But they also have cons: > > * Slower execution Yes, but they can be rather fast (with intermediate code (GNU Awk), precompiled language elements (Genie), or other means). It very much depends on the languages, on "both types" of languages. > * Little compile-time error checking (We already commented in your above point "Dynamic typing".) > * Less control (of data structures for example) Not sure what you mean (control constructs, more data structures). But have a look into Unix shells for control constructs, and into Kornshell specifically for data structures. It's a very inhomogeneous area. Impossible to clearly classify. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-29 14:17 +0200 |
| Message-ID | <20251029141714.00003385@yahoo.com> |
| In reply to | #394930 |
On Wed, 29 Oct 2025 06:57:10 +0100 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 28.10.2025 12:16, bart wrote: > > > * Less control (of data structures for example) > > Not sure what you mean (control constructs, more data structures). > But have a look into Unix shells for control constructs, and into > Kornshell specifically for data structures. > > It's a very inhomogeneous area. Impossible to clearly classify. > > Janis > Less control of data structures means less control of data structures. In some (not all) non-scripting languages we have ether full control of the layout of records (Ada) or at least non-full-but-good-enough-in- practice-if-one-knows-what-he-is-doing control (C). In scripting languages the same effect often has to be achieved by coding binary parser in imperative manner. Imperative style in this case is less convenient and more error-prone than declarative style available in Ada and C. However there are many none-scripting language, including few of the most popular (Java, C#) that in this regard are not better than your typical scripting language. So, may be, better division here would be not "dynamic,scripting vs statically-typed, non-scripting", but "system-oriented languages vs application-oriented languages".
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 14:40 +0000 |
| Message-ID | <10dt91f$2vlf1$1@dont-email.me> |
| In reply to | #394930 |
On 29/10/2025 05:57, Janis Papanagnou wrote:
> On 28.10.2025 12:16, bart wrote:
>> On 28/10/2025 02:35, Janis Papanagnou wrote:
>>> On 27.10.2025 16:11, bart wrote:
>>
>>> That's meaningless, but if you're interested to know...
>>> Mostly (including my professional work) I've probably used C++.
>>> But also other languages, depending on either projects' requirements
>>> or, where there was a choice, what appeared to be fitting best (and
>>> "best" sadly includes also bad languages if there's no alternative).
>>
>> Which bad languages are these?
>
> Are you hunting for a language war discussion? - I won't start it here.
> If you want, please start an appropriate topic in comp.lang.misc or so.
I'm just looking for /anything/ you don't like! Since you seem to be
remarkably uncritical of everything - except all the stuff I do.
>
>> [...]
>>
>> That CDECL took, what, 49 seconds on my machine, to process 68Kloc of C?
>> That's a whopping 1400 lines per second!
>>
>> If we go back 45 years to machines that were 1000 times slower,
>
> We are not in these days any more.
The point of the comparison to 1000-times slower hardware is to
highlight how remarkably slow some modern toolsets are.
> Nowadays there's much more complex
> software; some inherently bad designed software, and in other cases
> they might not care about tweaking the last second out of a process
> (for various reasons). So this comparison isn't really contributing
> anything here.
Software might be bigger, but that is why you use LPS figures rather
than overall build-time.
However, I also picked on this task since it wouldn't have changed
signicantly over those decades.
>> So, yeah, build-time is a problem, even on the ultra-fast hardware we
>> have now.
>
> What problem? - That you don't want to wait a few seconds?
You KNOW compile- and build-times can be a serious bottleneck, and
people are looking into ways to improve that, other than throwing extra
hardware resources at it.
Either you haven't experienced that, or you are remarkably tolerant and
patient.
The actual problem I picked up on is that the build-time was out of
proportion to the scale of the task. In this case of a one-off build, it
is not that consequential. But it suggests something is wrong.
On current hardware we must surely be able to do better than 1-2K lines
per second, even if optimising. And I know we can because some products,
not just mine, can manage 500-1000 times faster.
>> I know makefiles. Never used them, never will.
>
> (Do what you prefer. - After all you're not cooperating with others in
> your personal projects, as I understood, so there's no need to "learn"
> [or just use!] things you don't like. If you think it's a good idea to
> spend time in writing own code for already solved tasks, I'm fine with
> that.)
>
>> You might recall that I create my own solutions.
>
> I don't recall, to be honest. But let's rather say; I'm not astonished
> that you have "created your own solutions". (Where other folks would
> just use an already existing, flexibly and simply usable, working and
> supported solution.) - So that's your problem not anyone else's.
Because existing solutions DIDN'T EXIST in a practical form (remember I
worked with 8-bit computers), or they were hopelessly slow and
complicated on restricted hardware.
I don't need a linker, I don't need a makefile, I don't need lists of
dependencies between modules, I don't need independent compilation, I
don't use object files.
The generated makefile for the 49-module CDECL project is 2000 lines of
gobbledygook; that's not really selling it to me!
If *I* had a 49-module C project, the build info I'd supply you would
basically be that list of files, plus the source files.
With my language, you'd need exactly two files: a self-contained
compiler, and a self-contained source file amalgamation. For a 600KB
binary, it might take as much as 0.2 seconds to build.
I consider that a more satisfactory solution that writing 2000 lines of
garbage. YMMV.
> I also think that there a not few people that accept inferior quality;
> how else could the success of, say, DOS, Windows, and off-the-shelf
> MS office software, be explained.
MS products are fairly solid. They are superb at backwards compatibility
and at compatibility across machines in general. That's why Windows apps
can be supplied as binaries that will work on any Windows machine.
However they tend to be absolutely huge, complicated and slow, even more
so than any Linux tools. (It once took 90 minutes to install VS.
Starting it - usually inadvertently due to file associations - took 90
seconds.)
>> * Dynamic typing
>
> Marcel van der Veer is advertising Genie (his Algol 68 interpreter) as
> a system usable for scripting. (With no dynamic but static typing.)
This product is unusual, but then it's not clear where Algol 68 lies.
It's a not really a static language like C, Rust, Zig, Go, Java ... but
it's also not as high-level as ones like Haskell or OCaml, which are
static or type-infered.
The first group are usually compiled but may offer interpreted options.
Such languages can be naturally converted to performant native code.
However A68G prioritises interpretation. While there is a
compile-to-native option, it's not very performant.
So overall it's a curiosity. (An interesting one because after several
decades, I was finally able to try out Algol68 for real. I wasn't
impressed, and nothing to do with its speed either.)
>> * Run from source
>
> How about JIT, how about intermediate languages?
Intermediate languages (designed for compiler backends) are irrelevant.
Whether they even have a textual source format is a detail.
JIT-ing used in place of AOT-compilation for static languages is
something new. I haven't come across examples so I don't know how it
comes across, or what latencies there might be.
Personally, I can run both C (single file programs ATM) and my languages
directly from source, with no discernible delay, via a VERY FAST AOT
step. But I wouldn't class them as scripting languages for other reasons.
>> * Little compile-time error checking
>
> (We already commented in your above point "Dynamic typing".)
There's more that could be done. Take:
F(x, y, z)
F is a function in some imported module. In most dynamic languages, the
import is done at runtime so the number of arguments, or if F is even a
function can't be checked at compile-time.
In my dynamic language, the import is done at compile-time so there's
more that can be checked in advance. It's less dynamic, but x, y, z can
still be dynamically typed.
>> * Less control (of data structures for example)
>
> Not sure what you mean (control constructs, more data structures).
I mean things like layouts of structs, or even the exact form of an
array. Again, mine has FFI abilities built-in, and directly supports
C-like data types.
So either of these user types can be defined:
record date1 =
var d, m, y # can hold any types
end
type date2 = struct
u8 d, m
u16 y
end
An instance of the latter occupies 4 bytes; of the former, 48+32 bytes
plus whatever big data the members may contain.
Most dynamic languages don't natively support that latter kind of data
type. Actually many don't even directly have records with named fields
like the first. They have be to emulated.
> It's a very inhomogeneous area. Impossible to clearly classify.
Ask some people for examples of what they think of as scripting
languages. I'd be interested in what they say.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2025-10-29 16:09 +0100 |
| Message-ID | <10dtan0$lv6$1@news.gegeweb.eu> |
| In reply to | #394934 |
On 10/29/25 15:40, bart wrote:
>
> I don't need a linker, I don't need a makefile, I don't need lists of
> dependencies between modules, I don't need independent compilation, I
> don't use object files.
>
s/don't need/refuse to use/
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 16:47 +0000 |
| Message-ID | <10dtgfb$329ot$1@dont-email.me> |
| In reply to | #394935 |
On 29/10/2025 15:09, tTh wrote: > On 10/29/25 15:40, bart wrote: >> >> I don't need a linker, I don't need a makefile, I don't need lists of >> dependencies between modules, I don't need independent compilation, I >> don't use object files. >> > > s/don't need/refuse to use/ It looks like Python refuses to use all those things too! Think about that, then think about how it might be possible for a language and implementation to use an alternate path to get from source code to executable. One that is simpler.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-30 05:11 +0000 |
| Message-ID | <10dus1k$3usf7$1@paganini.bofh.team> |
| In reply to | #394934 |
bart <bc@freeuk.com> wrote:
>
> Because existing solutions DIDN'T EXIST in a practical form (remember I
> worked with 8-bit computers), or they were hopelessly slow and
> complicated on restricted hardware.
>
> I don't need a linker, I don't need a makefile, I don't need lists of
> dependencies between modules, I don't need independent compilation, I
> don't use object files.
>
> The generated makefile for the 49-module CDECL project is 2000 lines of
> gobbledygook; that's not really selling it to me!
>
> If *I* had a 49-module C project, the build info I'd supply you would
> basically be that list of files, plus the source files.
I sometime work with 8-bit microcontrollers. More frequently I work
with 32-bit microcontrollers of size comparable to 8-bit
microcontrollers. One target has 4 kB RAM (plus 16 kB flash for
storing programs). On such targets I care about program size.
I found it convenient during developement to run programs from
RAM, so ideally program + data should fit in 4 kB. And frequently
it fits. I have separate modules. For example, usually before
doing anything else I need to configure the clock. Needed clock
speed depends on program. I could use a general clock setting
routine that can set "any" clock speed. But such routine would
be more complicated and consequently bigger than a more specialized
one. So I have a few versions so that each version sets a single
clock speed and is doing only what is necessary for this speed.
Microcontrollers contain several built-in devices, they need
drivers. But it is almost impossible to use all devices and
given program usually uses only a few devices. So in programs
I just include what is needed.
My developement process is work in progress, there are some
things which I would like to improve. But I need to organize
things, for which I use files. There are compiler options,
paths to tools and libraries. In other words, there is
essential info outside C files. I use Makefile-s to record
this info. It is quite likely that in the future I will
have a tool to create specialized C code from higher level
information. In such case my dependecies will get more
complex.
Modern microcontrollers are quite fast compared to their
typical tasks, so most of the time speed of code is not
critical. But I write interrupt handlers and typically
interrupt handler should be as fast as possible, so speed
matters here. And as I wrote size of compiled code is
important. So compiler that quickly generates slow and big
code is of limited use to me. Given that files are usually
rather small I find gcc speed reasonable (during developement
I usually do not need to wait for compilation, it is fast
enough).
Certainly better compiler is possible. But given need to
generate reasonably good code for several differen CPU-s
(there are a few major familes and within family there are
variations affecting generated code) this is big task.
One could have better language than C. But currenly it
seems that I will be able to get features that I want by
generating code. Of course, if you look at whole toolchain
and developement process this is much more complicated than
specialized compiler for specialized language. But creating
whole environment with features that I want is a big task.
By using gcc I reduce amount of work that _I_ need to do.
I wrote several pieces of code that are available in existing
libraries (because I wanted to have smaller specialized
version), so I probably do more work than typical developer.
But life is finite so one need to choose what is worth
(re)doing as opposed to reusing existing code.
BTW: Using usual recipes, frequently gives much bigger programs,
for example program blinking a LED (embedded equivelent of
"Hello world") may take 20-30 kB (with my approach it is
552 bytes, most of which is essentially forced by MCU
architecure).
So, gcc and make _I_ find useful. For microcontroller
projects I currently do not need 'configure' and related
machinery, but do not exlude that in the future.
Note that while I am developing programs, my focus is on
providing a library and developement process. That is
potential user is supposed to write code which should
integrate with code that I wrote. So I either need
some amalgamation at source level or linking. ATM linking
works better. So I need linking, in the sense that if
I were forbiden to use linking, I would have to develop
some replacement and that could be substantial work and
inconvenience, for example textual amalgamation would
increase build time from rather satisfactory now to
probably noticable delay.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 12:56 +0000 |
| Message-ID | <10dvna8$3mfqh$1@dont-email.me> |
| In reply to | #394958 |
On 30/10/2025 05:11, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> >> Because existing solutions DIDN'T EXIST in a practical form (remember I >> worked with 8-bit computers), or they were hopelessly slow and >> complicated on restricted hardware. >> >> I don't need a linker, I don't need a makefile, I don't need lists of >> dependencies between modules, I don't need independent compilation, I >> don't use object files. >> >> The generated makefile for the 49-module CDECL project is 2000 lines of >> gobbledygook; that's not really selling it to me! >> >> If *I* had a 49-module C project, the build info I'd supply you would >> basically be that list of files, plus the source files. > > I sometime work with 8-bit microcontrollers. More frequently I work > with 32-bit microcontrollers of size comparable to 8-bit > microcontrollers. One target has 4 kB RAM (plus 16 kB flash for > storing programs). On such targets I care about program size. > I found it convenient during developement to run programs from > RAM, so ideally program + data should fit in 4 kB. And frequently > it fits. I have separate modules. For example, usually before > doing anything else I need to configure the clock. Needed clock > speed depends on program. I could use a general clock setting > routine that can set "any" clock speed. But such routine would > be more complicated and consequently bigger than a more specialized > one. So I have a few versions so that each version sets a single > clock speed and is doing only what is necessary for this speed. > Microcontrollers contain several built-in devices, they need > drivers. But it is almost impossible to use all devices and > given program usually uses only a few devices. So in programs > I just include what is needed. > > My developement process is work in progress, there are some > things which I would like to improve. But I need to organize > things, for which I use files. There are compiler options, > paths to tools and libraries. In other words, there is > essential info outside C files. I use Makefile-s to record > this info. It is quite likely that in the future I will > have a tool to create specialized C code from higher level > information. In such case my dependecies will get more > complex. > > Modern microcontrollers are quite fast compared to their > typical tasks, so most of the time speed of code is not > critical. But I write interrupt handlers and typically > interrupt handler should be as fast as possible, so speed > matters here. And as I wrote size of compiled code is > important. So compiler that quickly generates slow and big > code is of limited use to me. Given that files are usually > rather small I find gcc speed reasonable (during developement > I usually do not need to wait for compilation, it is fast > enough). > > Certainly better compiler is possible. But given need to > generate reasonably good code for several differen CPU-s > (there are a few major familes and within family there are > variations affecting generated code) this is big task. > > One could have better language than C. But currenly it > seems that I will be able to get features that I want by > generating code. Of course, if you look at whole toolchain > and developement process this is much more complicated than > specialized compiler for specialized language. But creating > whole environment with features that I want is a big task. > By using gcc I reduce amount of work that _I_ need to do. > I wrote several pieces of code that are available in existing > libraries (because I wanted to have smaller specialized > version), so I probably do more work than typical developer. > But life is finite so one need to choose what is worth > (re)doing as opposed to reusing existing code. > > BTW: Using usual recipes, frequently gives much bigger programs, > for example program blinking a LED (embedded equivelent of > "Hello world") may take 20-30 kB (with my approach it is > 552 bytes, most of which is essentially forced by MCU > architecure). > > So, gcc and make _I_ find useful. For microcontroller > projects I currently do not need 'configure' and related > machinery, but do not exlude that in the future. > > Note that while I am developing programs, my focus is on > providing a library and developement process. That is > potential user is supposed to write code which should > integrate with code that I wrote. So I either need > some amalgamation at source level or linking. ATM linking > works better. So I need linking, in the sense that if > I were forbiden to use linking, I would have to develop > some replacement and that could be substantial work and > inconvenience, for example textual amalgamation would > increase build time from rather satisfactory now to > probably noticable delay. > My background is unusual. I started off in hardware, and developed a small language and tools to help with my job as test and development engineer, something done on the side. Those tools evolved, and I got used to creating my own solutions, ones that were very productive compared to the (expensive and slow) compilers that were available then. Linking existed, in the form of a 'loader' program that combined multiple object files into one executable; a trivial task IMO, but other people's linkers seemed to make a big deal of it (they still do!). I didn't use makefiles: I had a crude IDE which used a project file, listing my source modules. So the IDE already knew all the which files needed to be submitted for compilation, on the occasions I needed to compile everything. I was also familiar enough with my projects to know when I only need to recompile the one module. In any case, compilation was quite fast even on the early 80s home and business computers I used (and used to help design!). I only use linking now for my C compiler, but that task is done within my assembler; there are no object files. My main language uses a whole-program compiler so linking is not relevant. External libraries are accessed dynamically only. When I wrote commercial apps, where users wanted to add their own content, I provided a scripting language for that. Developing add-ons was done within the running application. Now, if someone wanted to statically link native code from my compiler into their program, or vice versa, I can generate object files in standard format. Then a normal linker is used, but *they* are using the linker; not me! There are other solutions too: others can create libraries that are then used via runtime dynamic-linking. While I also have facilities within my backend to generate executable code in-memory, and that could be made available as a library to user-programs. In short, there are lots of alternatives when you are not limited to traditional tools, but you may have to write them yourself. For most people, that is not feasible or not practical, they will already be heavily invested in dependencies, and it cannot be done overnight anyway. But in my case it allows me to truthfully say: >I don't need a linker, I don't need a makefile, I don't need lists of dependencies between modules, I don't need independent compilation, I don't use object files. However ... I still believe that the build process for lots of C programs, for when a user needs to compile working program, can be vastly simplified. That means makefiles at least are not needed.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-10-28 17:34 -0400 |
| Message-ID | <10drct3$2a744$4@dont-email.me> |
| In reply to | #394850 |
On 2025-10-27 22:35, Janis Papanagnou wrote: ...> been effectively addressed. (I recall you were unfamiliar with make > files, or am I misremembering?) He's heard of make files, and many people have tried to explain them to him, but his comments about them indicate that he completely misunderstands them, to a degree that I find hard to fathom. It's similar to the unbelievable degree of his misunderstandings of C. You don't have to like C - many don't - but if you're going to use it you should try to understand it, and his preferences make it impossible for him to do so.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-31 04:37 +0000 |
| Message-ID | <10e1eep$8l0o$1@paganini.bofh.team> |
| In reply to | #394795 |
bart <bc@freeuk.com> wrote:
> On 27/10/2025 13:39, Janis Papanagnou wrote:
>> On 27.10.2025 13:50, bart wrote:
>>> On 27/10/2025 02:08, Janis Papanagnou wrote:
>>>> On 26.10.2025 12:26, bart wrote:
>
>> Speed is not an end in itself. It must be valued in comparison with
>> all the other often more relevant factors (that you seem to completely
>> miss, even when explained to you).
> Speed seems to be important enough that huge efforts have gone into
> creating the best optimising compilers over decades.
>
> Fantastically complex products like LLVM exist, which take 100 times
> longer to compile code than a naive compiler, in order to eke out the
> last bit of performance.
>
> Similarly, massive investment has gone into making dynamic languages
> fast, like the state-of-the-art products used in running JavaScript, or
> the numerous JIT approaches used to accelerate languages like Python and
> Ruby.
>
> Build-speed is taken seriously enough, and most 'serious' compilers are
> slow enough, that complex build systems exist, which use dependencies in
> order to avoid compilation as much as possible.
>
> Or failing that, by parallelising builds across multiple cores, possibly
> even across distributed machines.
>
> So, fortunately some people take this stuff more seriously than you do.
>
> I am also involved in this field, and my experimental work takes the
> approach of simplicity to achieve results.
>
>
>>
>> I know your goals are space and speed. And that's fine in principle
>> (unless you're ignoring other relevant factors).
>
> LLVM is a backend project which is massively bigger, more complex and
> slower (in build speed) than my stuff, by a number of magnitudes in each
> case.
>
> The resulting code however, might only be a fraction of a magnitude
> faster (for example the 0.3 vs 0.4 timings above, achieved via gcc, but
> LLVM would be similar).
>
> And that's if you apply the optimiser, which I would only use for
> production builds, or for benchmarking. Otherwise its code is just as
> poor as mine, or worse, but it still takes longer to build stuff!
>
> For me the trade-offs of a big, cumbersome product don't work. I like my
> near-zero builds and can work more spontaneously!
>
>>> It's still at least FIVE TIMES FASTER than A68G! [2-3 TIMES FASTER]
>>
>> So what? - I don't need a Lua system. So why should I care.
>>
>> You are the one who seems to think that the speed factor is the most
>> important factor to choose a language for a project. - You are wrong
>> for the general case. (But it may be right for your personal universe,
>> of course.)
>
> You are wrong. What language do you use most? Let's say it is C
> (although you usually post about every other language except C!).
>
> Then, suppose your C compiler was written in Python rather than C++ or
> whatever and run under CPython. What you think would happen to your
> build-times?
>
> Now imagine further if the CPython interpreter was inself written and
> executed with CPython.
>
> So, the 'speed' of a language (ie. of its typical implementation, which
> also depends on the language design) does matter.
>
> If speed wasn't an issue then we'd all be using easy dynamic languages
> for productivity. In reality those easy languages are far too slow in
> most cases.
It is not clear what you mean by "easy dynamic languages". Take
Objective Caml as an example. It has read-eval-print loop, so
you can do interactive developement, so it is quit "dynamic".
It seems that most developement is done using bytecode interpreter,
but there is also optimizing compiler which can boast about
its benchmark results. OTOH, it has strict type system and
you need to stick to its rules. So not entirely easy, but
if you write correct code compiler will automatically assign
types, so you can avoid writing any type declarations.
Do you consider Objective Caml as an "easy dynamic language"?
Concerning choice of language: much code is in big programs and
is quite expensive to rewrite such a program in a different
language. So simply a lot of coding uses the same language
in which program is written. It is also common to write new
parts in a different language, but then the new language must
be link compatible with the old one. For example, classic
algoritmic languages like Fortran, Cobol, Algol, Pascal, C,
Modula 2 or Ada used to have link compatible implementations:
with modest effort one can call routines in one language from
the other.
For me correctness of programs is important and I find
static typing quite helpful in improving correctness.
First, compile time type checks catch a lot of errors
that would otherwise require extensive tests to catch.
In other words, errors are caught earlier than say with
dynamic typing. Second, well defined types serve as
documentation of used data structures and interfaces.
This make my thinking about program clearer which
tends to reduce mistakes that I make.
A lot of folks consider types are hard things and
associate "easy language" with one which is dynamically
typed, or worse essentially untyped.
My experience with dynamically typed languages is that in
largish program there may be essentially nonsense code which
is not executed in normal operation. But rarely it gets
executed leading to crashes or nonsence results. If you have
small project with good developers than this is less of a
problem. Also, practices like "you add tests first and can
only add code to fix failing test" help. But for large
project with average or below average abilities and
requirtement of high quality code typically management want
all possible way to monitor and increase quality. Which
frequenty means using staticaly typed language.
So, compatiblity with existing code may lead to use of
otherwise suboptimal language. Quality usually is opposite
of "easy" and may lead to use of staticaly typed language.
OTOH, for me biggest productivity boost comes from garbage
collection. But AFAIK problem of cooperation between garbage
collectors do not have satisfactory solution. More precisely,
if memory use were not a concern, then one could simply
turn C 'free' into a no-op (and do similar thing in other
languages). Consequently, there would be no garbage
collection and no problem of incompatibility between garbage
collectors. But with easy style of programing, a program
can easiliy allocate say a gigabyte per second. If program
need to run for long time one would get ridiculosly large
memory use. So for short running programs one can somemtimes
tolerate lack of dealocation and garbage collection,
such program simply uses few times more memory than it should.
But for longer running programs you can get unbounded growth
of memory use, which is usually unacceptable.
Also, big attraction of popular mainstream languages are
large libraries, so that many standard tasks are just
a library call or combination of small number of calls.
But somebody must write those libraries and deal with
difficulties. And frequently "easy" languages use libraries
where "hard" parts and written in "hard" languages.
>>>> The tools I'm using for my personal purposes, and those that I had been
>>>> using for professional purposes, all served the necessary requirements.
>>>> Your's don't.
>>>
>>> I'm just showing just how astonishingly fast modern hardware can be.
>>> Like at least a thousand times faster than a 1970s mainframe, and yet
>>> people are still waiting on compilers!
>>
>> You've been explained before many times already by many people that
>> differences in compile time may not beat other more relevant factors.
>
> I've also explained that I work by very freqent edit-run cycles. Then
> compile-times matter. This is why many like to use scripting languages
> as those don't have a discernible build step.
>
> But I can use my system language, *or* C via my compiler, just like a
> scripting language.
>
> You will find now various projects that apply JIT-techniques to such
> languages in an effort to provide a similar experience. (I don't need
> such techniques as my AOT compilers already work near-instantly.)
Good that this works for you. I recently worked on old version of
binutils for a niche target. To make them work I needed to
resolve some probles. First problem was that somebody thought that
adding '-Werror' to distributed code is a good idea. But I used
new version of gcc which implemented new warnings and the old
code faild to compile because it triggered new warnings which
'-Werror' turned into errors. I tried tcc, and compilation
using tcc worked fine. But there were bugs in binutils.
Trying to fix/work around I got nonsense results. After wasting
some time I realized to debug info generated by tcc was wrong,
or a least incompantible with debugger (that is gdb). So
I used a wrapper around gcc which discared '-Werror' and then
compilartion worked fine and I was able to debug binutils,
locate problematic lines and implement a workaround.
In all this I had to build binutils several times so faster
build would help. But I probably wasted more time due to tcc
debug info problem than waiting for builds. Simply, if
I need to debug a program, then speed difference between
gcc and tcc is less important to me than debug info.
gcc had to be much slower than it is to make a difference.
Simply debugging without proper support takes time and
at its current speed gcc with working debug info gives
me net saving compared to faster compiler without working
debug info.
Note, if needed I can debug without debugger. Simply, to
get information which is almost immediate using debugger
usually I would need several edit-run cycles. Even with
compile time reduced to 0 the edit-run part is likely
to take more time than using debugger.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web