Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167206 > unrolled thread
| Started by | antispam@math.uni.wroc.pl |
|---|---|
| First post | 2022-08-25 02:33 +0000 |
| Last post | 2022-08-25 20:30 +0000 |
| Articles | 20 on this page of 236 — 17 participants |
Back to article view | Back to comp.lang.c
Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 02:33 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 03:00 +0000
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-26 00:22 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-26 16:48 +0000
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 03:01 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 14:29 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:10 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 16:23 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-25 20:53 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 06:56 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-26 17:29 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 13:44 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 16:01 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 10:27 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-28 03:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 15:05 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:00 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 15:16 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 09:38 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-30 04:03 -0700
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:20 +0300
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 09:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:19 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:11 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 17:20 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:31 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-28 21:29 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 02:58 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 19:51 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 10:54 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-12 05:13 -0700
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 13:55 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 15:06 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 15:22 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 17:04 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:39 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:40 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:52 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 17:24 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:55 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:51 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 14:57 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 00:46 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 16:13 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 08:47 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:13 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:30 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:36 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 00:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 10:44 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 04:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 05:48 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:31 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:15 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 16:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:43 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 18:37 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 19:30 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 18:47 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:37 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 19:47 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 09:45 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 11:55 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 05:23 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 14:20 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:20 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 00:25 +0000
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:46 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:11 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 12:54 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:52 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 21:08 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:46 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 01:25 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 11:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 12:04 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 16:06 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 23:24 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 11:39 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 18:57 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-02 17:37 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 23:51 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 01:23 +0000
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 20:42 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 14:34 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 17:39 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 12:00 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 14:45 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 17:40 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 17:30 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-04 15:02 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-04 22:45 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 01:02 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 08:22 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 12:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 15:15 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 22:54 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 22:49 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:05 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:41 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 09:39 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 10:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 15:29 +0200
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-06 17:05 +0300
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 15:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 17:19 +0200
Re: Are there any conformant C compilers? tTh <tth@none.invalid> - 2022-09-06 18:19 +0200
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-09-08 06:18 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 18:10 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-07 20:31 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-07 19:41 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 22:05 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-08 10:07 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:42 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 23:11 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:03 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:02 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-05 12:27 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:40 +0000
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-05 14:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 20:24 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 22:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 00:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 12:35 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 14:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 15:20 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 15:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 18:00 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-04 19:26 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 16:24 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 18:23 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 06:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:06 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 12:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:19 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 16:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:45 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 10:04 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 04:59 -0700
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-08-29 07:32 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 16:47 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 17:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 13:15 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 14:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 15:54 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:17 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 18:34 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 11:25 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:14 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:28 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 15:02 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 17:06 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 15:29 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:48 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 19:58 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:31 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 13:01 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 15:26 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 15:42 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:00 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 04:35 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-01 15:10 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 00:09 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 09:30 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 13:24 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 05:56 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 15:14 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 16:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 17:52 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 10:01 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 12:18 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:45 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:08 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 21:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 23:29 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 16:25 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:23 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 13:07 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 15:06 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:22 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 12:01 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:40 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-12 12:32 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-12 09:33 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:34 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 16:41 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:41 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 11:06 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 01:03 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 06:52 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 00:14 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 17:29 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-19 02:33 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:07 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:03 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:47 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 16:01 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 19:22 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 10:50 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 00:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 21:35 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 07:58 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:49 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:02 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 18:36 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:25 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 05:31 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:08 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:40 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:50 -0700
Re: Are there any conformant C compilers? Opus <ifonly@youknew.org> - 2022-08-27 20:04 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 17:03 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:50 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 12:04 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 12:25 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:23 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:58 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 07:51 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 11:50 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 19:45 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 22:03 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-27 08:14 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-27 11:23 -0700
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-25 12:41 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 20:30 +0000
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-05 15:15 +0100 |
| Message-ID | <tf5097$1fsi$1@gioia.aioe.org> |
| In reply to | #167489 |
On 05/09/2022 14:52, David Brown wrote: > On 05/09/2022 13:28, Bart wrote: >> On 05/09/2022 07:22, David Brown wrote: >>> On 05/09/2022 02:02, Bart wrote: >>>> >>>> I tried such a simple register allocator a couple of years ago, >>>> which just kept some locals in registers when there were spare >>>> registers. >>>> >>>> When applied to typical benchmarks, it worked pretty well. >>>> >>>> On real applications, it made a lot less difference, especially when >>>> I switched machines (from older Intel to newer AMD), then often it >>>> made no measurable difference. >>>> >>>> So I'm looking at not bothering with optimisation at all. This is >>>> because the difference between gcc-O3 (ver. 10.x), and my >>>> unoptimised code is not that much for my programs anyway. >>>> >>>> Typically mine will be half the speed of gcc -O3 (gcc code takes 50% >>>> less runtime). Here gcc takes 33% less runtime than mine: >>>> >>> >>> At the higher end, people pay several times as much for chips that >>> are less than 33% faster. Of course speed does not always matter, >>> but sometimes it does. >> >> Actually 33% less runtime means 50% faster. >> >> But remember that scripting languages are also tremendously popular, >> which can be 1-2 /magnitudes/ slower than optimised C code. > > As I said, speed does not always matter. > >> >> So even a C compiler such as Tiny C can be significantly faster than >> such languages for implementing the same programs. > > No one (well, no one who knows what they are doing) uses small C > compilers when they want high speed results. That does not mean that > everyone who uses or needs C is concerned about getting the fastest > results. But those who /do/ want the fastest results, use one of the > mainstream optimising compilers. My point here was that even the most naive native code compiler can easily outperform dynamically typed and interpreted scripting languages, when it comes to runtime speed. A huge amount of effort (eg. for JS) has been invested in trying to make dynamic languages fast, yet the lowly tcc.exe can manage it effortlessly and at little cost. Well, the cost is having to use C. I can see a small, fast C compiler being bundled into suitably designed scripting languages, or some hybrid design, since it can still give a significant speedup. You can't do that with a big compiler as people will notice the start-up delay on running any script (that and a 500MB sprawling installation). >> >> (In fact, Tiny C compiling itself still results in a compiler that >> runs rings around most others. I thought it was due to its using gcc >> -O3, but that's only part of it. Here: >> >> https://github.com/sal55/langs/blob/master/Compilertest3.md >> >> tcc variations occupy all four entries at the end of the first table, >> the fast end.) > > You seem to be having trouble understanding the information on that > page. It shows that tcc /compiles/ quickly - not that it generates > efficient. This point was that tcc compiles things quickly even when it's used to build itself. I thought it was cheating a little since much of its speed is due to gcc-O3; that is true, but it's still fast without that! code. I know you are fanatically obsessed with the speed of > compilers, so maybe tcc is the perfect compiler for /you/. That's fine > - I'm glad you are happy. Most serious C programmers look for other > features and trade-offs in the tools. If you have an existing, working application supplied as C source code, then to run it, it just needs translating tyo binary. Here you don't need long, deep analyses of what might be wrong with it. In fact, tcc is small enough to bundle /with/ the source code. Then applications can be run from source without any existing C installation.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-05 22:54 +0200 |
| Message-ID | <tf5nmp$3m3d4$1@dont-email.me> |
| In reply to | #167490 |
On 05/09/2022 16:15, Bart wrote: > On 05/09/2022 14:52, David Brown wrote: >> On 05/09/2022 13:28, Bart wrote: >>> On 05/09/2022 07:22, David Brown wrote: >>>> On 05/09/2022 02:02, Bart wrote: >>>>> >>>>> I tried such a simple register allocator a couple of years ago, >>>>> which just kept some locals in registers when there were spare >>>>> registers. >>>>> >>>>> When applied to typical benchmarks, it worked pretty well. >>>>> >>>>> On real applications, it made a lot less difference, especially >>>>> when I switched machines (from older Intel to newer AMD), then >>>>> often it made no measurable difference. >>>>> >>>>> So I'm looking at not bothering with optimisation at all. This is >>>>> because the difference between gcc-O3 (ver. 10.x), and my >>>>> unoptimised code is not that much for my programs anyway. >>>>> >>>>> Typically mine will be half the speed of gcc -O3 (gcc code takes >>>>> 50% less runtime). Here gcc takes 33% less runtime than mine: >>>>> >>>> >>>> At the higher end, people pay several times as much for chips that >>>> are less than 33% faster. Of course speed does not always matter, >>>> but sometimes it does. >>> >>> Actually 33% less runtime means 50% faster. >>> >>> But remember that scripting languages are also tremendously popular, >>> which can be 1-2 /magnitudes/ slower than optimised C code. >> >> As I said, speed does not always matter. >> >>> >>> So even a C compiler such as Tiny C can be significantly faster than >>> such languages for implementing the same programs. >> >> No one (well, no one who knows what they are doing) uses small C >> compilers when they want high speed results. That does not mean that >> everyone who uses or needs C is concerned about getting the fastest >> results. But those who /do/ want the fastest results, use one of the >> mainstream optimising compilers. > > My point here was that even the most naive native code compiler can > easily outperform dynamically typed and interpreted scripting languages, > when it comes to runtime speed. > > A huge amount of effort (eg. for JS) has been invested in trying to make > dynamic languages fast, yet the lowly tcc.exe can manage it effortlessly > and at little cost. Well, the cost is having to use C. > > I can see a small, fast C compiler being bundled into suitably designed > scripting languages, or some hybrid design, since it can still give a > significant speedup. You can't do that with a big compiler as people > will notice the start-up delay on running any script (that and a 500MB > sprawling installation). > No one cares about 500 MB installations, rounding to the nearest tenth of a percent of users. llvm was designed from the outset to work as a library for JIT compilation, and gcc is also now usable as a library. 500 MB is, what, about a minute of download time on an old slow connection? A thousandth of the space on a cheap disk? Of course many JIT systems will be smaller than that, since they are specially written for a single particular target language and target processor. But some will use the ready-written, well-tested and easily available llvm libraries. I'd be surprised if anyone bothered with tcc. >>> >>> (In fact, Tiny C compiling itself still results in a compiler that >>> runs rings around most others. I thought it was due to its using gcc >>> -O3, but that's only part of it. Here: >>> >>> https://github.com/sal55/langs/blob/master/Compilertest3.md >>> >>> tcc variations occupy all four entries at the end of the first table, >>> the fast end.) >> >> You seem to be having trouble understanding the information on that >> page. It shows that tcc /compiles/ quickly - not that it generates >> efficient. > > This point was that tcc compiles things quickly even when it's used to > build itself. I thought it was cheating a little since much of its speed > is due to gcc-O3; that is true, but it's still fast without that! That was not the point you claimed to make - nor is it a relevant point. > > code. I know you are fanatically obsessed with the speed of >> compilers, so maybe tcc is the perfect compiler for /you/. That's >> fine - I'm glad you are happy. Most serious C programmers look for >> other features and trade-offs in the tools. > > If you have an existing, working application supplied as C source code, > then to run it, it just needs translating tyo binary. Here you don't > need long, deep analyses of what might be wrong with it. > > In fact, tcc is small enough to bundle /with/ the source code. Then > applications can be run from source without any existing C installation. No windows user wants source code or to have to compile it, whether tcc is included or not (unless they are a C programmer, of course, in which case they will have a real compiler). No *nix user has a system that does not have a top-quality compiler. The people who see tcc as a directly useful compiler, rather than an interesting teaching tool, consist of the folks who think it is fun to get a "complete" *nix system on a 1.44" floppy, and you. Every attempt you make to suggest it is a serious and useful tool looks sillier than the last attempt you made, and detracts from the positive achievement of the compiler. It is an impressive piece of work, and it has its place as an example compiler for learning or for research (no sane person would try to learn about compiler design by looking at the gcc source code). You belittle it by desperately claiming it to be something it is not.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-05 22:49 +0100 |
| Message-ID | <tf5qtm$fus$1@gioia.aioe.org> |
| In reply to | #167495 |
On 05/09/2022 21:54, David Brown wrote:
> On 05/09/2022 16:15, Bart wrote:
>> On 05/09/2022 14:52, David Brown wrote:
>>> On 05/09/2022 13:28, Bart wrote:
>>>> On 05/09/2022 07:22, David Brown wrote:
>>>>> On 05/09/2022 02:02, Bart wrote:
>>>>>>
>>>>>> I tried such a simple register allocator a couple of years ago,
>>>>>> which just kept some locals in registers when there were spare
>>>>>> registers.
>>>>>>
>>>>>> When applied to typical benchmarks, it worked pretty well.
>>>>>>
>>>>>> On real applications, it made a lot less difference, especially
>>>>>> when I switched machines (from older Intel to newer AMD), then
>>>>>> often it made no measurable difference.
>>>>>>
>>>>>> So I'm looking at not bothering with optimisation at all. This is
>>>>>> because the difference between gcc-O3 (ver. 10.x), and my
>>>>>> unoptimised code is not that much for my programs anyway.
>>>>>>
>>>>>> Typically mine will be half the speed of gcc -O3 (gcc code takes
>>>>>> 50% less runtime). Here gcc takes 33% less runtime than mine:
>>>>>>
>>>>>
>>>>> At the higher end, people pay several times as much for chips that
>>>>> are less than 33% faster. Of course speed does not always matter,
>>>>> but sometimes it does.
>>>>
>>>> Actually 33% less runtime means 50% faster.
>>>>
>>>> But remember that scripting languages are also tremendously popular,
>>>> which can be 1-2 /magnitudes/ slower than optimised C code.
>>>
>>> As I said, speed does not always matter.
>>>
>>>>
>>>> So even a C compiler such as Tiny C can be significantly faster than
>>>> such languages for implementing the same programs.
>>>
>>> No one (well, no one who knows what they are doing) uses small C
>>> compilers when they want high speed results. That does not mean that
>>> everyone who uses or needs C is concerned about getting the fastest
>>> results. But those who /do/ want the fastest results, use one of the
>>> mainstream optimising compilers.
>>
>> My point here was that even the most naive native code compiler can
>> easily outperform dynamically typed and interpreted scripting
>> languages, when it comes to runtime speed.
>>
>> A huge amount of effort (eg. for JS) has been invested in trying to
>> make dynamic languages fast, yet the lowly tcc.exe can manage it
>> effortlessly and at little cost. Well, the cost is having to use C.
>>
>> I can see a small, fast C compiler being bundled into suitably
>> designed scripting languages, or some hybrid design, since it can
>> still give a significant speedup. You can't do that with a big
>> compiler as people will notice the start-up delay on running any
>> script (that and a 500MB sprawling installation).
>>
>
> No one cares about 500 MB installations, rounding to the nearest tenth
> of a percent of users. llvm was designed from the outset to work as a
> library for JIT compilation, and gcc is also now usable as a library.
> 500 MB is, what, about a minute of download time on an old slow
> connection? A thousandth of the space on a cheap disk?
>
> Of course many JIT systems will be smaller than that, since they are
> specially written for a single particular target language and target
> processor. But some will use the ready-written, well-tested and easily
> available llvm libraries. I'd be surprised if anyone bothered with tcc.
>
>>>>
>>>> (In fact, Tiny C compiling itself still results in a compiler that
>>>> runs rings around most others. I thought it was due to its using gcc
>>>> -O3, but that's only part of it. Here:
>>>>
>>>> https://github.com/sal55/langs/blob/master/Compilertest3.md
>>>>
>>>> tcc variations occupy all four entries at the end of the first
>>>> table, the fast end.)
>>>
>>> You seem to be having trouble understanding the information on that
>>> page. It shows that tcc /compiles/ quickly - not that it generates
>>> efficient.
>>
>> This point was that tcc compiles things quickly even when it's used to
>> build itself. I thought it was cheating a little since much of its
>> speed is due to gcc-O3; that is true, but it's still fast without that!
>
> That was not the point you claimed to make - nor is it a relevant point.
>
>>
>> code. I know you are fanatically obsessed with the speed of
>>> compilers, so maybe tcc is the perfect compiler for /you/. That's
>>> fine - I'm glad you are happy. Most serious C programmers look for
>>> other features and trade-offs in the tools.
>>
>> If you have an existing, working application supplied as C source
>> code, then to run it, it just needs translating tyo binary. Here you
>> don't need long, deep analyses of what might be wrong with it.
>>
>> In fact, tcc is small enough to bundle /with/ the source code. Then
>> applications can be run from source without any existing C installation.
>
> No windows user wants source code or to have to compile it, whether tcc
> is included or not (unless they are a C programmer, of course, in which
> case they will have a real compiler). No *nix user has a system that
> does not have a top-quality compiler. The people who see tcc as a
> directly useful compiler, rather than an interesting teaching tool,
> consist of the folks who think it is fun to get a "complete" *nix system
> on a 1.44" floppy, and you. Every attempt you make to suggest it is a
> serious and useful tool looks sillier than the last attempt you made,
> and detracts from the positive achievement of the compiler. It is an
> impressive piece of work, and it has its place as an example compiler
> for learning or for research (no sane person would try to learn about
> compiler design by looking at the gcc source code). You belittle it by
> desperately claiming it to be something it is not.
>
>
OK, I guess such a thing is not for you. For some people however the
difference between these two compilers:
c:\oldqx>tm gcc -O3 qq.c
TM: 15.27
c:\oldqx>tm tcc qq.c
TM: 0.08
That is, that one takes nearly 20000% as long than the other to get a
runnable program THAT GIVES EXACTLY THE SAME RESULTS, is extraordinary,
and a pretty big deal
(Did you know that some people pay several times as much for chips that
are merely 33% faster? Oh, you did!)
Note that my qq.c program is generated C code so has already been verified.
I know this will cut absolutely no ice with you, you're stuck on that
lofty pedestal with your large collection of heavyweight tools, but I
did once make use of tcc in a manner similar to how I suggested:
* I had my own compiler generating C code on Linux
* It then invoked either gcc or tcc to automatically build the result
Since the first stage was very fast, invoking gcc was like hitting a
brick wall, even using -O0. My preference then was to use tcc, which was
a much better match to my product.
But I had to make it optional because tcc is not routinely installed on
Linux. This is where I could have made use of a bundled version, if I'd
continued with it.
> The people who see tcc as a
> directly useful compiler, rather than an interesting teaching tool,
> consist of the folks who think it is fun to get a "complete" *nix system
> on a 1.44" floppy, and you.
You really, really don't get it do you? If I wanted to see whether my
bcc compiler is installed, and I see this:
c:\m>dir bcc.exe
31/08/2022 23:41 1,057,280 bcc.exe
then I know that all is well. If I want to check that gcc is installed,
then a similar listing will show nearly 10,000 files. How can I tell if
something essential is missing? I can't.
> Every attempt you make to suggest it is a
> serious and useful tool looks sillier than the l
If you were ever stuck for a working compiler, and only tcc was
available, I guess you'd be less fussy.
> from the positive achievement of the compiler. It is an
> impressive piece of work, and it has its place as an example compiler
> for learning or for research (no sane person would try to learn about
> compiler design by looking at the gcc source code). You belittle it b
Can you hear yourself? First you appear to praise it, then become
incredibly patronising by suggesting it is a toy or a teaching tool. And
then suggesting /I'm/ the one belittling it; WTF?
(Actually, as a teaching tool, my bcc product would be better, as tcc
doesn't support -S for example.)
I wonder, when you cook a meal at home, do you insist that only a huge,
industrial-sized and -equipped kitchen with an army of chefs can do the
job properly?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-05 23:05 +0000 |
| Message-ID | <OgvRK.14736$1Ly7.4989@fx34.iad> |
| In reply to | #167498 |
Bart <bc@freeuk.com> writes: >On 05/09/2022 21:54, David Brown wrote: >> > >OK, I guess such a thing is not for you. For some people however the >difference between these two compilers: > > c:\oldqx>tm gcc -O3 qq.c > TM: 15.27 > > c:\oldqx>tm tcc qq.c > TM: 0.08 > >That is, that one takes nearly 20000% as long than the other to get a >runnable program THAT GIVES EXACTLY THE SAME RESULTS, is extraordinary, >and a pretty big deal You can compare apples to oranges every day; it's a meaningless comparision outside of vague generalities (i.e. both are fruit, both contain juice, both may contain pips/seeds). gcc != tcc in any rational comparison.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-06 01:41 +0100 |
| Message-ID | <tf650e$1lih$1@gioia.aioe.org> |
| In reply to | #167502 |
On 06/09/2022 00:05, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 05/09/2022 21:54, David Brown wrote: > >>> >> >> OK, I guess such a thing is not for you. For some people however the >> difference between these two compilers: >> >> c:\oldqx>tm gcc -O3 qq.c >> TM: 15.27 >> >> c:\oldqx>tm tcc qq.c >> TM: 0.08 >> >> That is, that one takes nearly 20000% as long than the other to get a >> runnable program THAT GIVES EXACTLY THE SAME RESULTS, is extraordinary, >> and a pretty big deal > > You can compare apples to oranges every day; it's a meaningless comparision > outside of vague generalities (i.e. both are fruit, both contain juice, both > may contain pips/seeds). > > gcc != tcc in any rational comparison. If I take the same application and produce A.exe via gcc, and B.exe via tcc, the results of running either program are indistinguishable. That is, I can't tell if any output or any behaviour was produced by A or B. Unless I measured the runtime, then A might finish sooner. But there are other factors. If I run A on my machine and B on yours, then probably B will be quicker. So for all practical purposes, turning source code into a binary executable, there is very little difference. I'm not sure why this is apples and oranges. You obviously have something specific in mind as to the role of a compiler, one that is very different to mine. I expect that, if A.exe and B.exe were both just as fast as each other, you would still look down your nose at tcc. Personally I think the achievement of tcc is more to be admired than that of gcc. Sure the latter can produce very efficient code, but it would surprising if it didn't given its 60 optimising passes and spending 100 times longer and being 100 times bigger. Now try and do that in a smaller, faster package.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-06 09:39 +0200 |
| Message-ID | <tf6tfv$3rqn2$1@dont-email.me> |
| In reply to | #167498 |
On 05/09/2022 23:49, Bart wrote: > On 05/09/2022 21:54, David Brown wrote: >> On 05/09/2022 16:15, Bart wrote: >>> On 05/09/2022 14:52, David Brown wrote: >>>> On 05/09/2022 13:28, Bart wrote: >>>>> On 05/09/2022 07:22, David Brown wrote: >>>>>> On 05/09/2022 02:02, Bart wrote: >>>>>>> >>>>>>> I tried such a simple register allocator a couple of years ago, >>>>>>> which just kept some locals in registers when there were spare >>>>>>> registers. >>>>>>> >>>>>>> When applied to typical benchmarks, it worked pretty well. >>>>>>> >>>>>>> On real applications, it made a lot less difference, especially >>>>>>> when I switched machines (from older Intel to newer AMD), then >>>>>>> often it made no measurable difference. >>>>>>> >>>>>>> So I'm looking at not bothering with optimisation at all. This is >>>>>>> because the difference between gcc-O3 (ver. 10.x), and my >>>>>>> unoptimised code is not that much for my programs anyway. >>>>>>> >>>>>>> Typically mine will be half the speed of gcc -O3 (gcc code takes >>>>>>> 50% less runtime). Here gcc takes 33% less runtime than mine: >>>>>>> >>>>>> >>>>>> At the higher end, people pay several times as much for chips that >>>>>> are less than 33% faster. Of course speed does not always matter, >>>>>> but sometimes it does. >>>>> >>>>> Actually 33% less runtime means 50% faster. >>>>> >>>>> But remember that scripting languages are also tremendously >>>>> popular, which can be 1-2 /magnitudes/ slower than optimised C code. >>>> >>>> As I said, speed does not always matter. >>>> >>>>> >>>>> So even a C compiler such as Tiny C can be significantly faster >>>>> than such languages for implementing the same programs. >>>> >>>> No one (well, no one who knows what they are doing) uses small C >>>> compilers when they want high speed results. That does not mean >>>> that everyone who uses or needs C is concerned about getting the >>>> fastest results. But those who /do/ want the fastest results, use >>>> one of the mainstream optimising compilers. >>> >>> My point here was that even the most naive native code compiler can >>> easily outperform dynamically typed and interpreted scripting >>> languages, when it comes to runtime speed. >>> >>> A huge amount of effort (eg. for JS) has been invested in trying to >>> make dynamic languages fast, yet the lowly tcc.exe can manage it >>> effortlessly and at little cost. Well, the cost is having to use C. >>> >>> I can see a small, fast C compiler being bundled into suitably >>> designed scripting languages, or some hybrid design, since it can >>> still give a significant speedup. You can't do that with a big >>> compiler as people will notice the start-up delay on running any >>> script (that and a 500MB sprawling installation). >>> >> >> No one cares about 500 MB installations, rounding to the nearest tenth >> of a percent of users. llvm was designed from the outset to work as a >> library for JIT compilation, and gcc is also now usable as a library. >> 500 MB is, what, about a minute of download time on an old slow >> connection? A thousandth of the space on a cheap disk? >> >> Of course many JIT systems will be smaller than that, since they are >> specially written for a single particular target language and target >> processor. But some will use the ready-written, well-tested and >> easily available llvm libraries. I'd be surprised if anyone bothered >> with tcc. >> >>>>> >>>>> (In fact, Tiny C compiling itself still results in a compiler that >>>>> runs rings around most others. I thought it was due to its using >>>>> gcc -O3, but that's only part of it. Here: >>>>> >>>>> https://github.com/sal55/langs/blob/master/Compilertest3.md >>>>> >>>>> tcc variations occupy all four entries at the end of the first >>>>> table, the fast end.) >>>> >>>> You seem to be having trouble understanding the information on that >>>> page. It shows that tcc /compiles/ quickly - not that it generates >>>> efficient. >>> >>> This point was that tcc compiles things quickly even when it's used >>> to build itself. I thought it was cheating a little since much of its >>> speed is due to gcc-O3; that is true, but it's still fast without that! >> >> That was not the point you claimed to make - nor is it a relevant point. >> >>> >>> code. I know you are fanatically obsessed with the speed of >>>> compilers, so maybe tcc is the perfect compiler for /you/. That's >>>> fine - I'm glad you are happy. Most serious C programmers look for >>>> other features and trade-offs in the tools. >>> >>> If you have an existing, working application supplied as C source >>> code, then to run it, it just needs translating tyo binary. Here you >>> don't need long, deep analyses of what might be wrong with it. >>> >>> In fact, tcc is small enough to bundle /with/ the source code. Then >>> applications can be run from source without any existing C installation. >> >> No windows user wants source code or to have to compile it, whether >> tcc is included or not (unless they are a C programmer, of course, in >> which case they will have a real compiler). No *nix user has a system >> that does not have a top-quality compiler. The people who see tcc as >> a directly useful compiler, rather than an interesting teaching tool, >> consist of the folks who think it is fun to get a "complete" *nix >> system on a 1.44" floppy, and you. Every attempt you make to suggest >> it is a serious and useful tool looks sillier than the last attempt >> you made, and detracts from the positive achievement of the compiler. >> It is an impressive piece of work, and it has its place as an example >> compiler for learning or for research (no sane person would try to >> learn about compiler design by looking at the gcc source code). You >> belittle it by desperately claiming it to be something it is not. >> >> > > OK, I guess such a thing is not for you. For some people however the > difference between these two compilers: > > c:\oldqx>tm gcc -O3 qq.c > TM: 15.27 > Just as no one who is interested in fast executables uses a tool like tcc, no one who is interested in fast compilation uses "-O3" in gcc. "-O3" is telling gcc "I don't care how long you take, I don't care how big the resulting executable is - do everything you can to squeeze out the last fraction of a percent of speed that you can". Did you know that? Yes, of course you did - you've been told it countless times, yet you persist in intentionally muddying the waters and attempting to deceive people. > c:\oldqx>tm tcc qq.c > TM: 0.08 > > That is, that one takes nearly 20000% as long than the other to get a > runnable program THAT GIVES EXACTLY THE SAME RESULTS, is extraordinary, > and a pretty big deal > > (Did you know that some people pay several times as much for chips that > are merely 33% faster? Oh, you did!) > > Note that my qq.c program is generated C code so has already been verified. > > I know this will cut absolutely no ice with you, you're stuck on that > lofty pedestal with your large collection of heavyweight tools, but I > did once make use of tcc in a manner similar to how I suggested: > > * I had my own compiler generating C code on Linux > * It then invoked either gcc or tcc to automatically build the result > And did you know that I prefer my compilers to run quickly? Yes, of course you do, as I have told you many times. But I am not willing to sacrifice vital features of a tool in order to spare my computer a few seconds of processing time. > Since the first stage was very fast, invoking gcc was like hitting a > brick wall, even using -O0. My preference then was to use tcc, which was > a much better match to my product. > > But I had to make it optional because tcc is not routinely installed on > Linux. This is where I could have made use of a bundled version, if I'd > continued with it. > > > The people who see tcc as a > > directly useful compiler, rather than an interesting teaching tool, > > consist of the folks who think it is fun to get a "complete" *nix system > > on a 1.44" floppy, and you. > > You really, really don't get it do you? If I wanted to see whether my > bcc compiler is installed, and I see this: > We know /you/ like tcc, as you think it is more important to save your computer a couple of seconds than to save programmers' time. But you have yet to give any indication that there are others who think like you. > c:\m>dir bcc.exe > 31/08/2022 23:41 1,057,280 bcc.exe > > then I know that all is well. If I want to check that gcc is installed, > then a similar listing will show nearly 10,000 files. How can I tell if > something essential is missing? I can't. Perhaps you should ask such things in the "How to I use this computah thing?" newsgroup. > > > Every attempt you make to suggest it is a > > serious and useful tool looks sillier than the l > > If you were ever stuck for a working compiler, and only tcc was > available, I guess you'd be less fussy. Of course - what a silly thing to say. And if I had to put in some screws, and all I had was a hammer, I'd use the hammer. > > > from the positive achievement of the compiler. It is an > > impressive piece of work, and it has its place as an example compiler > > for learning or for research (no sane person would try to learn about > > compiler design by looking at the gcc source code). You belittle it b > > Can you hear yourself? First you appear to praise it, then become > incredibly patronising by suggesting it is a toy or a teaching tool. And > then suggesting /I'm/ the one belittling it; WTF? > It is used as a teaching tool. It was started as a joke or a challenge. It is not used as a normal real-world compiler. It is sometimes used for comparative benchmarks, or the very rare occasions when tiny size or high compile speed really are the overriding concerns for picking a tool. But those situations are highly unusual, and generally totally artificial (i.e., you want a tiny compiler not because size is relevant, but because that is the challenge you set yourself). > (Actually, as a teaching tool, my bcc product would be better, as tcc > doesn't support -S for example.) > > I wonder, when you cook a meal at home, do you insist that only a huge, > industrial-sized and -equipped kitchen with an army of chefs can do the > job properly? Pick the right tool for the right job. If armies of chefs had scaled down in size and cost, and scaled up in speed, the way the computer world has scaled - then yes, I'd have an army of chefs as they would fit happily in a small drawer in the kitchen and make my dinner in 30 seconds. Would you, in comparison, feel a drawer was too much space to use even for one of the kitchen's most important jobs - and therefore stick to your hamburger flipper who can make your chips in a couple of seconds and lives in a mouse hole? Professionals use professional-quality tools. When these are available freely, then serious amateurs use them too. There are plenty of different compilers that are appropriate for different tasks, and many /good/ reasons for picking particular compilers. Only a fool or a fanatic picks their tools for irrelevant and pointless reasons. There may be people who /do/ pick tcc as their tool of choice for good reasons (in addition to fun and challenges, which are always good reasons). I have yet to hear of any.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-06 10:50 +0100 |
| Message-ID | <tf754r$9qf$1@gioia.aioe.org> |
| In reply to | #167509 |
On 06/09/2022 08:39, David Brown wrote: > On 05/09/2022 23:49, Bart wrote: >> On 05/09/2022 21:54, David Brown wrote: >>> On 05/09/2022 16:15, Bart wrote: >>>> On 05/09/2022 14:52, David Brown wrote: >>>>> On 05/09/2022 13:28, Bart wrote: >>>>>> On 05/09/2022 07:22, David Brown wrote: >>>>>>> On 05/09/2022 02:02, Bart wrote: >>>>>>>> >>>>>>>> I tried such a simple register allocator a couple of years ago, >>>>>>>> which just kept some locals in registers when there were spare >>>>>>>> registers. >>>>>>>> >>>>>>>> When applied to typical benchmarks, it worked pretty well. >>>>>>>> >>>>>>>> On real applications, it made a lot less difference, especially >>>>>>>> when I switched machines (from older Intel to newer AMD), then >>>>>>>> often it made no measurable difference. >>>>>>>> >>>>>>>> So I'm looking at not bothering with optimisation at all. This >>>>>>>> is because the difference between gcc-O3 (ver. 10.x), and my >>>>>>>> unoptimised code is not that much for my programs anyway. >>>>>>>> >>>>>>>> Typically mine will be half the speed of gcc -O3 (gcc code takes >>>>>>>> 50% less runtime). Here gcc takes 33% less runtime than mine: >>>>>>>> >>>>>>> >>>>>>> At the higher end, people pay several times as much for chips >>>>>>> that are less than 33% faster. Of course speed does not always >>>>>>> matter, but sometimes it does. >>>>>> >>>>>> Actually 33% less runtime means 50% faster. >>>>>> >>>>>> But remember that scripting languages are also tremendously >>>>>> popular, which can be 1-2 /magnitudes/ slower than optimised C code. >>>>> >>>>> As I said, speed does not always matter. >>>>> >>>>>> >>>>>> So even a C compiler such as Tiny C can be significantly faster >>>>>> than such languages for implementing the same programs. >>>>> >>>>> No one (well, no one who knows what they are doing) uses small C >>>>> compilers when they want high speed results. That does not mean >>>>> that everyone who uses or needs C is concerned about getting the >>>>> fastest results. But those who /do/ want the fastest results, use >>>>> one of the mainstream optimising compilers. >>>> >>>> My point here was that even the most naive native code compiler can >>>> easily outperform dynamically typed and interpreted scripting >>>> languages, when it comes to runtime speed. >>>> >>>> A huge amount of effort (eg. for JS) has been invested in trying to >>>> make dynamic languages fast, yet the lowly tcc.exe can manage it >>>> effortlessly and at little cost. Well, the cost is having to use C. >>>> >>>> I can see a small, fast C compiler being bundled into suitably >>>> designed scripting languages, or some hybrid design, since it can >>>> still give a significant speedup. You can't do that with a big >>>> compiler as people will notice the start-up delay on running any >>>> script (that and a 500MB sprawling installation). >>>> >>> >>> No one cares about 500 MB installations, rounding to the nearest >>> tenth of a percent of users. llvm was designed from the outset to >>> work as a library for JIT compilation, and gcc is also now usable as >>> a library. 500 MB is, what, about a minute of download time on an old >>> slow connection? A thousandth of the space on a cheap disk? >>> >>> Of course many JIT systems will be smaller than that, since they are >>> specially written for a single particular target language and target >>> processor. But some will use the ready-written, well-tested and >>> easily available llvm libraries. I'd be surprised if anyone bothered >>> with tcc. >>> >>>>>> >>>>>> (In fact, Tiny C compiling itself still results in a compiler that >>>>>> runs rings around most others. I thought it was due to its using >>>>>> gcc -O3, but that's only part of it. Here: >>>>>> >>>>>> https://github.com/sal55/langs/blob/master/Compilertest3.md >>>>>> >>>>>> tcc variations occupy all four entries at the end of the first >>>>>> table, the fast end.) >>>>> >>>>> You seem to be having trouble understanding the information on that >>>>> page. It shows that tcc /compiles/ quickly - not that it generates >>>>> efficient. >>>> >>>> This point was that tcc compiles things quickly even when it's used >>>> to build itself. I thought it was cheating a little since much of >>>> its speed is due to gcc-O3; that is true, but it's still fast >>>> without that! >>> >>> That was not the point you claimed to make - nor is it a relevant point. >>> >>>> >>>> code. I know you are fanatically obsessed with the speed of >>>>> compilers, so maybe tcc is the perfect compiler for /you/. That's >>>>> fine - I'm glad you are happy. Most serious C programmers look for >>>>> other features and trade-offs in the tools. >>>> >>>> If you have an existing, working application supplied as C source >>>> code, then to run it, it just needs translating tyo binary. Here you >>>> don't need long, deep analyses of what might be wrong with it. >>>> >>>> In fact, tcc is small enough to bundle /with/ the source code. Then >>>> applications can be run from source without any existing C >>>> installation. >>> >>> No windows user wants source code or to have to compile it, whether >>> tcc is included or not (unless they are a C programmer, of course, in >>> which case they will have a real compiler). No *nix user has a >>> system that does not have a top-quality compiler. The people who see >>> tcc as a directly useful compiler, rather than an interesting >>> teaching tool, consist of the folks who think it is fun to get a >>> "complete" *nix system on a 1.44" floppy, and you. Every attempt you >>> make to suggest it is a serious and useful tool looks sillier than >>> the last attempt you made, and detracts from the positive achievement >>> of the compiler. It is an impressive piece of work, and it has its >>> place as an example compiler for learning or for research (no sane >>> person would try to learn about compiler design by looking at the gcc >>> source code). You belittle it by desperately claiming it to be >>> something it is not. >>> >>> >> >> OK, I guess such a thing is not for you. For some people however the >> difference between these two compilers: >> >> c:\oldqx>tm gcc -O3 qq.c >> TM: 15.27 >> > > Just as no one who is interested in fast executables uses a tool like > tcc, no one who is interested in fast compilation uses "-O3" in gcc. > "-O3" is telling gcc "I don't care how long you take, I don't care how > big the resulting executable is - do everything you can to squeeze out > the last fraction of a percent of speed that you can". Yes, that's what I use gcc-O3 for, not for routine compilation but to get the fastest possible executable. Actually, I only ever use gcc when I need to, because it is so annoyingly slow, whether I use -O3 or not. But -O2 still takes 12.3 seconds on my input. -O1 takes 6.4. -O0 takes 3.0 seconds, for code as bad as tcc's. > We know /you/ like tcc, as you think it is more important to save your > computer a couple of seconds than to save programmers' time. C, and the languages I devise, are all capable at being translated to good enough native code at hundred of thousands of lines per second (perhaps millions of lines per second on the machines you guys use, kind of ironic given that you downplay compilation speed so much). So why isn't that seen much in practice? That's why I like tcc, it highlights the possibilities. And shows up the competition, with products that are 100 times the size and 100 times slower, to produce an executable that runs only twice as fast. > Perhaps you should ask such things in the "How to I use this computah > thing?" newsgroup. So there is no advantage at all in having an application in a small, self-contained executable? I guess that's why there are countless tools to package Python applications into self-contained executables (although not so small), or why there is a trend among compilers now for there to be one large EXE rather than dozens of binaries (although not always self-contained). >> Can you hear yourself? First you appear to praise it, then become >> incredibly patronising by suggesting it is a toy or a teaching tool. >> And then suggesting /I'm/ the one belittling it; WTF? >> > > It is used as a teaching tool. I've never heard that. Teaching tools tend to involve one of those elaborate IDEs (which result in people not knowing how to build hello.c from the command line). According to Wikipedia about Tiny C: "It is designed to work for slow computers with little disk space (e.g. on rescue disks)" "This allows programs to be run as a shell script under Unix-like systems that support the shebang interpreter directive syntax." "Cinpy is a Python library that allows you to implement functions with C in Python modules. The functions are compiled with TCC at runtime. The results are made callable in Python through the ctypes library." (I've mentioned uses similar to the latter.) I think you need to open your mind a bit more. >> I wonder, when you cook a meal at home, do you insist that only a >> huge, industrial-sized and -equipped kitchen with an army of chefs can >> do the job properly? > > Pick the right tool for the right job. If armies of chefs had scaled > down in size and cost, and scaled up in speed, the way the computer > world has scaled - then yes, I'd have an army of chefs as they would fit > happily in a small drawer in the kitchen and make my dinner in 30 seconds. Scaling, yes. Imagine applying that to printed books: instead of properly editing a 10,000-page manuscript into 300 pages, you have the brilliant idea of type-setting at a tiny font. Except that with a book, it will take 30 times as long to read, and will not make any sense. With computer software however, using memory density and high clock speeds, you get can away with a lot more, and by much bigger factor than 30. That 300-page 'book' is more like 3 million pages (10,000 volumes).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-06 15:29 +0200 |
| Message-ID | <tf7hvu$3tq62$1@dont-email.me> |
| In reply to | #167510 |
On 06/09/2022 11:50, Bart wrote: > On 06/09/2022 08:39, David Brown wrote: >> On 05/09/2022 23:49, Bart wrote: >>> On 05/09/2022 21:54, David Brown wrote: >>>> On 05/09/2022 16:15, Bart wrote: > But -O2 still takes 12.3 seconds on my input. -O1 takes 6.4. -O0 takes > 3.0 seconds, for code as bad as tcc's. > Does anyone else care? >> We know /you/ like tcc, as you think it is more important to save your >> computer a couple of seconds than to save programmers' time. > > C, and the languages I devise, are all capable at being translated to > good enough native code at hundred of thousands of lines per second > (perhaps millions of lines per second on the machines you guys use, kind > of ironic given that you downplay compilation speed so much). > Does anyone else care? > So why isn't that seen much in practice? Good question. It's one that I've been asking, and which you can't seem to answer. All you are able to do is produce meaningless figures based on meaningless examples (they may be meaningful to /you/, but not to others). The answer, I believe, is that your obsession with tiny sizes and high compile speeds is not shared by many. > > So there is no advantage at all in having an application in a small, > self-contained executable? Small? No, not really. Of course there are degrees of "small". Most people in the western world - and certainly in any professional context - will be able to download a 500 MB toolchain in the time it takes to refill their coffee cup. And really, how often do you need to download or install a toolchain? Self-contained? Yes, there can be advantages in that. Things like AppImage on Linux or "Portable" images on Windows can be very convenient to let you use software without leaving traces of it (such as libraries, registry settings, etc.) behind. It is not nearly as relevant for a tool you expect to use a lot, such as a compiler toolchain, but it might be nice for testing unusual toolchains. But as for the /size/ of these, I really don't care. > > I guess that's why there are countless tools to package Python > applications into self-contained executables (although not so small), or > why there is a trend among compilers now for there to be one large EXE > rather than dozens of binaries (although not always self-contained). > >>> Can you hear yourself? First you appear to praise it, then become >>> incredibly patronising by suggesting it is a toy or a teaching tool. >>> And then suggesting /I'm/ the one belittling it; WTF? >>> >> >> It is used as a teaching tool. > > I've never heard that. Teaching tools tend to involve one of those > elaborate IDEs (which result in people not knowing how to build hello.c > from the command line). > I was thinking of teaching about compilers and compiler design. No one would use tcc as a toolchain if they were teaching C programming. > According to Wikipedia about Tiny C: > > "It is designed to work for slow computers with little disk space (e.g. > on rescue disks)" > Rescue "disks" have rarely been seen for the last couple of decades. People transitioned to rescue CD's, then rescue USB sticks. There certainly was a time when rescue floppies were useful, but it is /long/ past. And when you had rescue floppies, you would not have had a C compiler on them. > "This allows programs to be run as a shell script under Unix-like > systems that support the shebang interpreter directive syntax." > > "Cinpy is a Python library that allows you to implement functions with C > in Python modules. The functions are compiled with TCC at runtime. The > results are made callable in Python through the ctypes library." > > (I've mentioned uses similar to the latter.) You have claimed it could be done - I believe this is the first time you have given a real example. > > I think you need to open your mind a bit more. > >>> I wonder, when you cook a meal at home, do you insist that only a >>> huge, industrial-sized and -equipped kitchen with an army of chefs >>> can do the job properly? >> >> Pick the right tool for the right job. If armies of chefs had scaled >> down in size and cost, and scaled up in speed, the way the computer >> world has scaled - then yes, I'd have an army of chefs as they would >> fit happily in a small drawer in the kitchen and make my dinner in 30 >> seconds. > > Scaling, yes. Imagine applying that to printed books: instead of > properly editing a 10,000-page manuscript into 300 pages, you have the > brilliant idea of type-setting at a tiny font. > > Except that with a book, it will take 30 times as long to read, and will > not make any sense. > > With computer software however, using memory density and high clock > speeds, you get can away with a lot more, and by much bigger factor than > 30. That 300-page 'book' is more like 3 million pages (10,000 volumes). > We've already seen what happens with one wildly inappropriate metaphor. We don't need a second one.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2022-09-06 17:05 +0300 |
| Message-ID | <20220906170548.2ea3725297a6029c5ae6c057@g{oogle}mail.com> |
| In reply to | #167512 |
David Brown to Bart: > > But -O2 still takes 12.3 seconds on my input. -O1 takes > > 6.4. -O0 takes 3.0 seconds, for code as bad as tcc's. > > Does anyone else care? Yes, I suffer sorely while building DOSBox. It may up to 10 minutes on my PC, what with the slowness of GCC and colossally complicated makefiles. Freepascal compiles similar code in a matter of seconds. Such slowness is bad even nobody cares because it should how terribly bloated is the product. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-06 15:43 +0100 |
| Message-ID | <tf7maq$n1m$1@gioia.aioe.org> |
| In reply to | #167512 |
On 06/09/2022 14:29, David Brown wrote: > On 06/09/2022 11:50, Bart wrote: > Does anyone else care? About what? You say I'm obsessed with compilation speed. Well, I guess so are you: you probably have a much faster machine than I do (why). You run a compiler which spends most of its time optimising for speed. It has a lot of tricks to avoid compilation unless necessary, again for speed. Yet, you are completely unimpressed with an application that is magnitudes faster than another for doing pretty much the same job, as far as some of us are concerned. (That is, take the source code of a program, and produce a runable executable.) You have your own strong opinions about what a compiler's job is, and I have my own opinion which is very different from yours. So who's right? I'm been writing compilers TO GET STUFF DONE for 40 years, so I think I have a good grasp of what /I/ value in such a program. My style of development is to constantly edit and run until something works. When you have effectively instant compilation, you can afford to keep making tiny changes code to (eg. add a space to line up a message) until it's right, since building a new executable from scratch is finished even before you take your finger off the Enter key. According to you I should give that up? Fast, whole-program compilers which are what I work on open up new opportunities to do things differently, but I won't bore you with that because nothing I say will make a blind bit of difference to you. >>> We know /you/ like tcc, as you think it is more important to save >>> your computer a couple of seconds than to save programmers' time. >> >> C, and the languages I devise, are all capable at being translated to >> good enough native code at hundred of thousands of lines per second >> (perhaps millions of lines per second on the machines you guys use, >> kind of ironic given that you downplay compilation speed so much). >> > > Does anyone else care? EVERYONE cares about speed. Most are jealous because they are stuck using languages or compilers which are slow. Usually their only recourse is to throw processing power, memory, faster drives and multiple cores at the problem. Plus extra money and extra power. > >> So why isn't that seen much in practice? > > Good question. It's one that I've been asking, and which you can't seem > to answer. All you are able to do is produce meaningless figures based > on meaningless examples (they may be meaningful to /you/, but not to > others). The answer, I believe, is that your obsession with tiny sizes > and high compile speeds is not shared by many. I like small, lean, fast tools, and small, lean, fast languages. Why not? You seem to have trouble distinguishing between tool chains used for development; those used to build production versions of applications; and those someone might use to build a working source distribution. They all have different requirements, and may be done by different people. When it comes to distributing software as source code, that often requires a plethora of tools, languages and applications to be installed (or requires Linux). My approach again is very lean: I would provide just one self-contained source file for distribution. That requires only a compiler (one file if it's my language, otherwise a C compiler; tcc is recommended!). > Self-contained? Yes, there can be advantages in that. Things like > AppImage on Linux or "Portable" images on Windows can be very convenient > to let you use software without leaving traces of it (such as libraries, > registry settings, etc.) behind. It is not nearly as relevant for a > tool you expect to use a lot, such as a compiler toolchain, but it might > be nice for testing unusual toolchains. But as for the /size/ of these, > I really don't care. Look, it's very simple: there is a whole world out there of huge, complicated, ginormous tool-sets; big, slow, lumbering compilers and linkers. (Moreover, compilers that have no idea how to compiler C code unless you tell them in excruciating detail exactly what is valid and what isn't.) You're quite happy with that and so are many others. But I specifically work at the opposite end, and do so deliberately to make a stand. My products have a common theme: 'One-file'; self-contained; small; fast; simple; accessible; human scale. You don't like that? Then fuck you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-06 17:19 +0200 |
| Message-ID | <tf7oe4$3udso$1@dont-email.me> |
| In reply to | #167514 |
On 06/09/2022 16:43, Bart wrote: > On 06/09/2022 14:29, David Brown wrote: >> On 06/09/2022 11:50, Bart wrote: > >> Does anyone else care? > > About what? About the size of their toolchain. Everyone (including me) cares about speed, and would like their compiler to be faster. However, I think most people do not see the speed of the compiler as being the only relevant factor. Nor do they see "faster than fast enough" as a key benefit. Sure, compilation times measured in minutes can be annoying - but build times of less than about 5 seconds are fast enough that any speedup has no practical influence. > > You say I'm obsessed with compilation speed. Well, I guess so are you: > you probably have a much faster machine than I do (why). My machine is about 6 years old, and was not remotely top-of-the-line at that time. I do have quite a bit of ram - 32 GB - so that I can run ram-hungry IDE's without concern. It should not be difficult to find a used machine of equivalent power for about £200 or so, especially if you are happy to upgrade the ram yourself. > You run a > compiler which spends most of its time optimising for speed. I run tools that do the job I need them to do. Generating efficient object code for the targets I use, is part of that - but it is not all of it. There are many reasons why gcc is far more suited to serious programming than tcc - quality of the generated code is just one of them. > It has a > lot of tricks to avoid compilation unless necessary, again for speed. > My compiler has no such tricks. Perhaps you are referring to "make" - a utility that has nothing to do with C, gcc or any compiler, and which has been used with many tools and many languages (and many tasks that have nothing to do with coding), for something like four decades. There really isn't anything unusual about my computer, my OS, my compiler, my build system - it's the same stuff professional programmers have been using for a generation or more. > Yet, you are completely unimpressed with an application that is > magnitudes faster than another for doing pretty much the same job, as > far as some of us are concerned. (That is, take the source code of a > program, and produce a runable executable.) > > You have your own strong opinions about what a compiler's job is, and I > have my own opinion which is very different from yours. So who's right? > > I'm been writing compilers TO GET STUFF DONE for 40 years, so I think I > have a good grasp of what /I/ value in such a program. > > My style of development is to constantly edit and run until something > works. When you have effectively instant compilation, you can afford to > keep making tiny changes code to (eg. add a space to line up a message) > until it's right, since building a new executable from scratch is > finished even before you take your finger off the Enter key. > > According to you I should give that up? No, there is no need to give up. But /growing/ up might make you more productive. You have managed to achieve a great deal, but much of that is /despite/ your choices, not because of them. It is ridiculous to be concerned about build speeds and then not use standard tools to help. It is absurd to worry about seconds of your time for compilation, while using an ancient computer that isn't worth half an hour of your professional time. And you'd get on far better by learning the language you are using, getting real tools and learning how to use them, so that you can write code correctly and find more mistakes /before/ you get as far as trial-and-error coding. You've been so busy programming the same way for 40 years that you don't seem to have noticed the world has moved on, and there are better ways to do things.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2022-09-06 18:19 +0200 |
| Message-ID | <tf7rto$1t6n$1@news.gegeweb.eu> |
| In reply to | #167514 |
On 9/6/22 16:43, Bart wrote:
> My style of development is to constantly edit and run until something
> works.
http://www.catb.org/jargon/html/S/shotgun-debugging.html
tTh
--
+------------------------------------------------------------------+
| https://framalibre.org/content/tetalab |
+------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-09-08 06:18 -0700 |
| Message-ID | <2f1747bf-1f9b-4a93-b3fb-2749b3dc61b8n@googlegroups.com> |
| In reply to | #167516 |
On Tuesday, 6 September 2022 at 19:19:17 UTC+3, tTh wrote: > On 9/6/22 16:43, Bart wrote: > > > My style of development is to constantly edit and run until something > > works. > http://www.catb.org/jargon/html/S/shotgun-debugging.html https://en.wikipedia.org/wiki/Voodoo_programming
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-07 18:10 +0100 |
| Message-ID | <tfaj9e$1bkf$1@gioia.aioe.org> |
| In reply to | #167512 |
On 06/09/2022 14:29, David Brown wrote: > On 06/09/2022 11:50, Bart wrote: >> So why isn't that seen much in practice? > > Good question. It's one that I've been asking, and which you can't seem > to answer. All you are able to do is produce meaningless figures based > on meaningless examples (they may be meaningful to /you/, but not to > others). The answer, I believe, is that your obsession with tiny sizes > and high compile speeds is not shared by many. For those who do care about this stuff: It is not so much an obsession, as a mystery as to why some compilers are so much bigger and slower. They may produce somewhat faster code, but could it be done at a much lower cost? That is, in a smaller compiler, and with a higher throughput. People like DB are too familiar with the ins and outs of the C language and its compilers and associated tools and know of a million things that they want such a commpiler to spend its time doing, other than generating code. However I work on other language related products and I've seen the same effect there too; mainstream products are much slower than they could be: - Bytecode compilers for interpreters - Assemblers Here the task is much, much more straightforward, and little for the compilers or assembler to get its teeth into. On one test input, CPython only managed a throughput of 130K lines per second, while my product managed 1.5M lines per second. This is compiling to bytecode followed by the fixups necessary to run the code. The program runtime itself was neglible. (PyPy managed only 60Klps, but it has a much harder job ahead. However LuaJIT also did about 1.5Mlps, for a version with higher code density too.) On a different test, the YASM assembler (itself a much faster version of NASM) was about a magnitude slower than my own product. 'as', which is actually quite nippy, was perhaps half a magnitude slower too. (In all case, I'm am comparing unoptimised code of my products to, most like, optimised code.) Then the question needs to be asked, why are those other tools slower, and could those reasons be affecting HLL compilers too? Nobody appears to be doing that, not helped by certain people dismissing the smaller, faster products as toys not worthy of consideration.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-07 20:31 +0200 |
| Message-ID | <tfao14$9tnc$1@dont-email.me> |
| In reply to | #167529 |
On 07/09/2022 19:10, Bart wrote:
> Then the question needs to be asked, why are those other tools slower,
> and could those reasons be affecting HLL compilers too?
>
In-depth analysis of code takes time and effort in the compiler.
Efficient code generation as well as solid static error checking,
require in-depth analysis. Ergo, compilers that generate efficient code
and do advanced static error checking take time to run. Modern
compilers will analyse the paths through code, tracking constants or
known facts (such as possible ranges for values) through call-trees of
functions. They do inter-procedural optimisations that may scale
quadratically (or worse) with the number of functions or number of
lines. They track variable lifetimes (the period when a local variable
is actually in use, not just its C lifetime). It all takes time and
effort, and sophisticated tools.
Could the tools be faster? Without doubt, yes. Big projects like gcc
suffer from being built up over a long time by many people - there will
be many aspects where a complete re-write from scratch would give far
more efficient results. But that is obviously impractical.
I'm sure some of these reasons apply equally to HLL compilers and JIT tools.
> Nobody appears to be doing that, not helped by certain people dismissing
> the smaller, faster products as toys not worthy of consideration.
>
I think you greatly underestimate the effort made by people who write
such tools - they /do/ care about speed ("care", not "obsess" - speed is
good but not an overriding priority in most cases). I don't know how
many gcc, llvm or other developer conferences you have been to in order
to justify claiming "nobody appears to be doing that".
And I think you greatly overestimate the influence of "certain people"
who see compilers such as tcc as being of niche usage, and a toy in
comparison to heavyweight toolchains. Do you really think the gcc
developers ignore the speed of their compiler purely because they have
read one of my posts on Usenet?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-07 19:41 +0000 |
| Message-ID | <Ft6SK.120726$w35c.87771@fx47.iad> |
| In reply to | #167534 |
David Brown <david.brown@hesbynett.no> writes:
>On 07/09/2022 19:10, Bart wrote:
>
>> Then the question needs to be asked, why are those other tools slower,
>> and could those reasons be affecting HLL compilers too?
>>
<snip>
>
>> Nobody appears to be doing that, not helped by certain people dismissing
>> the smaller, faster products as toys not worthy of consideration.
>>
>
>I think you greatly underestimate the effort made by people who write
>such tools - they /do/ care about speed ("care", not "obsess" - speed is
>good but not an overriding priority in most cases). I don't know how
>many gcc, llvm or other developer conferences you have been to in order
>to justify claiming "nobody appears to be doing that".
And, given that pretty much everything Bart has complained about is
open source. I'm sure the current project maintainers would be
very happy to accept Bart's contributions to improve compilation
times.
Rather than just complaining about it.
>
>And I think you greatly overestimate the influence of "certain people"
>who see compilers such as tcc as being of niche usage, and a toy in
>comparison to heavyweight toolchains. Do you really think the gcc
>developers ignore the speed of their compiler purely because they have
>read one of my posts on Usenet?
I work with one of the gcc developers, and he certainly cares
about the speed of the compiler, but he also cares about the quality
of implementation, including the quality of generated code, the
support for multiple architectures (arm, mips, x86, riscv), support
for current standards and a host of other considerations and constraints.
Then there is the science of benchmarking itself, which Bart doesn't
seem to be very familiar with, starting with reproducability.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-07 22:05 +0100 |
| Message-ID | <tfb124$1h3c$1@gioia.aioe.org> |
| In reply to | #167534 |
On 07/09/2022 19:31, David Brown wrote:
> On 07/09/2022 19:10, Bart wrote:
>
>> Then the question needs to be asked, why are those other tools slower,
>> and could those reasons be affecting HLL compilers too?
>>
>
> In-depth analysis of code takes time and effort in the compiler.
> Efficient code generation as well as solid static error checking,
> require in-depth analysis. Ergo, compilers that generate efficient code
> and do advanced static error checking take time to run. Modern
> compilers will analyse the paths through code, tracking constants or
> known facts (such as possible ranges for values) through call-trees of
> functions. They do inter-procedural optimisations that may scale
> quadratically (or worse) with the number of functions or number of
> lines. They track variable lifetimes (the period when a local variable
> is actually in use, not just its C lifetime). It all takes time and
> effort, and sophisticated tools.
This is why I used bytecode compilers and assemblers for extra examples.
The only time-consuming thing an assembler might do is multiple passes
to minimise forward jump displacements (something that IME might make 1%
difference).
But NASM, which I used to use, had a bug that either no one noticed, or
no one cared about, since I tried reporting it. On large inputs of real
programs (say 100K lines, which might be the output of a whole-program
compilation), it got exponentially slow.
Like, taking a minute or more to assemble. Minimising those passes might
reduce 60 seconds to 40, but that's still far too long.
It's possible the bug affects normal-sized inputs too, but it's just not
as obvious; it's a just a regular slow assembler (until you stop to
think why an assembler would be slow).
I created my own product for the job (which tackles 100K lines in some
50ms), although I later discovered YASM which doesn't have the bug
(still not as fast as mine though).
> Could the tools be faster? Without doubt, yes. Big projects like gcc
> suffer from being built up over a long time by many people - there will
> be many aspects where a complete re-write from scratch would give far
> more efficient results. But that is obviously impractical.
Clang was written from scratch. By the time it was a perfect clone of
gcc, it was just as slow. And now I believe it's built on top of LLVM.
>> Nobody appears to be doing that, not helped by certain people
>> dismissing the smaller, faster products as toys not worthy of
>> consideration.
>>
>
> I think you greatly underestimate the effort made by people who write
> such tools - they /do/ care about speed ("care", not "obsess" - speed is
> good but not an overriding priority in most cases). I don't know how
> many gcc, llvm or other developer conferences you have been to in order
> to justify claiming "nobody appears to be doing that".
Is there somebody whose job it is to simplify, delete and consolidate? I
got the impression from what jacob navia used to say that people who
work on gcc like to add things rather than than remove.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-08 10:07 +0200 |
| Message-ID | <tfc7s2$m3mk$1@dont-email.me> |
| In reply to | #167542 |
On 07/09/2022 23:05, Bart wrote:
> On 07/09/2022 19:31, David Brown wrote:
>> On 07/09/2022 19:10, Bart wrote:
>>
>>> Then the question needs to be asked, why are those other tools
>>> slower, and could those reasons be affecting HLL compilers too?
>>>
>>
>> In-depth analysis of code takes time and effort in the compiler.
>> Efficient code generation as well as solid static error checking,
>> require in-depth analysis. Ergo, compilers that generate efficient
>> code and do advanced static error checking take time to run. Modern
>> compilers will analyse the paths through code, tracking constants or
>> known facts (such as possible ranges for values) through call-trees of
>> functions. They do inter-procedural optimisations that may scale
>> quadratically (or worse) with the number of functions or number of
>> lines. They track variable lifetimes (the period when a local
>> variable is actually in use, not just its C lifetime). It all takes
>> time and effort, and sophisticated tools.
>
> This is why I used bytecode compilers and assemblers for extra examples.
>
> The only time-consuming thing an assembler might do is multiple passes
> to minimise forward jump displacements (something that IME might make 1%
> difference).
>
There are assemblers that do more, such as re-organising code sections
to shorten branches or improve code and data locality for better cache
efficiency. I don't know details of many such assemblers in practice
(and I know nothing of NASM in particular), but it's easy to see that
such optimisations could become equivalent to the travelling salesman
problem if the assembler writer gets too enthusiastic.
> But NASM, which I used to use, had a bug that either no one noticed, or
> no one cared about, since I tried reporting it. On large inputs of real
> programs (say 100K lines, which might be the output of a whole-program
> compilation), it got exponentially slow.
>
> Like, taking a minute or more to assemble. Minimising those passes might
> reduce 60 seconds to 40, but that's still far too long.
>
> It's possible the bug affects normal-sized inputs too, but it's just not
> as obvious; it's a just a regular slow assembler (until you stop to
> think why an assembler would be slow).
>
"Bug" implies a specific error in the implementation - this could be a
design limitation with the algorithms used simply not scalable to such
large code bases. Perhaps the jump optimisation is done in a simplistic
way where each time an opportunity for shorting a jump is found, a new
full pass is triggered to run through the entire source again. That
would give you roughly quadratic scaling, but might easily be worse in
some cases. Perhaps the data structures for the symbol tables are
optimised for smaller sizes of source that are more realistic - NASM was
designed long before whole-program optimisation was common.
I don't know NASM at all, and have not used it, so I can only make vague
suggestions. And maybe it is as simple as a bug somewhere.
> I created my own product for the job (which tackles 100K lines in some
> 50ms), although I later discovered YASM which doesn't have the bug
> (still not as fast as mine though).
>
Making a fast assembler is not usually a hard task (though there are a
great many time-consuming details). And you are correct that the kinds
of optimisations done in assemblers rarely have significant effects.
>
>> Could the tools be faster? Without doubt, yes. Big projects like gcc
>> suffer from being built up over a long time by many people - there
>> will be many aspects where a complete re-write from scratch would give
>> far more efficient results. But that is obviously impractical.
>
> Clang was written from scratch. By the time it was a perfect clone of
> gcc, it was just as slow. And now I believe it's built on top of LLVM.
>
clang was always a front-end to llvm. LLVM is designed to be a
middle-end for compilers (including byte compilers, JIT compilers, etc.)
that handles low level language agnostic optimisations of a generalised
virtual processor. It does things like inter-procedural optimisations,
constant propagation, whole-program optimisations, and corresponding
static analysis and error checking. The input to LLVM comes from a
variety of front-end language handlers - C and C++ are covered by clang,
Fortran by flang, and there are a dozen or more others. The output is
passed on to one of many back ends for different target processors.
When clang/llvm was new, it was a lot faster than gcc but the resulting
code was not nearly as efficient, the static checking was not as
powerful (though the messages it produced were neater), and the
extensions and additional features were fewer. Gradually it caught up
with gcc in its power - and slowed in compilation speed. Meanwhile, gcc
was inspired to improve compilation speed and give better warning
messages. Now they are much closer in functionality (but "clone" is
completely the wrong idea), and also in speed.
That tells us that gcc is not, in fact, particularly slow for what it
does. It had scope for improvement, and still does, but if you want a
compiler that can do what gcc can do, it takes time. (You can look at
Intel's icc for another sample.)
I have said repeatedly that I do not see compilation time as an issue
for C, and that is, I believe, the common attitude. But for C++ it is a
different matter entirely. C++ compilation is much more time-consuming
in itself, and C++ headers are often massively more complex than C
headers - entire libraries are included in headers so that compiling
your 5 KLoc source file might mean the compiler faces 1 MLoc after
includes. So C++ compilation speed is always the main focus for the
compiler developers, with much less consideration for C.
>>> Nobody appears to be doing that, not helped by certain people
>>> dismissing the smaller, faster products as toys not worthy of
>>> consideration.
>>>
>>
>> I think you greatly underestimate the effort made by people who write
>> such tools - they /do/ care about speed ("care", not "obsess" - speed
>> is good but not an overriding priority in most cases). I don't know
>> how many gcc, llvm or other developer conferences you have been to in
>> order to justify claiming "nobody appears to be doing that".
>
> Is there somebody whose job it is to simplify, delete and consolidate? I
> got the impression from what jacob navia used to say that people who
> work on gcc like to add things rather than than remove.
>
Imagine it like running a town. You have a town council that makes the
big decisions, with members who change over time and have different
ideas. You have a town that people use, but there are always new
facilities to introduce, repairs or changes to be made, people that
complain about problems that must be fixed - all with limited resources,
and without breaking everything. When you need a new school, it's much
easier to build it in the outskirts where there is more space. When you
need a faster road, you build a bypass or a ring-road - you don't mess
with the historic town centre. You know that the town would run more
efficiently if you knocked down the middle part and set it up as a neat
grid of wide streets - and you know it is utterly impossible to do that.
You might occasionally knock down an old building, but you don't do so
often.
In comparison, you've built your own hut in the woods, and gradually
turned it into a working farm. That is hugely impressive. But it
cannot be compared to the town, either in its functionality, its users,
its features, or how it is run and changed. (And in this metaphor,
Jacob inherited his grandparent's farm and added some extensions and a
barn.)
Simplification, deletion and consolidation /do/ happen in projects like
gcc, but rarely and not without /very/ strong justification.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-05 21:42 +0000 |
| Message-ID | <o3uRK.7569$I0A5.4853@fx04.iad> |
| In reply to | #167487 |
Bart <bc@freeuk.com> writes: >On 05/09/2022 07:22, David Brown wrote: >> On 05/09/2022 02:02, Bart wrote: >>> >>> I tried such a simple register allocator a couple of years ago, which >>> just kept some locals in registers when there were spare registers. >>> >>> When applied to typical benchmarks, it worked pretty well. >>> >>> On real applications, it made a lot less difference, especially when I >>> switched machines (from older Intel to newer AMD), then often it made >>> no measurable difference. >>> >>> So I'm looking at not bothering with optimisation at all. This is >>> because the difference between gcc-O3 (ver. 10.x), and my unoptimised >>> code is not that much for my programs anyway. >>> >>> Typically mine will be half the speed of gcc -O3 (gcc code takes 50% >>> less runtime). Here gcc takes 33% less runtime than mine: >>> >> >> At the higher end, people pay several times as much for chips that are >> less than 33% faster. Of course speed does not always matter, but >> sometimes it does. > >Actually 33% less runtime means 50% faster. > >But remember that scripting languages are also tremendously popular, >which can be 1-2 /magnitudes/ slower than optimised C code. > >So even a C compiler such as Tiny C can be significantly faster than >such languages for implementing the same programs. > >(In fact, Tiny C compiling itself still results in a compiler that runs >rings around most others. I thought it was due to its using gcc -O3, but >that's only part of it. Here: > >https://github.com/sal55/langs/blob/master/Compilertest3.md > >tcc variations occupy all four entries at the end of the first table, >the fast end.) As as been noted before, compilation speed is an irrelevent benchmark. It's not like the compiler is limited to the speed of the card reader anymore. The speed of the "compiled" code is much more relevent.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-05 23:11 +0100 |
| Message-ID | <tf5s76$ut9$1@gioia.aioe.org> |
| In reply to | #167497 |
On 05/09/2022 22:42, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 05/09/2022 07:22, David Brown wrote:
>>> On 05/09/2022 02:02, Bart wrote:
>>>>
>>>> I tried such a simple register allocator a couple of years ago, which
>>>> just kept some locals in registers when there were spare registers.
>>>>
>>>> When applied to typical benchmarks, it worked pretty well.
>>>>
>>>> On real applications, it made a lot less difference, especially when I
>>>> switched machines (from older Intel to newer AMD), then often it made
>>>> no measurable difference.
>>>>
>>>> So I'm looking at not bothering with optimisation at all. This is
>>>> because the difference between gcc-O3 (ver. 10.x), and my unoptimised
>>>> code is not that much for my programs anyway.
>>>>
>>>> Typically mine will be half the speed of gcc -O3 (gcc code takes 50%
>>>> less runtime). Here gcc takes 33% less runtime than mine:
>>>>
>>>
>>> At the higher end, people pay several times as much for chips that are
>>> less than 33% faster. Of course speed does not always matter, but
>>> sometimes it does.
>>
>> Actually 33% less runtime means 50% faster.
>>
>> But remember that scripting languages are also tremendously popular,
>> which can be 1-2 /magnitudes/ slower than optimised C code.
>>
>> So even a C compiler such as Tiny C can be significantly faster than
>> such languages for implementing the same programs.
>>
>> (In fact, Tiny C compiling itself still results in a compiler that runs
>> rings around most others. I thought it was due to its using gcc -O3, but
>> that's only part of it. Here:
>>
>> https://github.com/sal55/langs/blob/master/Compilertest3.md
>>
>> tcc variations occupy all four entries at the end of the first table,
>> the fast end.)
>
> As as been noted before, compilation speed is an irrelevent benchmark.
>
> It's not like the compiler is limited to the speed of the card reader
> anymore.
>
> The speed of the "compiled" code is much more relevent.
Why? How important is it actually? What proportion of builds are for
finished production executables that will be run 1000s of times to make
the extra compile-time worthwhile?
Here are some actual measurements I just posted in a reply to David Brown:
c:\oldqx>tm gcc -O3 qq.c
TM: 15.27
c:\oldqx>tm tcc qq.c
TM: 0.08
Please tell why I need to hang about 200 times longer for a program I
might run once. Sure, gcc -O0 will be faster (it only takes 36 times as
long), but the code is just as slow, so what's the point? (As I said
there, this C code has been verified.)
Out of interest, how big and how slow does a compiler have to get before
even you start to complain?
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web