Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #157279 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2020-12-15 13:57 -0800 |
| Last post | 2020-12-21 22:17 +0100 |
| Articles | 20 on this page of 300 — 18 participants |
Back to article view | Back to comp.lang.c
A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-15 13:57 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-16 02:11 +0300
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 01:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 10:48 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 04:16 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:04 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 16:06 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 15:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 19:32 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 21:12 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-17 13:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:35 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 06:05 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 15:28 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 08:49 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 18:24 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 10:31 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 16:53 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:33 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:06 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:55 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:09 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-18 15:39 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:55 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 17:05 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 17:12 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:41 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 10:13 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:28 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 11:35 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:45 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 13:26 -0500
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 11:31 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 20:41 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 19:57 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:05 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 20:26 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:59 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 15:23 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 17:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:21 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 20:13 +0000
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:37 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 16:26 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-25 00:55 +0000
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 12:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 14:01 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 16:32 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 07:42 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 16:07 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:38 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 17:25 +0100
Re: A defer mechanism for C Christian Hanné <the.hanne@gmail.com> - 2020-12-20 17:46 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 09:07 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:43 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 10:11 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 14:58 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:58 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:41 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 20:25 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 22:34 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 20:52 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-20 12:37 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:42 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:19 -0500
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-21 10:18 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 11:06 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:09 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:13 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:18 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:26 -0700
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:47 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:59 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:25 -0700
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-21 14:23 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-22 09:58 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:57 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:19 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-27 11:24 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 22:45 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 00:33 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 11:31 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-29 17:24 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 18:43 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 11:32 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 03:34 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 21:06 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-29 20:40 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 02:56 -0800
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:22 -0700
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 02:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 06:49 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-24 03:16 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 13:38 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:37 -0800
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-25 11:39 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:34 -0800
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:48 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:51 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 22:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 09:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:18 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:32 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:55 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:16 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 22:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:42 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 05:53 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:40 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:19 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 11:01 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 03:45 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 13:25 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 06:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 15:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 07:05 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:13 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:21 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:06 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 08:57 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:43 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-16 12:05 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 14:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 15:57 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:49 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 11:33 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:05 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:52 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 10:59 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 20:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 19:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 21:56 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:03 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 12:30 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:16 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:39 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 13:44 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 06:54 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 13:28 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:14 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:16 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:19 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:26 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 17:07 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 18:18 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 18:34 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:40 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 21:16 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 22:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 21:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:25 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:01 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 02:45 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 13:33 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:24 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:28 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 21:55 -0800
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:38 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:51 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-25 20:00 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:19 +0100
Re: A defer mechanism for C Öö Tiib <ootiib@hot.ee> - 2020-12-26 19:10 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:42 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 02:29 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:11 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 09:33 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 18:50 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-26 07:40 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:36 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:49 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:39 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:25 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 01:55 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:16 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:55 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:10 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 16:47 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:22 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:09 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:25 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 08:02 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:55 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 21:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 23:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:40 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:59 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:10 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:46 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:46 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:00 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 10:59 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 11:12 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:18 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 16:25 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 19:24 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 09:07 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:36 +0300
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-19 15:54 -0500
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 01:21 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 15:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:53 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:55 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 12:07 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 03:38 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:40 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:00 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:02 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:43 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:34 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:11 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 17:22 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:08 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:26 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:36 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:54 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:12 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 15:13 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 12:45 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 16:25 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 13:38 +0000
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:26 -0500
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 20:30 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 21:41 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:14 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:25 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:38 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:44 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:07 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 00:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:51 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 06:15 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 06:25 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:43 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:55 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:52 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 00:40 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:46 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:22 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:31 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 22:27 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 09:36 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-21 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:24 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:07 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-16 18:35 -0800
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 04:08 +0000
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 23:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 20:29 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:26 +0300
Re: A defer mechanism for C fir <profesor.fir@gmail.com> - 2020-12-21 05:02 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 15:03 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 06:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 16:51 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:17 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:22 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:46 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:04 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 10:57 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:10 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 11:39 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:48 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:34 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:15 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:26 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:45 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 20:15 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:28 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 20:49 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:17 +0100
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-20 15:23 +0000 |
| Message-ID | <H%JDH.178562$oqF7.162236@fx32.ams4> |
| In reply to | #157504 |
On 20/12/2020 12:59, David Brown wrote: > On 19/12/2020 20:57, Bart wrote: >> If I run the binary trees benchmark: >> >> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html >> >> >> then a version using normal malloc/free, compiled with gcc-O3, runs at >> half the speed of my version using my own allocator. >> >> I don't know what malloc version gcc on Windows happens to use, but for >> this purpose, mine is faster. >> >> (Mine is a small-object allocator implemented on top of larger memory >> blocks obtained with any other allocator including malloc. It doesn't >> need to store the block size, which helps.) >> > > As seems to be the case so regularly, you don't know what you are doing > when compiling and linking (you are often even unsure what your own > home-made tools are doing), and yet you feel qualified to give opinions. > > There are many different ways to handle memory allocation, with > different pros and cons, strengths and weaknesses. There are many > different gcc builds for Windows, and many different C libraries that > can be used with them. > > So all you actually know from your benchmarking is that some things are > faster than others. Marvellous. That's usually the point of benchmarking... Here are the figures (best using optimisation where available): Using regular malloc/free: Pelles C 2.0 seconds all on Windows lccwin 2.2 DMC 2.2 gcc 3.2 bcc 3.7 tcc 3.8 gcc 3.9/1.7 on virtual Ubuntu Using my allocator: bb 1.4 seconds on Windows gcc 1.0 (via C) gcc 2.2/0.9 on virtual Ubuntu qq 7.2 seconds (dynamic bytecode) What can I conclude from those figures? According to you, absolutely nothing (never mind my allocator is up to 3 times as fast). I should abandon my allocator, just use malloc, and cross-my-fingers that whoever builds my programs happens to be using a decent C library. Personally I'd rather not have that special dependency coupled with such an unknown quantity. With my allocator, I can guarantee that performance. It DOESN'T MATTER what C library is used. (My gcc installation is only 750MB and 13,000 files; I guess they couldn't squeeze in a decent C library.) (Note that my allocators, going back forever, have never stored the size of an allocated block. That needs to be maintained by the application, and most of the time that is no problem. This will always give them an edge over any implementation of malloc that has a functional 'free' routine.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 17:48 +0100 |
| Message-ID | <rrnv8v$k6p$1@dont-email.me> |
| In reply to | #157506 |
On 20/12/2020 16:23, Bart wrote: > On 20/12/2020 12:59, David Brown wrote: >> On 19/12/2020 20:57, Bart wrote: > >>> If I run the binary trees benchmark: >>> >>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html >>> >>> >>> >>> then a version using normal malloc/free, compiled with gcc-O3, runs at >>> half the speed of my version using my own allocator. >>> >>> I don't know what malloc version gcc on Windows happens to use, but for >>> this purpose, mine is faster. >>> >>> (Mine is a small-object allocator implemented on top of larger memory >>> blocks obtained with any other allocator including malloc. It doesn't >>> need to store the block size, which helps.) >>> >> >> As seems to be the case so regularly, you don't know what you are doing >> when compiling and linking (you are often even unsure what your own >> home-made tools are doing), and yet you feel qualified to give opinions. >> >> There are many different ways to handle memory allocation, with >> different pros and cons, strengths and weaknesses. There are many >> different gcc builds for Windows, and many different C libraries that >> can be used with them. >> >> So all you actually know from your benchmarking is that some things are >> faster than others. Marvellous. > > > > That's usually the point of benchmarking... If you don't know what you are comparing, then no - it is useless. So, what library are you using with gcc? If you don't know, you are wasting your time and everyone else's. The same applies to any other toolchains if they support different C libraries - because malloc/free are part of the library, not the compiler. The library makes a big difference, as can the way it is connected to the application (static or dynamic linking).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-20 17:21 +0000 |
| Message-ID | <HKLDH.253233$J736.180439@fx42.ams4> |
| In reply to | #157512 |
On 20/12/2020 16:48, David Brown wrote:
> On 20/12/2020 16:23, Bart wrote:
>> On 20/12/2020 12:59, David Brown wrote:
>>> On 19/12/2020 20:57, Bart wrote:
>>
>>>> If I run the binary trees benchmark:
>>>>
>>>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html
>>>>
>>>>
>>>>
>>>> then a version using normal malloc/free, compiled with gcc-O3, runs at
>>>> half the speed of my version using my own allocator.
>>>>
>>>> I don't know what malloc version gcc on Windows happens to use, but for
>>>> this purpose, mine is faster.
>>>>
>>>> (Mine is a small-object allocator implemented on top of larger memory
>>>> blocks obtained with any other allocator including malloc. It doesn't
>>>> need to store the block size, which helps.)
>>>>
>>>
>>> As seems to be the case so regularly, you don't know what you are doing
>>> when compiling and linking (you are often even unsure what your own
>>> home-made tools are doing), and yet you feel qualified to give opinions.
>>>
>>> There are many different ways to handle memory allocation, with
>>> different pros and cons, strengths and weaknesses. There are many
>>> different gcc builds for Windows, and many different C libraries that
>>> can be used with them.
>>>
>>> So all you actually know from your benchmarking is that some things are
>>> faster than others. Marvellous.
>>
>>
>>
>> That's usually the point of benchmarking...
>
> If you don't know what you are comparing, then no - it is useless.
>
> So, what library are you using with gcc? If you don't know, you are
> wasting your time and everyone else's.
How is that information supposed to help?
Don't forget I use multiple different C implementations. Anyone building
my programs could be doing so with myriad C implementations.
What exactly am I supposed to do about that? I really don't care and
don't want to care about what's going on on the other side of a C compiler.
I just ensure my applications don't have such a dependency.
All the tests I've done on implementations available to me, show that
malloc is slower FOR MY PURPOSES than my own library.
==================
But here is a version of the BINARY benchmark that you can try for
yourself, or BM can try it with 'mimalloc' plugged in.
With USEMALLOC defined as 1, it will use normal malloc/free.
With USEMALLOC defined as 0, it will use a dedicated local allocator
(since it knows that every allocation will be of exactly the same size).
For the N used here (16), it will normally do about 30M mallocs and 30M
frees. With USEMALLOC set to 0, it will only do about 250K mallocs and
no frees.
I get runtimes with gcc-O3 of 3.2 seconds with normal malloc; and 0.8
seconds with the dedicated allocator. That's about 4:1. With other C
compilers, it goes down to roughly 2:1 (they have trouble matching gcc's
0.8 seconds).
I would be interested if knowing the exact version of your library lets
you get a closer ratio than the 2:1.
Remember my own more general purpose allocator managed 1.0 seconds,
about 1.25:1.
-------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#define USEMALLOC 1
//#define USEMALLOC 0
void** freelist;
typedef struct _node {
struct _node *left;
struct _node *right;
int item;
} treenode;
#if USEMALLOC
void* localalloc(void) {
return malloc(sizeof(treenode));
}
void localfree(void* p){
free(p);
}
#else
void* localalloc(void) {
void* p;
if (freelist) {
p=freelist;
freelist=(void**)*freelist;
return p;
}
return malloc(sizeof(treenode));
}
void localfree(void* p){
*(void**)p = freelist;
freelist=(void**)p;
}
#endif
treenode* newtreenode(treenode* left, treenode* right, int item) {
treenode* t;
t=localalloc();
t->left=left;
t->right=right;
t->item=item;
return t;
}
int itemcheck(treenode* tree) {
if (tree->left==NULL)
return tree->item;
else
return tree->item+itemcheck(tree->left)-itemcheck(tree->right);
}
treenode* bottomuptree(int item, int depth) {
if (depth>0)
return newtreenode(bottomuptree(2*item-1,depth-1),
bottomuptree(2*item,depth-1),item);
else
return newtreenode(NULL,NULL,item);
}
void deletetree(treenode* tree) {
if (tree->left) {
deletetree(tree->left);
deletetree(tree->right);
}
localfree(tree);
}
int main(void) {
treenode *stretchtree, *longlivedtree, *temptree;
int n,depth,mindepth,maxdepth,stretchdepth,check,iterations,i;
n=16;
mindepth=4;
if ((mindepth+2)>n)
maxdepth=mindepth+1;
else
maxdepth=n;
stretchdepth=maxdepth+1;
stretchtree=bottomuptree(0,stretchdepth);
printf("Stretch tree of depth %d check: %d\n", stretchdepth,
itemcheck(stretchtree));
deletetree(stretchtree);
longlivedtree=bottomuptree(0,maxdepth);
depth=mindepth;
while (depth<=maxdepth) {
iterations=1<<(maxdepth-depth+mindepth);
check=0;
for (i=1; i<=iterations; ++i) {
temptree=bottomuptree(i,depth);
check=check+itemcheck(temptree);
deletetree(temptree);
temptree=bottomuptree(-i,depth);
check=check+itemcheck(temptree);
deletetree(temptree);
}
printf("%d Trees of depth %d check: %d\n", iterations*2,
depth, check);
depth=depth+2;
}
printf("%s %d %s %d\n", "long lived tree of depth", maxdepth,
"\tcheck:", itemcheck(longlivedtree));
}
-------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 18:48 +0100 |
| Message-ID | <rro2pp$g28$1@dont-email.me> |
| In reply to | #157514 |
On 20/12/2020 18:21, Bart wrote: > On 20/12/2020 16:48, David Brown wrote: >> On 20/12/2020 16:23, Bart wrote: >>> On 20/12/2020 12:59, David Brown wrote: >>>> On 19/12/2020 20:57, Bart wrote: >>> >>>>> If I run the binary trees benchmark: >>>>> >>>>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html >>>>> >>>>> >>>>> >>>>> >>>>> then a version using normal malloc/free, compiled with gcc-O3, runs at >>>>> half the speed of my version using my own allocator. >>>>> >>>>> I don't know what malloc version gcc on Windows happens to use, but >>>>> for >>>>> this purpose, mine is faster. >>>>> >>>>> (Mine is a small-object allocator implemented on top of larger memory >>>>> blocks obtained with any other allocator including malloc. It doesn't >>>>> need to store the block size, which helps.) >>>>> >>>> >>>> As seems to be the case so regularly, you don't know what you are doing >>>> when compiling and linking (you are often even unsure what your own >>>> home-made tools are doing), and yet you feel qualified to give >>>> opinions. >>>> >>>> There are many different ways to handle memory allocation, with >>>> different pros and cons, strengths and weaknesses. There are many >>>> different gcc builds for Windows, and many different C libraries that >>>> can be used with them. >>>> >>>> So all you actually know from your benchmarking is that some things are >>>> faster than others. Marvellous. >>> >>> >>> >>> That's usually the point of benchmarking... >> >> If you don't know what you are comparing, then no - it is useless. >> >> So, what library are you using with gcc? If you don't know, you are >> wasting your time and everyone else's. > > How is that information supposed to help? > > Don't forget I use multiple different C implementations. Anyone building > my programs could be doing so with myriad C implementations. > If a benchmark is to be meaningful, you need to know what you are testing. Otherwise it is useless. It's /that/ simple. Would you publish a set of benchmarks showing: Dell 3.0 IBM 2.5 HP 4.5 and say that HP computers are nearly twice as fast as IBM computers? That's the level of information you are giving here. (And showing the program you used would be interesting additional information - but only in addition to the actual important information.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-20 20:13 +0000 |
| Message-ID | <YfODH.1160738$ckra.653986@fx37.ams4> |
| In reply to | #157521 |
On 20/12/2020 17:48, David Brown wrote: > On 20/12/2020 18:21, Bart wrote: >> How is that information supposed to help? >> >> Don't forget I use multiple different C implementations. Anyone building >> my programs could be doing so with myriad C implementations. >> > > If a benchmark is to be meaningful, you need to know what you are > testing. Otherwise it is useless. It's /that/ simple. > > Would you publish a set of benchmarks showing: > > Dell 3.0 > IBM 2.5 > HP 4.5 > > and say that HP computers are nearly twice as fast as IBM computers? > That's the level of information you are giving here. (And showing the > program you used would be interesting additional information - but only > in addition to the actual important information.) This is the EXACT purpose of the Binary Trees benchmark - a program which does nothing but allocate and deallocate a fixed-size struct, but in a pattern that cannot be optimised away. This is similar to the Fibonacci benchmark which does nothing except lots and lots of calls. Although listed on the Shootout benchmark page** as a language test, it is really a test of the language's allocator function, or rather of its implementation. My original response was to a remark that said you shouldn't implement malloc yourself. (Which I haven't done, but my own allocator is on top of malloc, which handles the larger blocks.) I still maintain an interpreter which is brisker than most, and one reason is that I pay attention to benchmarks like this. (But also, I don't /want/ an allocator which needs to store extra info of at least 8 bytes even for small blocks.) BTW how do you get with on that Binary Trees benchmark I posted? Have you found any library that comes close to the version using the local free-list?) (** https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-20 17:37 +0000 |
| Message-ID | <PZLDH.171218$xGx7.158093@fx38.ams4> |
| In reply to | #157512 |
On 20/12/2020 16:48, David Brown wrote: > On 20/12/2020 16:23, Bart wrote: >> That's usually the point of benchmarking... > > If you don't know what you are comparing, then no - it is useless. > > So, what library are you using with gcc? If you don't know, you are > wasting your time and everyone else's. The same applies to any other > toolchains if they support different C libraries - because malloc/free > are part of the library, not the compiler. The library makes a big > difference, as can the way it is connected to the application (static or > dynamic linking). > BTW the way I normally use malloc is by dynamic linking, because I call it via a FFI. Then any comparisons /have/ to be the same way. On Windows, the C libraries used from my languages are: M: msvcrt.dll C: msvcrt.dll (bcc) Q: msvcrt.dll via LoadLibrary/GetProcAddress Q: libc.so.6 (Linux) via dlopen/dlsym What other compilers use, how should /I/ know? I just download the bundle. In the case of my C compiler bcc, then 'bcc -info' mentions msvcrt.dll. Other compilers tend not to say.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-24 16:26 -0800 |
| Message-ID | <86ft3uybl9.fsf@linuxsc.com> |
| In reply to | #157506 |
Bart <bc@freeuk.com> writes: > On 20/12/2020 12:59, David Brown wrote: > >> On 19/12/2020 20:57, Bart wrote: >> >>> If I run the binary trees benchmark: >>> >>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html >>> >>> >>> then a version using normal malloc/free, compiled with gcc-O3, runs at >>> half the speed of my version using my own allocator. >>> >>> I don't know what malloc version gcc on Windows happens to use, but for >>> this purpose, mine is faster. >>> >>> (Mine is a small-object allocator implemented on top of larger memory >>> blocks obtained with any other allocator including malloc. It doesn't >>> need to store the block size, which helps.) >> >> As seems to be the case so regularly, you don't know what you are doing >> when compiling and linking (you are often even unsure what your own >> home-made tools are doing), and yet you feel qualified to give opinions. >> >> There are many different ways to handle memory allocation, with >> different pros and cons, strengths and weaknesses. There are many >> different gcc builds for Windows, and many different C libraries that >> can be used with them. >> >> So all you actually know from your benchmarking is that some things are >> faster than others. Marvellous. > > That's usually the point of benchmarking... > > > Here are the figures (best using optimisation where available): > > Using regular malloc/free: > > Pelles C 2.0 seconds all on Windows > lccwin 2.2 > DMC 2.2 > gcc 3.2 > bcc 3.7 > tcc 3.8 > > gcc 3.9/1.7 on virtual Ubuntu > > > Using my allocator: > > bb 1.4 seconds on Windows > gcc 1.0 (via C) > > gcc 2.2/0.9 on virtual Ubuntu > > qq 7.2 seconds (dynamic bytecode) > > > What can I conclude from those figures? According to you, absolutely > nothing (never mind my allocator is up to 3 times as fast). > > I should abandon my allocator, just use malloc, and cross-my-fingers > that whoever builds my programs happens to be using a decent C > library. > > Personally I'd rather not have that special dependency coupled with > such an unknown quantity. With my allocator, I can guarantee that > performance. It DOESN'T MATTER what C library is used. > > (My gcc installation is only 750MB and 13,000 files; I guess they > couldn't squeeze in a decent C library.) > > > (Note that my allocators, going back forever, have never stored the > size of an allocated block. That needs to be maintained by the > application, [...] So the results you reported are actually apples-and-oranges comparisons, and the main conclusion is that it isn't meaningful to compare them.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-25 00:55 +0000 |
| Message-ID | <2MaFH.376220$GyS9.180483@fx04.ams4> |
| In reply to | #157717 |
On 25/12/2020 00:26, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: >> (Note that my allocators, going back forever, have never stored the >> size of an allocated block. That needs to be maintained by the >> application, [...] > > So the results you reported are actually apples-and-oranges > comparisons, and the main conclusion is that it isn't > meaningful to compare them. I'm not comparing malloc to malloc. I comparing a more streamlined allocator to malloc. While still general purpose, it can't be a drop-in replacement for malloc/free (although it can be just for malloc). The tests showed that using it instead of malloc were highly beneficial in the case of that benchmark, and could useful within applications too. How much of the improvement is due to not having to record the block size, I don't know. I've never been a fan of the way malloc/free works, but unfortunately you can't turn off the behaviour. Having to provide a size parameter to free is a minor imposition, as the size is something a program can easily keep track of.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-19 12:10 -0800 |
| Message-ID | <4053f2c2-aa28-4909-8e26-595ff8643558n@googlegroups.com> |
| In reply to | #157489 |
On Saturday, 19 December 2020 at 19:41:51 UTC, Bonita Montero wrote: > > I implemented malloc() and a colleague implemented trig functions for it, > > so yes, it was pretty bare bones. ... > > Don't implement malloc() yourself, there are others which have done > a lot of research on that and which did it better. There are extremly > fast malloc()-implementations like mimalloc from Microsoft Relsearch > which is currently the fastest implementation. > It's 18 C source files. Whilst I'm sure it's faster and more efficient in memory usage than a simple single file roll your own of the sort I provided, these things have to be significant in terms of the programming goals before you can justify incorporating something like that in your codebase.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 13:56 +0100 |
| Message-ID | <rrnhl3$npl$1@dont-email.me> |
| In reply to | #157489 |
On 19/12/2020 20:41, Bonita Montero wrote: >> I implemented malloc() and a colleague implemented trig functions for it, >> so yes, it was pretty bare bones. ... > > Don't implement malloc() yourself, there are others which have done > a lot of research on that and which did it better. There are extremly > fast malloc()-implementations like mimalloc from Microsoft Relsearch > which is currently the fastest implementation. There is no such thing as "the fastest" malloc - nor "the best" malloc. Requirements for memory allocators varies enormously from system to system - what works well on PC-style hardware would be totally inappropriate on a small embedded system such as the one Malcolm is talking about.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-20 14:01 +0100 |
| Message-ID | <rrnhvo$q3v$1@dont-email.me> |
| In reply to | #157503 |
> There is no such thing as "the fastest" malloc - nor "the best" malloc. mimalloc has proven to be the fastest malloc-implementation for applications with a lot of small allocations up to 8kB. > Requirements for memory allocators varies enormously from system to > system - what works well on PC-style hardware would be totally > inappropriate on a small embedded system such as the one Malcolm is > talking about. mimalloc might be inappropriate in some cases because the pools for objects are rounded up to 2^N bytes up to 8kB, so this means it wastes a bit of space.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 16:32 +0100 |
| Message-ID | <rrnqq2$lns$1@dont-email.me> |
| In reply to | #157505 |
On 20/12/2020 14:01, Bonita Montero wrote: >> There is no such thing as "the fastest" malloc - nor "the best" malloc. > > mimalloc has proven to be the fastest malloc-implementation > for applications with a lot of small allocations up to 8kB. > >> Requirements for memory allocators varies enormously from system to >> system - what works well on PC-style hardware would be totally >> inappropriate on a small embedded system such as the one Malcolm is >> talking about. > > mimalloc might be inappropriate in some cases because the pools for > objects are rounded up to 2^N bytes up to 8kB, so this means it wastes > a bit of space. /All/ general malloc systems waste space. As I said, there are all kinds of factors involved in the requirements you have, and the implementations. There cannot possibly be a "best" choice. I can guarantee, without any doubt whatsoever, that the fastest malloc implementation you will ever see is the algorithm used by FreeRTOS's "heap_1" allocator. It will easily beat MS's algorithm, regardless of the size of the blocks or the number of them, and it will not waste any space beyond what you might need for alignment. It will beat any size-specific pool-based system. However, it has one weakness - "free" is a no-op. There are many systems and programs for which that is absolutely fine - but also many for which it is absolutely useless. I have no idea whether Malcolm's allocator was any good, or whether Bart's allocator is any good. But I /do/ know that there are times where any given general purpose allocator is not the best choice.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-20 07:42 -0800 |
| Message-ID | <88521a9d-3f16-4f42-b677-89a7badce702n@googlegroups.com> |
| In reply to | #157507 |
On Sunday, 20 December 2020 at 15:32:33 UTC, David Brown wrote: > > I have no idea whether Malcolm's allocator was any good, or whether > Bart's allocator is any good. But I /do/ know that there are times > where any given general purpose allocator is not the best choice. > The game shipped, and I never had any complaints about malloc() performance from other programmers on the project. However if programmers knew that malloc() was so fast as to be essentially free, they might write code in a better, more structured way than if they have to regard malloc() as a relatively costly operation. It was just a simple linked free list allocator with a single pool. Nothing special.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-20 16:07 +0000 |
| Message-ID | <tFKDH.276082$bG69.254959@fx23.ams4> |
| In reply to | #157508 |
On 20/12/2020 15:42, Malcolm McLean wrote: > On Sunday, 20 December 2020 at 15:32:33 UTC, David Brown wrote: >> >> I have no idea whether Malcolm's allocator was any good, or whether >> Bart's allocator is any good. But I /do/ know that there are times >> where any given general purpose allocator is not the best choice. >> > The game shipped, and I never had any complaints about malloc() > performance from other programmers on the project. However if > programmers knew that malloc() was so fast as to be essentially free, > they might write code in a better, more structured way than if they > have to regard malloc() as a relatively costly operation. > > It was just a simple linked free list allocator with a single pool. Nothing > special. > I remember (this must have been 30 years ago) going to a lot more effort in my allocator, which was mostly used for the large numbers of small, transient allocations involved in running an interpreter. Block sizes were any multiple of 16 bytes (eg. 80 bytes), and I kept a bitmap of the allocated blocks, 1 bit per 16 bytes, which allowed me to combine, say, unused blocks of 32 and 16 bytes, into one of 48 bytes. I then disabled the bitmap (so that with fragmentation, those 48 bytes could not be used for a 48-byte block, only 32- and 16-byte ones) to see what would happen. And nothing did! It made no difference to the interpreter, and I can't even remember if it needed more memory overall (there wasn't much free then inside 640KB). I haven't bothered with anything complicated since. Now my small blocks are 7 power-of-two sizes from 16 to 1024 bytes, and each has a dedicated free-list. Bigger ones just use regular malloc, but I request a power-of-two capacity (up to a certain threshold) so certain objects can grow without needing to deal with reallocation at every step. The trouble with malloc is that even if you request a size which is a multiple of 4KB (which would tidily be a whole number of virtual memory pages), then because it needs to store the size, a 4096-byte request needs 4100 or 4104 or 4112 bytes, no longer quite as tidy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 18:38 +0100 |
| Message-ID | <rro266$bk7$1@dont-email.me> |
| In reply to | #157509 |
On 20/12/2020 17:07, Bart wrote: > On 20/12/2020 15:42, Malcolm McLean wrote: >> On Sunday, 20 December 2020 at 15:32:33 UTC, David Brown wrote: >>> >>> I have no idea whether Malcolm's allocator was any good, or whether >>> Bart's allocator is any good. But I /do/ know that there are times >>> where any given general purpose allocator is not the best choice. >>> >> The game shipped, and I never had any complaints about malloc() >> performance from other programmers on the project. However if >> programmers knew that malloc() was so fast as to be essentially free, >> they might write code in a better, more structured way than if they >> have to regard malloc() as a relatively costly operation. >> >> It was just a simple linked free list allocator with a single pool. >> Nothing >> special. >> > > > I remember (this must have been 30 years ago) going to a lot more effort > in my allocator, which was mostly used for the large numbers of small, > transient allocations involved in running an interpreter. > > Block sizes were any multiple of 16 bytes (eg. 80 bytes), and I kept a > bitmap of the allocated blocks, 1 bit per 16 bytes, which allowed me to > combine, say, unused blocks of 32 and 16 bytes, into one of 48 bytes. > > I then disabled the bitmap (so that with fragmentation, those 48 bytes > could not be used for a 48-byte block, only 32- and 16-byte ones) to see > what would happen. > > And nothing did! It made no difference to the interpreter, and I can't > even remember if it needed more memory overall (there wasn't much free > then inside 640KB). > > I haven't bothered with anything complicated since. Now my small blocks > are 7 power-of-two sizes from 16 to 1024 bytes, and each has a dedicated > free-list. > > Bigger ones just use regular malloc, but I request a power-of-two > capacity (up to a certain threshold) so certain objects can grow without > needing to deal with reallocation at every step. > > The trouble with malloc is that even if you request a size which is a > multiple of 4KB (which would tidily be a whole number of virtual memory > pages), then because it needs to store the size, a 4096-byte request > needs 4100 or 4104 or 4112 bytes, no longer quite as tidy. There are different ways to handle this. Allocations can be tracked in a list separate from the actual allocated memory. This avoids the issue you describe here, and can give more efficient allocation - but can mean less efficient deallocation. Pools can be used to get a similar effect. (On modern systems, it can make sense to improve the speed and especially the cache-friendliness of allocation at the expense of slower de-allocation, since that can be handled in a low-priority thread.) Personally, I think it is unfortunate that the standard C malloc/free system is based on an unsized "free" call. I suspect that in most cases where C code calls "free", the code knows the size of the allocated memory. And in the few cases it doesn't already know it, tracking the size along with the pointer would have been entirely feasible.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-20 17:25 +0100 |
| Message-ID | <rrntu4$bqg$1@dont-email.me> |
| In reply to | #157507 |
> /All/ general malloc systems waste space. I'm aware of that. But mimalloc bases on a number of other allocators and adds this 2^N thread-local pooling. > /All/ general malloc systems waste space. As I said, there are all > kinds of factors involved in the requirements you have, and the > implementations. There cannot possibly be a "best" choice. Look at the benchmarks of mimalloc. There's no benchmark where it is slower than others. > I can guarantee, without any doubt whatsoever, that the fastest malloc > implementation you will ever see is the algorithm used by FreeRTOS's > "heap_1" allocator. It will easily beat MS's algorithm, regardless of > the size of the blocks or the number of them, and it will not waste any > space beyond what you might need for alignment. It will beat any > size-specific pool-based system. However, it has one weakness - "free" > is a no-op. There's possibility that could make it slower when its allocation takes more time than allocating and freeing with another allocator. And free- ing is very fast on all allocators, so it's very likely that there will be an allocator that beats it.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-12-20 17:46 +0100 |
| Message-ID | <rrnv5e$14mi$1@gioia.aioe.org> |
| In reply to | #157510 |
>> I can guarantee, without any doubt whatsoever, that the fastest malloc >> implementation you will ever see is the algorithm used by FreeRTOS's >> "heap_1" allocator. It will easily beat MS's algorithm, regardless of >> the size of the blocks or the number of them, and it will not waste any >> space beyond what you might need for alignment. It will beat any >> size-specific pool-based system. However, it has one weakness - "free" >> is a no-op. Forget it, a malloc()-implementation without free isn't a malloc()-implementation.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-20 09:07 -0800 |
| Message-ID | <fd804e6a-58eb-4294-a3e4-391f4b8163f1n@googlegroups.com> |
| In reply to | #157511 |
On Sunday, 20 December 2020 at 16:46:55 UTC, Christian Hanné wrote: > >> I can guarantee, without any doubt whatsoever, that the fastest malloc > >> implementation you will ever see is the algorithm used by FreeRTOS's > >> "heap_1" allocator. It will easily beat MS's algorithm, regardless of > >> the size of the blocks or the number of them, and it will not waste any > >> space beyond what you might need for alignment. It will beat any > >> size-specific pool-based system. However, it has one weakness - "free" > >> is a no-op. > Forget it, a malloc()-implementation without free isn't a > malloc()-implementation. > Most dymanic allocations are in fact arranged in a stack. Allocation and free are in the same scope, and they are either nested or easy to make nested. So you can write a very fast and efficient allocator. However I must admit that I've never actually used such an allocator in a real project.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-20 18:43 +0100 |
| Message-ID | <rro2gt$dgj$1@dont-email.me> |
| In reply to | #157513 |
> Most dymanic allocations are in fact arranged in a stack. That's not really true. Only allocations to a size-class are handled with stack / linked list to preserve cache-locality.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 18:45 +0100 |
| Message-ID | <rro2j7$elg$1@dont-email.me> |
| In reply to | #157513 |
On 20/12/2020 18:07, Malcolm McLean wrote: > On Sunday, 20 December 2020 at 16:46:55 UTC, Christian Hanné wrote: >>>> I can guarantee, without any doubt whatsoever, that the fastest malloc >>>> implementation you will ever see is the algorithm used by FreeRTOS's >>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of >>>> the size of the blocks or the number of them, and it will not waste any >>>> space beyond what you might need for alignment. It will beat any >>>> size-specific pool-based system. However, it has one weakness - "free" >>>> is a no-op. >> Forget it, a malloc()-implementation without free isn't a >> malloc()-implementation. >> > Most dymanic allocations are in fact arranged in a stack. That is a very questionable assumption. > Allocation > and free are in the same scope, and they are either nested or easy > to make nested. > So you can write a very fast and efficient allocator. That would be a different kind of allocator - one for which free does something, and memory will be re-used, as long as freeing is done in the reverse order from malloc'ing. Such allocators are also found, and are also useful - they are a great deal more efficient than general malloc systems, while being a bit more flexible than the "free is a no-op" allocator I described. (The "free is a no-op" is faster and more memory efficient, however.) > However I must admit that I've never actually used such an allocator > in a real project. > I have. Yes, they are useful. They require more discipline from the programmer, but small-systems embedded programmers are used to having restrictions that are not found on big systems.
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web