Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #385836 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2024-06-11 10:13 +0100 |
| Last post | 2024-06-11 18:21 +0000 |
| Articles | 20 on this page of 351 — 23 participants |
Back to article view | Back to comp.lang.c
Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 10:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 13:59 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 14:35 +0100
Mac users (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 10:04 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-11 15:16 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 15:35 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-12 00:34 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 00:50 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 18:02 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 17:15 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 07:40 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 09:01 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 10:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:20 +0200
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 13:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 12:27 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 14:35 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:13 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 15:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:46 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 00:29 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 23:22 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-13 13:53 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 14:46 +0100
Re: Baby X is bor nagain tTh <tth@none.invalid> - 2024-06-13 17:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 16:32 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 08:47 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 19:13 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 17:43 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-14 18:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-14 19:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-15 12:35 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:22 -0400
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-17 07:30 +0000
Are Javascript and Python similarly slow ? (Was: Baby X is bor nagain) Michael S <already5chosen@yahoo.com> - 2024-06-17 12:11 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-17 12:25 +0300
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 10:54 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:23 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 11:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:36 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 17:38 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:54 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 14:14 -0400
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 20:52 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 16:07 -0400
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 15:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:15 +0200
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 21:09 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 18:40 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 17:39 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:49 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 10:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:42 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 17:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:49 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 21:42 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 22:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 12:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 14:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 17:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-20 20:28 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 20:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 22:16 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 23:40 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 10:02 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 09:55 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 09:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 13:18 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 12:24 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 13:36 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:26 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 08:05 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 17:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 17:45 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 13:55 -0400
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 19:01 +0000
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:41 -0700
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:34 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:44 -0700
Re: Baby X is bor nagain vallor <vallor@cultnix.org> - 2024-06-20 22:21 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 22:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:19 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:37 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:39 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-21 00:56 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-21 22:07 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 14:57 -0700
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 20:59 -0400
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 18:42 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-21 21:10 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 12:19 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-23 10:30 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 11:04 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:33 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 03:28 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:35 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-25 05:38 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 16:33 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 07:40 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 14:25 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 09:47 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-23 19:55 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 09:34 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 01:53 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 12:59 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 23:46 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 17:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 13:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:44 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:27 -0700
sort - C, python, C++, glibc Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-19 13:17 +0300
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:53 +0200
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 18:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:39 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:26 -0400
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 11:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:43 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 16:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:21 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 20:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 21:29 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 22:06 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 08:44 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:21 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 11:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:47 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:25 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 19:21 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 22:09 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-24 00:52 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 01:25 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 00:56 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:28 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 12:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 13:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 14:01 +0100
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:16 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 16:09 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 15:00 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 17:09 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:19 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 19:15 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:25 +0000
Re: Baby X is bor nagain "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-25 20:29 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 22:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 21:34 +0000
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 22:03 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 10:19 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 12:18 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:08 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:28 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:17 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 12:52 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 20:39 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 16:28 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-26 00:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:23 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-26 15:18 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:45 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 12:04 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:21 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-26 08:31 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 13:15 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 12:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 18:10 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:51 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:02 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 18:50 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 18:10 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 20:33 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 11:36 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 15:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 15:08 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:12 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 16:59 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 16:27 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 19:51 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 18:11 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:42 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:35 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 13:15 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 12:16 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-27 15:24 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 14:13 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 14:31 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 17:28 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 21:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 22:47 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:23 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:19 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 10:26 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 15:14 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-29 08:38 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 17:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:42 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:49 +0300
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 15:43 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:43 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:23 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-30 00:36 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-03 17:12 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:49 -0700
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:46 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 20:55 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 12:18 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:54 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 19:10 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-01 00:20 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 19:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 16:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 10:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 12:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-30 11:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 12:22 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-01 13:09 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 15:14 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:20 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:00 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 16:44 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 00:58 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 01:23 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 00:47 +0000
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 01:18 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 01:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-03 09:08 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 10:36 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-07-03 09:41 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:33 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-04 09:14 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 22:58 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:24 +0200
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-02 13:16 -0500
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:46 +0000
Re: Baby X is bor nagain Phillip <nntp@fulltermprivacy.com> - 2025-01-02 16:47 -0500
Re: Baby X is bor nagain antispam@fricas.org (Waldek Hebisch) - 2025-01-02 22:22 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 13:48 +0100
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-03 12:04 -0500
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 18:12 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:18 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-03 11:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-03 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:20 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:52 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 11:05 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-29 09:15 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:11 +0200
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:51 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:17 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:57 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 13:23 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:44 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 17:50 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 00:16 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-27 23:58 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:21 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:53 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:08 -0700
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:30 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:11 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:41 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:36 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 15:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 20:37 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:42 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 16:01 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:45 +0300
tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-01 20:09 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-01 12:14 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:48 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 15:09 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 11:54 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 12:22 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 16:27 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 15:18 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 17:55 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 13:57 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:50 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:47 -0700
Re: tcc - first impression. Was: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 11:50 -0400
Re: tcc - first impression. Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-02 10:35 +0100
Re: tcc - first impression. Was: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-07-02 14:33 +0000
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 15:43 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:17 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:32 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:45 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 17:12 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 00:42 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-04 00:04 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:07 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-27 23:24 +0100
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-28 00:44 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 20:41 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:39 +0300
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 16:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 22:01 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 09:01 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 19:52 -0400
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 11:26 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 20:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:40 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:55 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 09:39 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:58 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 14:33 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 13:02 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:06 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:07 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:22 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 16:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 10:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 11:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:53 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 12:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 14:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 19:43 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:56 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-23 15:22 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 15:11 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 14:09 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:38 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:28 -0400
Topicality is not your strong suit (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 09:40 +0000
Re: Topicality is not your strong suit (Was: Baby X is bor nagain) Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 12:59 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 18:09 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 20:22 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 20:31 +0100
Re: Baby X is bor nagain kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-06-11 18:21 +0000
Page 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-26 00:28 +0300 |
| Message-ID | <20240626002842.000041f8@yahoo.com> |
| In reply to | #386519 |
On Tue, 25 Jun 2024 17:08:42 +0200 David Brown <david.brown@hesbynett.no> wrote: > > Do you think the developers of gcc don't care? That's about right. At least for C, they don't. Most likely the same applies even stronger to Fortran. For C++ they would love to not care, but then their compiler would become unusable. So they have to care, but probably very sorry about it. However bigger reason is not lack of care, but the style of their development process. It's best described as a patchwork. > Or they are just bad at writing code? I don't thinks so. Most of them are rather good. But factors mentioned above prevail. > Do you know how laughable that is? It is not > /quite/ as bad as your usual paranoia that the developers behind C, > gcc, Linux, make, and countless other things you don't understand > created them just to annoy you personally. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-26 09:17 +0200 |
| Message-ID | <v5gf9u$21ekk$1@dont-email.me> |
| In reply to | #386536 |
On 25/06/2024 23:28, Michael S wrote: > On Tue, 25 Jun 2024 17:08:42 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> Do you think the developers of gcc don't care? > > That's about right. At least for C, they don't. I don't think speed of compilation for C is a big priority for gcc developers. But that's not the same as saying they don't care. Like any other big development project, they have limited resources and priorities - when Intel, ARM, Red Hat, Google, and other companies pay people to work on gcc, they want a concentration on the issues that matter to them and their customers. Intel is not bothered about the speed of C compilation, because their customers are not bothered about it - they are a lot more interested in having the generated code running faster (especially on /their/ chips). > Most likely the same applies even stronger to Fortran. Again, people don't care about the speed of Fortran compilation. It is more than fast enough. There are only two reasons anybody uses Fortran. One is because they have a large code base in Fortran and are stuck with it. The other is because they have code that does massive numerical calculations and they can get slightly more speed from it than the same thing in C (or C++). Compile speed is almost entirely irrelevant to both groups. > For C++ they would love to not care, but then their compiler would > become unusable. So they have to care, but probably very sorry about it. > C++, especially modern template-heavy code with header-only libraries, can easily take an order of magnitude or more longer to compile than roughly equivalent C. It can easily take an order of magnitude or more longer to link. And since projects in C++ are often far bigger than those in C - since C's lack of namespaces of any sort makes it a poor language for large code bases - speed of compilation is a different world here. > However bigger reason is not lack of care, but the style of their > development process. It's best described as a patchwork. > It is, yes. It is a massive project built by vast numbers of people over three and a half decades. Sometimes there are big renovations and significant parts get re-written for big gains. But those are rare - they take a great deal of development resources, and they are a serious risk for new problems. gcc is the backbone of far too much critical software to take big risks easily. Some twenty years ago, someone also thought that gcc's code structure and development process was inflexible and limiting for a compiler, and it would be better to start with a clean, modern design with modern languages and tools, that allowed more modular development, streamlined and faster compilation, better error messages and cross-module link-time optimisations. When llvm/clang was young, in comparison to gcc it was very much faster, had much nicer error messages and supported much more efficient link-time optimisation - at the expense of significantly less efficient generated code and less static checking. Now llvm/clang is much more mature, and is comparable to gcc in generated code quality (clang wins some benchmarks, gcc wins most, but the differences are often minor). And its compile times are not much faster than gcc. It turns out that quality code generation takes time. There are basically two things to be done about C++ compilation speed. One is to move past the literal inclusion of headers as a language model. The problem with C++ compilation is not that it takes a long time to analyse and compile 2000 lines of code in a .cpp file. It is that the compiler also has to deal with a million lines of include files for that compilation. Thus we have C++ modules. Unfortunately, retrofitting a good module solution to a language that has always used literal includes, is far from easy, and it has taken longer than anyone would have wanted to get them defined and standardised in the language, and to get implementations in place. As these fall into place, however, it will be possible to move projects to being mostly module based and improve C++ build speeds in a way that you couldn't dream of by streamlining a C++ compiler. The second challenge for C++ build times on large projects is linking. Here there are new linkers being developed that have C++ in mind, rather than being mere modifications of traditional linkers that targeted assembly, C and Fortran.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2024-06-25 12:52 -0400 |
| Message-ID | <667af5ce$0$2873002$882e4bbb@reader.netnews.com> |
| In reply to | #386508 |
On 6/25/2024 7:18 AM, bart wrote: > On 25/06/2024 09:19, David Brown wrote: > >> At no point in all this does anyone care in the slightest about the >> speed of your little toys or of the cute little tcc. tcc might be >> ideal for the half-dozen people in the world who think C scripts are a >> good idea, and it had its place in a time when "live Linux" systems >> were booted from floppies, but that's about it. > > Yet, projects like mine, and like tcc, show what is possible: just how > fast should it take to turn lower level code into machine code. Can you use tcc to generate assembly from a .c source file? similar to: $ gcc -S sourcefile.c
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-25 20:39 +0100 |
| Message-ID | <v5f6db$1mm97$1@dont-email.me> |
| In reply to | #386523 |
On 25/06/2024 17:52, DFS wrote: > On 6/25/2024 7:18 AM, bart wrote: >> On 25/06/2024 09:19, David Brown wrote: >> >>> At no point in all this does anyone care in the slightest about the >>> speed of your little toys or of the cute little tcc. tcc might be >>> ideal for the half-dozen people in the world who think C scripts are >>> a good idea, and it had its place in a time when "live Linux" systems >>> were booted from floppies, but that's about it. >> >> Yet, projects like mine, and like tcc, show what is possible: just how >> fast should it take to turn lower level code into machine code. > > > Can you use tcc to generate assembly from a .c source file? > > similar to: > > $ gcc -S sourcefile.c I don't think that's an option with tcc. gcc works by generating intermediate assembly anyway, and the -S option exposes it. Generally it depends on compiler. Mine has it for example.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2024-06-25 16:28 -0400 |
| Message-ID | <667b285b$0$3620706$882e4bbb@reader.netnews.com> |
| In reply to | #386531 |
On 6/25/2024 3:39 PM, bart wrote:
> On 25/06/2024 17:52, DFS wrote:
>> On 6/25/2024 7:18 AM, bart wrote:
>>> On 25/06/2024 09:19, David Brown wrote:
>>>
>>>> At no point in all this does anyone care in the slightest about the
>>>> speed of your little toys or of the cute little tcc. tcc might be
>>>> ideal for the half-dozen people in the world who think C scripts are
>>>> a good idea, and it had its place in a time when "live Linux"
>>>> systems were booted from floppies, but that's about it.
>>>
>>> Yet, projects like mine, and like tcc, show what is possible: just
>>> how fast should it take to turn lower level code into machine code.
>>
>>
>> Can you use tcc to generate assembly from a .c source file?
>>
>> similar to:
>>
>> $ gcc -S sourcefile.c
>
>
> I don't think that's an option with tcc.
It's not listed in the tcc help anyway.
> gcc works by generating intermediate assembly anyway, and the -S option
> exposes it.
>
> Generally it depends on compiler. Mine has it for example.
Cool.
If you don't mind, what assembly code does your compiler generate for
this C code:
-------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
int N=0;
int *nums = malloc(2 * sizeof(int));
FILE* datafile = fopen(argv[1], "r");
while(fscanf(datafile, "%d", &nums[N++]) == 1){
nums = realloc(nums, (N+1) * sizeof(int));
}
fclose (datafile);
N--;
for(int i=0;i<N;i++) {
printf("%d.%d ", i+1, nums[i]);
}
free(nums);
printf("\n");
return 0;
}
----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-26 00:23 +0100 |
| Message-ID | <v5fji3$1p5ds$1@dont-email.me> |
| In reply to | #386533 |
On 25/06/2024 21:28, DFS wrote:
> On 6/25/2024 3:39 PM, bart wrote:
>> On 25/06/2024 17:52, DFS wrote:
>>> On 6/25/2024 7:18 AM, bart wrote:
>>>> On 25/06/2024 09:19, David Brown wrote:
>>>>
>>>>> At no point in all this does anyone care in the slightest about the
>>>>> speed of your little toys or of the cute little tcc. tcc might be
>>>>> ideal for the half-dozen people in the world who think C scripts
>>>>> are a good idea, and it had its place in a time when "live Linux"
>>>>> systems were booted from floppies, but that's about it.
>>>>
>>>> Yet, projects like mine, and like tcc, show what is possible: just
>>>> how fast should it take to turn lower level code into machine code.
>>>
>>>
>>> Can you use tcc to generate assembly from a .c source file?
>>>
>>> similar to:
>>>
>>> $ gcc -S sourcefile.c
>>
>>
>> I don't think that's an option with tcc.
>
> It's not listed in the tcc help anyway.
>
>
>
>> gcc works by generating intermediate assembly anyway, and the -S
>> option exposes it.
>>
>> Generally it depends on compiler. Mine has it for example.
>
> Cool.
>
> If you don't mind, what assembly code does your compiler generate for
> this C code:
I've shown the main code below. I normally use alternate registers
names, I've changed it to use Intel; it looks about right.
This is for Win64 ABI running on x64.
Although I'm not sure how helpful this will be. Most of the runtime in
your program will be spent inside library functions.
----------------------------------------
`main::
`main.argc = -8
`main.argv = -16
`R.main.N = edi
`R.main.nums = rbx
`R.main.datafile = rsi
`R.main.i.3 = r12d
`main.$env = -24
`main.$info = -152
push rdi
push rbx
push rsi
push r12
push rbp
mov rbp, rsp
sub rsp, 192
;... (some code which sets up argc/argv via __getmainargs() ...
mov edi, 0
mov rcx, 8
call `malloc*
mov rbx, rax
mov rax, [rbp+`main.argv]
lea rax, [rax+8]
mov rax, [rax]
mov rcx, rax
mov rdx, L6
call `fopen*
mov rsi, rax
jmp L7
L9:
lea eax, [rdi+1]
movsx rax, eax
shl rax, 2
mov rcx, rbx
mov rdx, rax
call `realloc*
mov rbx, rax
L7:
mov eax, edi
inc edi
movsx rax, eax
lea r10, [rbx+rax*4]
mov rcx, rsi
mov rdx, L10
mov r8, r10
call `fscanf*
cmp eax, 1
jz L9
L8:
mov rcx, rsi
call `fclose*
dec edi
mov r12d, 0
jmp L13
L14:
mov eax, r12d
movsx rax, eax
lea r10, [rbx+rax*4]
mov r10d, [r10]
lea eax, [r12+1]
mov rcx, L15
mov edx, eax
mov r8d, r10d
call `printf*
L11:
inc r12d
L13:
cmp r12d, edi
jl L14
L12:
mov rcx, rbx
call `free*
mov rcx, L16
call `printf*
;------------------------
xor ecx, ecx
call `exit*
add rsp, 192
pop rbp
pop r12
pop rsi
pop rbx
pop rdi
ret
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-25 13:13 -0700 |
| Message-ID | <874j9gu6fu.fsf@nosuchdomain.example.com> |
| In reply to | #386523 |
DFS <nospam@dfs.com> writes:
[...]
> Can you use tcc to generate assembly from a .c source file?
>
> similar to:
>
> $ gcc -S sourcefile.c
No, tcc has no such option.
I was able to get an assembly listing by running `tcc -c sourcefile.c`
followed by `objdump -d sourcefile.o`.
--
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 | 2024-06-26 09:23 +0200 |
| Message-ID | <v5gfm5$21ekk$3@dont-email.me> |
| In reply to | #386532 |
On 25/06/2024 22:13, Keith Thompson wrote: > DFS <nospam@dfs.com> writes: > [...] >> Can you use tcc to generate assembly from a .c source file? >> >> similar to: >> >> $ gcc -S sourcefile.c > > No, tcc has no such option. > > I was able to get an assembly listing by running `tcc -c sourcefile.c` > followed by `objdump -d sourcefile.o`. > <https://godbolt.org> has tcc on its list of C compilers, and it shows the generated assembly. I don't know how it does this - perhaps using this same method. If people are interested in looking at the code generated by tcc (or vast numbers of other compilers, versions and targets), then godbolt is usually the easiest way to get it. And if anyone wants to know how they get the nice assembly out of the compilers, the source code for godbolt is also freely available.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-26 15:18 -0700 |
| Message-ID | <87zfr7s5yn.fsf@nosuchdomain.example.com> |
| In reply to | #386547 |
David Brown <david.brown@hesbynett.no> writes:
> On 25/06/2024 22:13, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
>> [...]
>>> Can you use tcc to generate assembly from a .c source file?
>>>
>>> similar to:
>>>
>>> $ gcc -S sourcefile.c
>> No, tcc has no such option.
>> I was able to get an assembly listing by running `tcc -c
>> sourcefile.c`
>> followed by `objdump -d sourcefile.o`.
>
> <https://godbolt.org> has tcc on its list of C compilers, and it shows
> the generated assembly. I don't know how it does this - perhaps using
> this same method. If people are interested in looking at the code
> generated by tcc (or vast numbers of other compilers, versions and
> targets), then godbolt is usually the easiest way to get it.
>
> And if anyone wants to know how they get the nice assembly out of the
> compilers, the source code for godbolt is also freely available.
https://godbolt.org/z/3b18qno37
The assembly listing doesn't look like objdump output, and the output
window on the lower right looks like tcc itself generated
"/app/output.s". A quick look at the source code was unhelpful.
I've emailed Matt Goldbolt and asked him about this.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-27 15:45 -0700 |
| Message-ID | <87pls2xavs.fsf@nosuchdomain.example.com> |
| In reply to | #386578 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>> On 25/06/2024 22:13, Keith Thompson wrote:
>>> DFS <nospam@dfs.com> writes:
>>> [...]
>>>> Can you use tcc to generate assembly from a .c source file?
>>>>
>>>> similar to:
>>>>
>>>> $ gcc -S sourcefile.c
>>> No, tcc has no such option.
>>> I was able to get an assembly listing by running `tcc -c
>>> sourcefile.c`
>>> followed by `objdump -d sourcefile.o`.
>>
>> <https://godbolt.org> has tcc on its list of C compilers, and it shows
>> the generated assembly. I don't know how it does this - perhaps using
>> this same method. If people are interested in looking at the code
>> generated by tcc (or vast numbers of other compilers, versions and
>> targets), then godbolt is usually the easiest way to get it.
>>
>> And if anyone wants to know how they get the nice assembly out of the
>> compilers, the source code for godbolt is also freely available.
>
> https://godbolt.org/z/3b18qno37
>
> The assembly listing doesn't look like objdump output, and the output
> window on the lower right looks like tcc itself generated
> "/app/output.s". A quick look at the source code was unhelpful.
>
> I've emailed Matt Goldbolt and asked him about this.
I got a reply from Matt Godbolt. The assembly listing is objdump
output. The web client filters it and displays it as if it were regular
output.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-25 12:04 -0700 |
| Message-ID | <878qysu9mt.fsf@nosuchdomain.example.com> |
| In reply to | #386508 |
bart <bc@freeuk.com> writes:
[...]
> You think it is all totally pointless? Then fuck you.
[...]
Let's keep things civil.
--
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 | 2024-06-26 09:21 +0200 |
| Message-ID | <v5gfha$21ekk$2@dont-email.me> |
| In reply to | #386530 |
On 25/06/2024 21:04, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> You think it is all totally pointless? Then fuck you. > [...] > > Let's keep things civil. > He felt provoked. So it is I who need to think more, be more respectful and be less provocative in my wording. My apologies to Bart, and to the group for frustrating him that much.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-06-26 08:31 +0000 |
| Message-ID | <20240626012935.914@kylheku.com> |
| In reply to | #386546 |
On 2024-06-26, David Brown <david.brown@hesbynett.no> wrote: > On 25/06/2024 21:04, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >> [...] >>> You think it is all totally pointless? Then fuck you. >> [...] >> >> Let's keep things civil. >> > > He felt provoked. So it is I who need to think more, be more respectful > and be less provocative in my wording. My apologies to Bart, and to the > group for frustrating him that much. To balnce this view, we have to acknowledge that Bart carries a "background level of provocation" as a reaction to the state of things in the computing world, and is actively looking to be further provoked in the C newsgroup. -- 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-25 13:15 +0300 |
| Message-ID | <20240625131520.000007b1@yahoo.com> |
| In reply to | #386461 |
On Mon, 24 Jun 2024 17:09:25 +0200 David Brown <david.brown@hesbynett.no> wrote: > > (I'm not suggesting Michael change for this project - for serious > embedded work, repeatable builds and consistency of toolchains is > generally far more important than build times. But I presume he'll > use newer and better tools for new projects.) > It is not that simple. Tools are supplied by Altera (more recently called Intel, but gossips are that will be called Altera again really soon now). Of course, I can build gcc compiler and binutils to native exe myself, but then it wouldn't be supported. And I'd still will be forced to run these native tools from cygwin shell because of compatibility with other vendor-supplied tools. Altera/Intel-supplied Nios2 SDK on Windows up to 2018 was based on cygwin. 2019-2022 it is based on WSL. 2023 and later it is "deprecated" in theory and removed in practice, both on Windows and on Linux, in favor of "Nios-V" which is a name for Intel-supplied RISC-V core. I have a weak hope that if Altera become more independent then the last step will be reversed, but by now it's what we have. As you can see, at no point they supported msys/msys2-based tools any other "native" Windows form of tools. So practical choice Intel/Altera give is between cygwin and WSL. WSL is not usable in our working environment. That leaves cygwin. And it's not that bad. Yes, cygwin shell is inconvenient, but not unusable. Yes, cygwin is slower. But project that I presented is among our biggest and still a full rebuild takes only ~15 seconds on rather old hardware. During development full rebuilds are very rare. More typical build on more typical project is 2-3 seconds. For me, it's slightly inconvenient, but tolerable. For few other co-workers it's not even inconvenient. I know few people for whom it would be quite unnerving, but luckily non of them is currently doing Nios2 sw development. So, your presumption is wrong. I am going to start new project that among other things involves Nios2 software and I planning to start it with cygwin-based build tools. A little newer version of tools (gcc 5.2 instead of 4.1, newer binutils 2.25 etc) but otherwise almost identical to 11 y.o. SDK that was used to gather numbers in post above.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-25 12:56 +0200 |
| Message-ID | <v5e7p0$1gutf$1@dont-email.me> |
| In reply to | #386505 |
On 25/06/2024 12:15, Michael S wrote: > On Mon, 24 Jun 2024 17:09:25 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> (I'm not suggesting Michael change for this project - for serious >> embedded work, repeatable builds and consistency of toolchains is >> generally far more important than build times. But I presume he'll >> use newer and better tools for new projects.) >> > > It is not that simple. > Tools are supplied by Altera (more recently called Intel, but gossips > are that will be called Altera again really soon now). > Of course, I can build gcc compiler and binutils to native exe myself, > but then it wouldn't be supported. And I'd still will be forced to run > these native tools from cygwin shell because of compatibility with > other vendor-supplied tools. If that's the vendor-supplied tools, then that's what you use, of course. I assumed that this was an old project, since gcc 4.1 is a very old version and few people use Cygwin now, and it's normal in this branch to stick to the tools you start with in a project. > Altera/Intel-supplied Nios2 SDK on Windows up to 2018 was based on > cygwin. 2019-2022 it is based on WSL. 2023 and later it is "deprecated" > in theory and removed in practice, both on Windows and on Linux, in > favor of "Nios-V" which is a name for Intel-supplied RISC-V core. > I have a weak hope that if Altera become more independent then the last > step will be reversed, but by now it's what we have. > As you can see, at no point they supported msys/msys2-based tools any > other "native" Windows form of tools. > So practical choice Intel/Altera give is between cygwin and WSL. WSL is > not usable in our working environment. That leaves cygwin. > I have customers using WSL for gcc-based builds, though the gcc toolchains in question are mingw64 hosted. I have no experience with it myself - I use Linux for most development and my Windows system is Windows 7 without WSL. I used the Nios 2 briefly when it was new, but that was many years ago. I can understand that Altera/Intel are a bit slow with updating the toolchains (and I can understand why they are pushing towards a RISC-V core). But the Nios 2 is a mainstream gcc port - there is no excuse for them being stuck on such an old version of gcc, and such an awkward emulation layer. > And it's not that bad. > Yes, cygwin shell is inconvenient, but not unusable. Yes, cygwin is > slower. But project that I presented is among our biggest and still a > full rebuild takes only ~15 seconds on rather old hardware. During > development full rebuilds are very rare. More typical build on more > typical project is 2-3 seconds. For me, it's slightly inconvenient, but > tolerable. For few other co-workers it's not even inconvenient. I know > few people for whom it would be quite unnerving, but luckily non of > them is currently doing Nios2 sw development. > Fair enough - after all, fast enough is fast enough. You have no plans of switching to Linux? I think these days that's the most common OS for FPGA development. (Of course I am not recommending switching to Linux just to get faster builds :-) ) > So, your presumption is wrong. I am going to start new project that > among other things involves Nios2 software and I planning to start it > with cygwin-based build tools. A little newer version of tools (gcc 5.2 > instead of 4.1, newer binutils 2.25 etc) but otherwise almost identical > to 11 y.o. SDK that was used to gather numbers in post above. > OK.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-24 18:10 +0300 |
| Message-ID | <20240624181006.00003b94@yahoo.com> |
| In reply to | #386457 |
On Mon, 24 Jun 2024 15:00:26 +0100 bart <bc@freeuk.com> wrote: > On 24/06/2024 14:09, Michael S wrote: > > On Fri, 21 Jun 2024 22:47:46 +0100 > > bart <bc@freeuk.com> wrote: > > > >> On 21/06/2024 14:34, David Brown wrote: > >>> On 21/06/2024 12:42, bart wrote: > >>>> On 21/06/2024 10:46, David Brown wrote: > >>>>> > >>>>> > >>>>> I understand your viewpoint and motivation. But my own > >>>>> experience is mostly different. > >>>>> > >>>>> First, to get it out of the way, there's the speed of > >>>>> compilation. While heavy optimisation (-O3) can take noticeably > >>>>> longer, I never see -O0 as being in any noticeable way faster > >>>>> for compilation than -O1 or even -O2. > >>>> > >>>> Absolute time or relative? > >>> > >>> Both. > >>> > >>>> For me, optimised options with gcc always take longer: > >>> > >>> Of course. But I said it was not noticeable - it does not make > >>> enough difference in speed for it to be worth choosing. > >>> > >>>> > >>>> C:\c>tm gcc bignum.c -shared -s -obignum.dll # from > >>>> cold TM: 3.85 > >>> > >>> Cold build times are irrelevant to development - when you are > >>> working on a project, all the source files and all your compiler > >>> files are in the PC's cache. > >>> > >>> > >>>> > >>>> C:\c>tm gcc bignum.c -shared -s -obignum.dll > >>>> TM: 0.31 > >>>> > >>>> C:\c>tm gcc bignum.c -shared -s -obignum.dll -O2 > >>>> TM: 0.83 > >>>> > >>>> C:\c>tm gcc bignum.c -shared -s -obignum.dll -O3 > >>>> TM: 0.93 > >>>> > >>>> C:\c>dir bignum.dll > >>>> 21/06/2024 11:14 35,840 bignum.dll > >>> > >>> Any build time under a second is as good as instant. > >>> > >>> I tested on a real project, not a single file. It has 158 C files > >>> and about 220 header files. And I ran it on my old PC, without > >>> any "tricks" that you dislike so much, doing full clean > >>> re-builds. The files are actually all compiled twice, building > >>> two variants of the binary. > >>> > >>> With -O2, it took 34.3 seconds to build. With -O1, it took 33.4 > >>> seconds. With -O0, it took 30.8 seconds. > >>> > >>> So that is a 15% difference for full builds. In practice, of > >>> course, full rebuilds are rarely needed, and most builds after > >>> changes to the source are within a second or so. > >> > >> Then there's something very peculiar about your codebase. > >> > > > > > > To me it looks more likely that your codebase is very unusual rather > > than David's > > > > In order to get meaningful measurements I took embedded project that > > is significantly bigger than average by my standards. Here are > > times of full parallel rebuild (make -j5) on relatively old > > computer (4-core Xeon E3-1271 v3). > > > > Option time(s) -g time text size > > -O0 13.1 13.3 631648 > > -Os 13.6 14.1 424016 > > -O1 13.5 13.7 455728 > > -O2 14.0 14.1 450056 > > -O3 14.0 14.6 525380 > > > > The difference in time between different -O settings in my > > measurements is even smaller than reported by David Brown. That can > > be attributed to older compiler (gcc 4.1.2). Another difference is > > that this compiler works under cygwin, which is significantly > > slower both than native Linux and than native Windows. That causes > > relatively higher make overhead and longer link. > > I don't know why Cygwin would make much difference; the native code > is still running on the same processor. > I don't know specific reasons. Bird's eye perspective is that cygwin tries to emulate Posix semantics on platform that is not Posix and achieves that by using few low-granularity semaphores in user space, which seriously limits parallelism. Besides, there are problems with emulation of Posix I/O semantics that cause cygwin file I/O to be 2-3 times slower that native Windows I/O. The later applies mostly to relatively small files, but, then again, software build mostly accesses small files. As a matter of fact, a parallel speed up I see on this project on this quad-core machine is barely 2x. I expect 3x or a little more for the same project with native Windows tools. > However, is there any way of isolating the compilation time (turning > .c files into either or .o files) from 'make' the linker? Failing > that, can you compile just one module in isolation (.c to .o) with > -O0 and -O2, or is that not possible? > Of course, there is a way. But it's more work and gives an answer I am not interested to know. Here are fully agree with what David said few posts below. > Those throughputs don't look that impressive for a parallel build on > what sounds like a high-spec machine. > Yes, not that impressive. However I wouldn't call the machine high-spec. More precisely, when originally bought almost decade ago it was high-spec (but not top-spec) machine for FPGA development. FPGA development tools even today are not so good at parallelization of their jobs. 10 years ago parallelization gain above 2 cores was non-existing. Also, data access patterns of this tools tend to have poor locality of reference. It means that big L3 cache has limited usefulness. On the other hand, low-latency main memory is very useful. This specific machine is bought with this constraints in mind - high [for 2014] single-thread performance, relatively small 8MB L3 cache, small [for multi-user server] 32 GB low-latency main memory built of unbuffered DIMMs rather than of more typical for server registered DIMMs. People that care about parallel software builds buy quit different sort of servers - dual-socket, lots of cores, big last level cache, big main memory with high throughput and high latency. Back in the second half of 2014 those of them that had bigger budgets bought Xeon E5-2697 v2; those with smaller budgets preferred Xeon E5-2697 v2. Those with good contacts were getting Xeon E5 v3 that was already lounched but not available for everyone. > Your processor has a CPU-mark double that of mine, which has only two > cores, and is using one. > > Building a 34-module project with .text size of 300KB, with either > gcc 10 or 14, using -O0, takes about 8 seconds, or 37KB/second. > But my project has much more than 34 modules. 164 modules compiled during build + several dozens in libraries. > Your figures show about 50KB/second. text KB/second is hardly a good measure, esp. considering that we are talking about different architectures. Mine is Altera Nios2 - 32-bit RISC processor very similar to MIPS. The code density for this architecture is significantly lower than on ARMv7 or x386 and even somewhat lower than x86-64 and ARM64. The exact ratio depends on the project, but 15-20% would be typical. Also, part of text are libraries that we not compiled during this build. But I would think that your .text size also includes libraries. > You say you use gcc 4, but an > older gcc is more likely to be faster in compilation speed than a > newer one. > Yes, but not dramatically so. And your ratios are extra-dramatically different from mines, David's and Scott's. > It does sound like something outside of gcc itself. > > For the same project, on the same slow machine, Tiny C's throughput > is 1.3MB/second. While my non-C compiler, on other projects, is > 5-10MB/second, still only looking at .text segments. That is 100 > times faster than your timings, for generating code that is as good > as gcc's -O0. > > So IT IS NOT WINDOWS ITSELF THAT IS SLOW. > > > > If I had were "native" tools then all times will be likely shorter > > by few seconds and the difference between -O0 and -O3 will be close > > to 10%. > > So two people now saying that all the many dozens of extras passes > and extra analysis that gcc -O2/O3 has to do, compared with the basic > front-end work that every toy compiler needs to do and does it > quickly, only slows it down by 10%. > > I really don't believe it. And you should understand that it doesn't > add up. > I am not lying. I am pretty sure that DavidB also tells truth. I recommend to try to compile your C compiler with gcc. Somehow I have a feeling that -O0 to -O2 ratio you'd see will be much closer to 1.15x than to 4x.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-24 17:51 +0100 |
| Message-ID | <v5c86d$11ac7$1@dont-email.me> |
| In reply to | #386462 |
On 24/06/2024 16:10, Michael S wrote: > On Mon, 24 Jun 2024 15:00:26 +0100 > bart <bc@freeuk.com> wrote: > >> Your processor has a CPU-mark double that of mine, which has only two >> cores, and is using one. >> >> Building a 34-module project with .text size of 300KB, with either >> gcc 10 or 14, using -O0, takes about 8 seconds, or 37KB/second. >> > > But my project has much more than 34 modules. 164 modules compiled > during build + several dozens in libraries. Does that matter? My example is a smaller project, but I'm comparing the rate of compilation not total time. If you want a bigger example, yesterday I posted one involving 140 .c files, total EXE size is 5MB (don't know .text as this is ELF format). -O2 took just over twice as long as -O0. But I guess every single example I come up with is 'exceptional'. Maybe what's exceptional is that I measuring the runtime of the compiler, and not all sorts of other junk. You might claim that that other junk is necessary for the the build; I'd dispute that. >> Your figures show about 50KB/second. > > text KB/second is hardly a good measure, esp. considering that we are > talking about different architectures. Mine is Altera Nios2 - 32-bit > RISC processor very similar to MIPS. The code density for this > architecture is significantly lower than on ARMv7 or x386 and even > somewhat lower than x86-64 and ARM64. The exact ratio depends on the > project, but 15-20% would be typical. > Also, part of text are libraries that we not compiled during this build. > But I would think that your .text size also includes libraries. So, what is the total size of the code that is produced by the compilation? What is the data size? >> I really don't believe it. And you should understand that it doesn't >> add up. >> > > I am not lying. I'm not saying that. I'm disputing that -O2 adds only 10% compared to -O0 when running only gcc. I am pretty sure that DavidB also tells truth. > I recommend to try to compile your C compiler with gcc. My C compiler is not written in C. I can transpile to C, but then it would be a single large C file, which puts pressure on the optimiser: C:\cx>mc -c cc # transpile to C Compiling cc.m to cc.c C:\cx>tm gcc cc.c # -O0 build TM: 1.92 C:\cx>tm gcc cc.c -O2 TM: 9.22 It takes 380% longer compared with -O0. However the advantage is that I now have a whole-program optimised application. But this is not something I need to do routinely (maybe on production versions or running benchmarks). Most of the time I don't need the optimised code (which is only about 40% faster) and can build like this: C:\cx>tm mm cc Compiling cc.m to cc.exe TM: 0.06 (If mm.exe is similarly boosted by via gcc, otherwise it takes 0.08s.) So optimisation for this product take 150 times, or 15,000%, longer. DB was however saying that he normally has optimisation turned on. Well I'm not surprised if turning it off makes only 11% difference! But he is not interested in super-fast builds such as those I work on. Note that that 0.06 figure is for rebuilding my C compiler from scratch (200KB .text size, 300KB EXE size.), and 1/3 of it is Windows process overheads. Accurately measuring build-times when timings are near zero is difficult.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-24 17:02 +0000 |
| Message-ID | <JEheO.108086$ED9b.74955@fx11.iad> |
| In reply to | #386467 |
bart <bc@freeuk.com> writes: >On 24/06/2024 16:10, Michael S wrote: >> But my project has much more than 34 modules. 164 modules compiled >> during build + several dozens in libraries. > >Does that matter? My example is a smaller project, but I'm comparing the >rate of compilation not total time. > >If you want a bigger example, yesterday I posted one involving 140 .c >files, total EXE size is 5MB (don't know .text as this is ELF format). Why do you believe that the size of the executable is interesting? Why do you think you think 5MB is unusual if you don't know anything about ELF? The 'size' command will tell you the text size, although the text size is a meaningless parameter in modern virtual memory systems which load pages on demand. $ file /tmp/a /tmp/a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=12944219f87c74b03ec19d1d693771e12416dd81, not stripped $ size /tmp/a text data bss dec hex filename 1257 548 4 1809 711 /tmp/a $ ls -l /tmp/a -rwxrwxr-x. 1 scott scott 8501 Jun 20 07:45 /tmp/a When the average disk holds 1 TB, 5MB is not even in the noise. > >-O2 took just over twice as long as -O0. > >But I guess every single example I come up with is 'exceptional'. By definition. > Maybe >what's exceptional is that I measuring the runtime of the compiler, and >not all sorts of other junk. You seem to be measuring the wall-clock time which is influenced by factors other than the size of the source file including other processes running during your compile.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-24 18:50 +0100 |
| Message-ID | <v5cblg$11q0j$1@dont-email.me> |
| In reply to | #386468 |
On 24/06/2024 18:02, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 24/06/2024 16:10, Michael S wrote: > >>> But my project has much more than 34 modules. 164 modules compiled >>> during build + several dozens in libraries. >> >> Does that matter? My example is a smaller project, but I'm comparing the >> rate of compilation not total time. >> >> If you want a bigger example, yesterday I posted one involving 140 .c >> files, total EXE size is 5MB (don't know .text as this is ELF format). > > Why do you believe that the size of the executable is interesting? Well, what metric IS interesting? You seem to not care whether an executable is 10KB, 10MB, or 10GB. You really don't think there's correspondence with build-time? > > Why do you think you think 5MB is unusual MS claimed that my project was smaller than his. So I found a bigger one. > if you don't know anything > about ELF? What's that going to do with the price of fish? ELF is another executable format, but my tools can't look inside it. > > The 'size' command will tell you the text size, although the text size > is a meaningless parameter in modern virtual memory systems which > load pages on demand. The .text was also something introduced by MS. > $ file /tmp/a > /tmp/a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=12944219f87c74b03ec19d1d693771e12416dd81, not stripped > $ size /tmp/a > text data bss dec hex filename > 1257 548 4 1809 711 /tmp/a > $ ls -l /tmp/a > -rwxrwxr-x. 1 scott scott 8501 Jun 20 07:45 /tmp/a > > > When the average disk holds 1 TB, 5MB is not even in the noise. And what does /that/ have to do with anything? One metric I find useful with my compiler work is how many MB per second they can produce from direct compilation. And 5MB per second is faster than 50KB per second. It took gcc 17-38 seconds to build that 5MB product in WSL; that's pretty slow. If you want to ignore that simple fact then <shrug>. The common themes in this newsgroup is first to defend the design of the C language, and second to defend the behaviour and performance of gcc. Maybe more people should take an interest. It would be funny if gcc suddenly doubled in speed overnight because of some stupid oversight that nobody had bothered to investigate. Because lines/second or MB/second or anything else is 'uninteresting'. BTW how slow does a tool have to get before YOU start asking questions? >> >> -O2 took just over twice as long as -O0. >> >> But I guess every single example I come up with is 'exceptional'. > > By definition. > >> Maybe >> what's exceptional is that I measuring the runtime of the compiler, and >> not all sorts of other junk. > > You seem to be measuring the wall-clock time which is influenced by > factors other than the size of the source file including other processes > running during your compile. > Yes, it is during that same time period that people waiting for it to complete have to sit twiddling their thumbs.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-24 18:10 +0000 |
| Message-ID | <gEieO.108089$ED9b.25598@fx11.iad> |
| In reply to | #386474 |
bart <bc@freeuk.com> writes: >On 24/06/2024 18:02, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 24/06/2024 16:10, Michael S wrote: >> >>>> But my project has much more than 34 modules. 164 modules compiled >>>> during build + several dozens in libraries. >>> >>> Does that matter? My example is a smaller project, but I'm comparing the >>> rate of compilation not total time. >>> >>> If you want a bigger example, yesterday I posted one involving 140 .c >>> files, total EXE size is 5MB (don't know .text as this is ELF format). >> >> Why do you believe that the size of the executable is interesting? > >Well, what metric IS interesting? > >You seem to not care whether an executable is 10KB, 10MB, or 10GB. You >really don't think there's correspondence with build-time? No. The ELF file contains a lot of stuff that never gets loaded into memory (symbol tables, DWARF section data, etc); writing to the object files by the compiler is an insignificant component of the overall compile time. Build time is not related in any way to the size of the ELF. Disk space is cheap and plentiful. > >The .text was also something introduced by MS. I don't understand this comment. .text predates any MS compiler by more than a decade.
[toc] | [prev] | [next] | [standalone]
Page 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web