Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63716 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2015-06-21 16:20 +0200 |
| Last post | 2015-06-22 03:25 -0500 |
| Articles | 20 on this page of 214 — 26 participants |
Back to article view | Back to comp.lang.c
More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 16:20 +0200
Re: More useful memory functions Reinhardt Behm <rbehm@hushmail.com> - 2015-06-21 22:31 +0800
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 16:35 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 13:20 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 22:52 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 14:43 -0700
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 17:50 -0400
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:21 +0200
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 18:39 -0400
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:44 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 16:00 -0700
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 21:03 +0000
Re: More useful memory functions Robert Wessel <robertwessel2@yahoo.com> - 2015-06-22 18:47 -0500
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 00:50 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 20:19 +1200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 01:46 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 21:07 +1200
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 10:22 +0100
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 21:27 +1200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-23 08:30 -0700
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 16:43 +0100
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 02:36 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 21:54 +1200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 05:38 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-24 09:03 +1200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 17:20 -0700
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 01:36 +0100
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 00:34 -0700
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 09:55 +0200
Re: More useful memory functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-23 08:35 +0000
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 11:32 +0200
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-24 09:51 +0000
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 17:03 -0700
Re: More useful memory functions gordonb.muhly@burditt.org (Gordon Burditt) - 2015-06-22 05:17 -0500
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-22 09:08 -0400
Re: Snipping attribution lines Noob <root@127.0.0.1> - 2015-06-23 22:20 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 16:57 -0700
Re: More useful memory functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-22 00:54 +0000
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 12:35 +0000
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 21:10 -0400
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 19:21 -0700
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 22:55 -0400
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 13:41 -0500
Re: More useful memory functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-22 05:01 +0000
Re: More useful memory functions Robert Wessel <robertwessel2@yahoo.com> - 2015-06-22 01:48 -0500
Re: More useful memory functions Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-06-23 00:06 +0000
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 23:42 -0500
Re: More useful memory functions Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-06-23 23:04 +0000
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 22:28 -0500
Re: More useful memory functions Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:23 +0000
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-23 09:53 -0400
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 08:34 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 10:38 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 11:09 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-22 07:47 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 16:49 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 17:43 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 17:47 +0200
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 20:42 +0000
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 18:10 -0500
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 10:52 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-22 09:16 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 09:38 +1200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-22 10:53 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 11:56 -0500
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-22 09:21 -0400
Re: More useful memory functions Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:32 +0000
Re: More useful memory functions Robert Wessel <robertwessel2@yahoo.com> - 2015-06-23 22:37 -0500
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 11:07 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 13:40 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 13:56 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 16:20 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 15:44 +0100
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 15:50 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 16:57 +0200
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 17:38 -0500
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 07:49 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 17:17 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 18:34 +0100
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 20:08 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 20:42 +0100
More useful memory functions asetofsymbols@gmail.com - 2015-06-21 07:43 -0700
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-21 17:25 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 10:06 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 21:46 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 14:26 -0700
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 13:17 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 22:55 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 14:45 -0700
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 15:14 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 09:44 -0500
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-21 19:18 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-21 23:42 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:33 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 08:42 +0200
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 08:23 -0500
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 21:45 +0200
Re: More useful memory functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 10:56 -0700
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-21 18:35 +0200
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-21 21:39 +0100
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:39 +0200
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 18:41 -0400
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:47 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 17:08 -0700
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 17:12 -0700
Re: More useful memory functions gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-22 00:58 +0000
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 21:02 +0000
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-23 20:56 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 21:17 +0200
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-23 21:58 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 22:06 +0200
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 21:21 +0100
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 22:48 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 23:17 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 23:25 +0200
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-24 00:35 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 00:39 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-23 15:37 -0700
Re: Microsoft C run-time Noob <root@127.0.0.1> - 2015-06-23 23:22 +0200
Re: Microsoft C run-time jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 23:27 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 13:42 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 19:00 -0500
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 01:52 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 22:25 -0500
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 09:53 +0100
Re: More useful memory functions gwowen <gwowen@gmail.com> - 2015-06-24 01:59 -0700
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 11:05 +0100
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 11:23 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 07:55 -0500
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-24 07:48 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 10:47 -0500
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-07-03 17:34 +0000
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-05 05:27 -0700
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 11:28 +0100
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 11:50 +0100
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 12:58 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 14:20 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-24 14:27 +0200
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 13:38 +0100
Re: More useful memory functions gwowen <gwowen@gmail.com> - 2015-06-24 08:16 -0700
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 16:57 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 13:47 +0100
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 14:48 +0100
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 18:45 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 14:12 -0500
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 17:12 +0200
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 10:27 -0500
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 14:41 +0100
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-24 07:53 -0700
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 16:17 +0100
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-24 08:34 -0700
Re: More useful memory functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:48 -0700
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 18:56 -0700
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-07-10 20:53 -0700
Re: More useful memory functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:52 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 10:31 -0500
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 14:15 +0200
Re: gcc FUD Noob <root@127.0.0.1> - 2015-06-25 09:57 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 11:34 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-25 13:11 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 12:38 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-25 16:13 +0200
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-25 09:49 -0700
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-25 11:32 -0500
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 18:37 +0100
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-25 19:56 +0100
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 20:33 +0100
Re: gcc FUD Siri Cruz <chine.bleu@yahoo.com> - 2015-06-25 12:46 -0700
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-26 13:08 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-26 13:22 +0100
Re: gcc FUD Keith Thompson <kst-u@mib.org> - 2015-06-25 11:57 -0700
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-25 16:32 -0500
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 23:11 +0100
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-25 20:09 -0500
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 10:15 +0200
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-26 01:54 -0700
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 11:17 +0200
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-26 13:36 +0100
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 17:45 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-26 09:28 -0500
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 17:48 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-26 11:30 -0500
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-27 09:00 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-27 11:08 -0500
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-28 18:07 +0100
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-28 22:26 -0500
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 09:49 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-29 09:05 -0500
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 16:54 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-29 12:39 -0500
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-26 14:05 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-27 11:40 +0100
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-27 16:33 +0100
Re: gcc FUD Keith Thompson <kst-u@mib.org> - 2015-06-27 12:24 -0700
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-27 22:37 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-27 22:31 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-28 00:47 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-28 11:28 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-28 14:00 +0200
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-28 05:44 -0700
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 13:47 +0100
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-28 05:55 -0700
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 18:42 +0100
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-29 07:27 +0200
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 10:17 +0200
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-29 11:05 +0200
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 11:34 +0200
Re: gcc FUD Robert Wessel <robertwessel2@yahoo.com> - 2015-06-28 02:14 -0500
Re: gcc FUD Ian Collins <ian-news@hotmail.com> - 2015-06-28 08:57 +1200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-26 10:18 +0100
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 11:26 +0200
Re: gcc FUD Paul <nospam@needed.com> - 2015-06-26 08:05 -0400
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-21 11:56 -0500
Re: More useful memory functions Gordon Burditt <gordon@hammy.burditt.org> - 2015-06-22 03:25 -0500
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 10:52 +0200 |
| Message-ID | <mmb6li$bl0$1@dont-email.me> |
| In reply to | #63822 |
On 22/06/15 17:47, jacobnavia wrote: > Le 22/06/2015 17:43, David Brown a écrit : >> Obviously no one is going to be using your tools for embedded >> development > > > My system has been used for an embedded TI 16 bit processor, and in > general I have several customers in that sector. > > But of course you know better than me who my customers are! > I had assumed your tools were Windows-only, as that is what appears from your website and all the posts I have read from you in this group. But if that is not the case, then I apologize for the incorrect assumption. I expect that the processor in question is the msp430. (Tell me if I am wrong here.) If you are able to say more about it (such as where it is used), please do so - I am curious. In most systems for the msp430, you would not want any sort of dynamic memory management. As an example of an exception when you would want it, an RTOS might use dynamic memory for allocating tasks and other objects. Here is some information about memory management on FreeRTOS, a popular embedded OS (with ports for the msp430 amongst others). In particular, one of the choices of implementation is exactly the one I gave earlier: <http://www.freertos.org/a00111.html#heap_1>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-22 09:16 -0700 |
| Message-ID | <4d558e3f-e9fd-4be9-ab42-13bc7eb4d794@googlegroups.com> |
| In reply to | #63820 |
On Monday, June 22, 2015 at 4:43:52 PM UTC+1, David Brown wrote: > > If you want to learn about how C is used in the world beyond > Windows, ask and we will be happy to tell you - don't claim to know it all. > Talking to the OS isn't the same as "programming". Every program has to talk to the OS in some shape or form to get its data in and its results out. But there's a large class of programs for which this is trivial, just a matter of loading an input file and saving out an output file. There's also a huge class of programs for which it's quite involved, but you don't want to do it in C. You want the logical core of the program in C, but not all the putting up of windows to display results and get options from the user. At the moment, for example, I'm welding together a variable offset algorithm written in C-like C++, with a GUI that allows the user to specify things like line caps and joining options, written in HTML and a javascript variant.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-23 09:38 +1200 |
| Message-ID | <curdi4F8qmtU1@mid.individual.net> |
| In reply to | #63828 |
Malcolm McLean wrote: > On Monday, June 22, 2015 at 4:43:52 PM UTC+1, David Brown wrote: >> >> If you want to learn about how C is used in the world beyond >> Windows, ask and we will be happy to tell you - don't claim to know it all. >> > Talking to the OS isn't the same as "programming". Every program has to talk to > the OS in some shape or form to get its data in and its results out. Except when there isn't one... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-22 10:53 +0100 |
| Message-ID | <mm8lso$qq0$1@dont-email.me> |
| In reply to | #63792 |
On 22/06/2015 09:38, jacobnavia wrote:
> Le 22/06/2015 08:34, David Brown a écrit :
>> void free(void* ptr) {
>> }
> This implementation allocates and never frees.
>
> GREAT!
>
>> I believe this is conforming - it is certainly a practical
>> implementation for some small embedded systems that find it convenient
>> to use dynamic memory allocation at startup, but never stop or free the
>> memory.
>>
>
> This is absolutely nonsense. Precisely in small systems managing a
> scarce resource like memory should be done with utmost care.
>
> Providing rubbish like that is worst than nothing.
This is practical for many kinds of applications where memory is kept is
kept in use until the program terminates. Free is not really needed.
On small systems, it saves the overheads involved with storing sizes and
managing the blocks.
On big systems it might not be needed because there is more memory than
you know what to do with. It can work. (And if it is known that free()
does nothing, you can make use of that information, by making your own
arrangements to minimise and re-use memory.)
(I recently implemented an allocator for a kind of object that relied on
garbage collection to recover space no longer in use, but I never got
round to doing the garbage collector. That was a couple of years ago and
it's never given any trouble!)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-22 11:56 -0500 |
| Message-ID | <mm9f0e$dhk$1@news.albasani.net> |
| In reply to | #63794 |
On 6/22/2015 4:53 AM, Bartc wrote:
> On 22/06/2015 09:38, jacobnavia wrote:
>> Le 22/06/2015 08:34, David Brown a écrit :
>
>>> void free(void* ptr) {
>>> }
>
>> This implementation allocates and never frees.
>>
>> GREAT!
>>
>>> I believe this is conforming - it is certainly a practical
>>> implementation for some small embedded systems that find it convenient
>>> to use dynamic memory allocation at startup, but never stop or free the
>>> memory.
>>>
>>
>> This is absolutely nonsense. Precisely in small systems managing a
>> scarce resource like memory should be done with utmost care.
>>
>> Providing rubbish like that is worst than nothing.
>
> This is practical for many kinds of applications where memory is kept is
> kept in use until the program terminates. Free is not really needed.
>
> On small systems, it saves the overheads involved with storing sizes and
> managing the blocks.
>
yeah. outside of PC uses, memory becomes complicated.
size constraints are one thing, can be severe in smaller MCUs (often
only a few kB or so).
alternatively, there may still memory, just not a huge amount of it, so
it makes sense to be conservative.
as for more MM features in the standard:
they could be nice, but granted, would likely be better off as an
optional feature, so implementations which can't reasonably implement
them would leave them out.
> On big systems it might not be needed because there is more memory than
> you know what to do with. It can work. (And if it is known that free()
> does nothing, you can make use of that information, by making your own
> arrangements to minimise and re-use memory.)
>
yes.
> (I recently implemented an allocator for a kind of object that relied on
> garbage collection to recover space no longer in use, but I never got
> round to doing the garbage collector. That was a couple of years ago and
> it's never given any trouble!)
>
this works, apart from those of us still doing 32-bit programs and
running them at the limits of the address space.
the issues of GC in such a use-case are still enough that I have mostly
ended up back-tracking some, and putting a lot more resources into a mix
of statically-bounded lifespans and manual memory management.
often it isn't necessarily "garbage" that is the problem, but rather the
program may itself use considerable amounts of data as working data, and
may need some sort of feedback to indicate that it may need to reduce
its working set.
there is a version of my script language I have recently started some
work on (I am calling it "BGBScript-RT", and it will use a different VM
backend than its parent language). (the existing language+VM is far too
big/bulky to really be viable on the target, nor was it designed with
timing-constraints in mind).
it will primarily use a mix of lifetime inference, defined lifespans in
the language semantics, manual new/delete, and RAII like patterns. a few
internal structures may be reference counted, but there will be no
global GC. likewise, the language will be primarily statically-typed
(and supports use of structs and raw pointers and similar).
some goals include:
predictable timing latencies (should at no point hold execution for more
than 1us, and the internal scheduler should at no point exceed a 10us
latency for event scheduling);
decent performance (a lot of the target HW is still in MHz territory);
conservative memory use (should not use significantly more memory than a
raw native-code C program);
...
basically, would be used on lower-stat ARM hardware in combination with
real-time motor control (well, in addition to me already running C in a
similar VM, likely the C variant and BS-RT will share the VM).
for now it will be interpreted, but AOT is likely as a later option.
conventional JIT isn't a great fit for the use-case (traditional JIT
tends to introduce lots of small unpredictable delays whenever the JIT
compiler runs). AOT has a potentially higher initial start-up cost, but
can avoid random delays during execution. precompiling to native code
prior to deployment is another option.
the high-level language will be multithreaded and support asynchronous
execution, however the underlying implementation will use a cooperative
threading model and work via trampoline loops.
I will see how much I can keep intact of high-level features, but there
will be some constraints, and some internal funkiness.
the language will still logically use 16-bit characters, but most likely
the underlying string storage for most strings will likely use Windows-1252.
the PC VM uses M-UTF-8, but as-is, this leads to an issue where fetching
characters by index involve walking the string. OTOH, 1252 uses 8-bit
characters, but will not be able to represent every possible string (but
should have pretty good coverage, and pretty much anything likely to be
used in the use-case).
generally, raw 16-bit strings are undesirable as they waste a lot of
memory (and in the vast majority of cases are unnecessary).
or such...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-22 09:21 -0400 |
| Message-ID | <mm921t$6hl$1@dont-email.me> |
| In reply to | #63787 |
On 06/22/2015 02:34 AM, David Brown wrote:
> On 21/06/15 23:43, Keith Thompson wrote:
...
>> Implementations of malloc can typically allocate more memory than was
>> asked for in the call. A conforming implementation needn't store the
>> requested size; it can store only the actual allocated size (since
>> there's currently no requirement to be able to retrieve either). I can
>> imagine implementations where neither size is stored explicitly (say, if
>> all allocations are managed in multiple linked lists, one for each
>> size).
>>
>> I'm not saying it would be a large burden, or even that I'd oppose
>> adding msize() to the standard, but it would be imposed on *all*
>> malloc() calls, whether the program calls msize() or not.
>>
>
> There are also systems that use minimal versions of malloc/free, for
> which something like msize() would be impossible or at least inefficient:
>
> #define heapSize 2048
> static union
> { unsigned long alignment; unsigned char heap[heapSize]; } heap;
> static unsigned char* topOfHeap = heap.heap;
>
> void* malloc(size_t size) {
> // Note - size or topOfHeap might need adjustment for alignment
> void* p = topOfHeap;
> topOfHeap += size;
> return p;
> }
>
> void free(void* ptr) {
> }
>
>
> I believe this is conforming - it is certainly a practical
This version of free() does not make the memory "available for further
allocation", as required by 7.22.3.3p2. However, since there's no
circumstance under which malloc() is ever required to succeed (not even
int main(void) { malloc(1); }), no strictly conforming program can be
used to prove that malloc() failed to reuse memory released by a call to
free(). So technically, this is covered by the as-if rule - but that is
precisely the "cheat" I referred to in my response to Keith in another
branch of this thread.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-06-23 13:32 +0000 |
| Message-ID | <slrnmoinut.1mn.nw@granicus.if.org> |
| In reply to | #63787 |
On 2015-06-22, David Brown <david.brown@hesbynett.no> wrote: > Implementing msize() would require storing the size of allocations > somewhere, which would be a waste of space for a fairly useless function > (since the function calling malloc() knows the size of the allocation, > and can store the information if you need it later). Further, while I haven't thought it through in detail, it seems like a user of malloc that wanted this could allocate enough space for a size_t in addition to the space wanted and store the size in the allocated space itself. In pseudocode: struct foo *f; f = malloc(sizeof *f + sizeof size_t); *(size_t *) f = sizeof *f; f += sizeof size_t; You'd need to think about alignment issues, and probably want to write a wrapper function. Is there a portable way to determine the maximum needed alignment? If not, you could probably write a portability header to specify it per system. Failing that, 16 bytes is probably pretty safe. -- nw
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-23 22:37 -0500 |
| Message-ID | <ga9koalfmsrev0r56pfg2db063pr06pvbm@4ax.com> |
| In reply to | #63920 |
On 23 Jun 2015 13:32:13 +0000, Nathan Wagner <nw@hydaspes.if.org> wrote: >On 2015-06-22, David Brown <david.brown@hesbynett.no> wrote: > >> Implementing msize() would require storing the size of allocations >> somewhere, which would be a waste of space for a fairly useless function >> (since the function calling malloc() knows the size of the allocation, >> and can store the information if you need it later). > >Further, while I haven't thought it through in detail, it seems like a >user of malloc that wanted this could allocate enough space for a size_t >in addition to the space wanted and store the size in the allocated >space itself. > >In pseudocode: > >struct foo *f; > >f = malloc(sizeof *f + sizeof size_t); >*(size_t *) f = sizeof *f; >f += sizeof size_t; > >You'd need to think about alignment issues, and probably want to write a >wrapper function. Is there a portable way to determine the maximum >needed alignment? If not, you could probably write a portability header >to specify it per system. Failing that, 16 bytes is probably pretty >safe. In C++11, "alignof(std::max_align_t)" comes close to telling you the worst case alignment requirements (that malloc would have to respect).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 11:07 +0100 |
| Message-ID | <mmbb33$ps8$1@dont-email.me> |
| In reply to | #63759 |
On 21/06/2015 22:43, Keith Thompson wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: >> I do not see how would it be so difficult to return the size of a memory >> block!!! > > Implementations of malloc can typically allocate more memory than was > asked for in the call. A conforming implementation needn't store the > requested size; it can store only the actual allocated size (since > there's currently no requirement to be able to retrieve either). I can > imagine implementations where neither size is stored explicitly (say, if > all allocations are managed in multiple linked lists, one for each > size). Before I started using the C library, I used memory allocation routines that didn't store the size of the allocation at all. It required that the corresponding free function supplied the size of the block that needed freeing (ie. the application had to keep track of the size). This worked extremely well for many years; after all most of the time, a program /will/ know the size of the block: for example, the size of a struct being freed, or the length of an array because you will have needed to know the length anyway. Actually I didn't understand why C wanted to make a rod for its own back, by making the library magically remember the size. This can require more memory and extra code to do so but usually the caller already knows it! (It also makes nice, round allocations such as 1024 bytes into odd-sized 1032 or 1040 byte ones in the process.) (I can't remember whether odd-sized requests were rounded up in my scheme. If so then the rounding method would be known, if the application needed to know the actual amount allocated. Now, I use an allocation system which is a thin wrapper on top of malloc and free, and the freeing routine still requires the size. Small blocks are allocated and freed very rapidly using a memory pool, larger ones call malloc and free directly but I do my own rounding up before calling malloc. If malloc rounds it further, then I don't care. free() of course doesn't need my size.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 13:40 +0200 |
| Message-ID | <mmbghp$d64$1@dont-email.me> |
| In reply to | #63904 |
On 23/06/15 12:07, Bartc wrote: > On 21/06/2015 22:43, Keith Thompson wrote: >> jacobnavia <jacob@jacob.remcomp.fr> writes: > >>> I do not see how would it be so difficult to return the size of a memory >>> block!!! >> >> Implementations of malloc can typically allocate more memory than was >> asked for in the call. A conforming implementation needn't store the >> requested size; it can store only the actual allocated size (since >> there's currently no requirement to be able to retrieve either). I can >> imagine implementations where neither size is stored explicitly (say, if >> all allocations are managed in multiple linked lists, one for each >> size). > > Before I started using the C library, I used memory allocation routines > that didn't store the size of the allocation at all. It required that > the corresponding free function supplied the size of the block that > needed freeing (ie. the application had to keep track of the size). > > This worked extremely well for many years; after all most of the time, a > program /will/ know the size of the block: for example, the size of a > struct being freed, or the length of an array because you will have > needed to know the length anyway. > > Actually I didn't understand why C wanted to make a rod for its own > back, by making the library magically remember the size. This can > require more memory and extra code to do so but usually the caller > already knows it! (It also makes nice, round allocations such as 1024 > bytes into odd-sized 1032 or 1040 byte ones in the process.) > > (I can't remember whether odd-sized requests were rounded up in my > scheme. If so then the rounding method would be known, if the > application needed to know the actual amount allocated. > > Now, I use an allocation system which is a thin wrapper on top of malloc > and free, and the freeing routine still requires the size. Small blocks > are allocated and freed very rapidly using a memory pool, larger ones > call malloc and free directly but I do my own rounding up before calling > malloc. If malloc rounds it further, then I don't care. free() of course > doesn't need my size.) > I would prefer free to require a size - it would make malloc/free more efficient, and generally I know what I am free'ing and thus the size needed for free(). I gather that C++14 now has a version of delete that is called with the size - by overriding the global new/delete operators, you could make your own heap management that took advantage of that.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 13:56 +0100 |
| Message-ID | <mmbl08$tgp$1@dont-email.me> |
| In reply to | #63904 |
On 23/06/2015 11:07, Bartc wrote:
> Before I started using the C library, I used memory allocation routines
> that didn't store the size of the allocation at all.
...
> Now, I use an allocation system which is a thin wrapper on top of malloc
> and free, and the freeing routine still requires the size.
Out of interest, I had another look at the 'binary trees' benchmark I
sometimes use. (C version here: http://pastebin.com/D7rniNds. Probably
some mods from the original.)
This seems to be heavily dependent on the quality of the malloc
implementation. Some quick timings under Windows (with N=15) are as follows:
32-bit 64-bit
gcc 1.85 - seconds
(gcc 0.8 - same machine under Ubuntu)
Pelles C 0.9 0.75
lcc-win 1.6 (error)
DMC 0.8 -
gcc/TDM - 1.0
Clang 1.95 -
B(1) - 1.25
B(2) - 0.25
B(3) 0.125 -
B is my own language and compiler targetting x64. (1) uses malloc/free
and is linked with gcc/TDM so presumably uses the same library.
(2) uses my own /general purpose/ allocator which runs on top of
malloc/free but does its own handling for small allocations.
The free routine requires the size to be given. I don't know how much
that helps achieve the speed, but it doesn't seem to hurt!
(3) is the same code and method as (2) but translated to C then compiled
with gcc/32-bit. This is 15 times as fast as using gcc/32 directly!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 16:20 +0200 |
| Message-ID | <mmbpt2$hji$1@dont-email.me> |
| In reply to | #63913 |
On 23/06/15 14:56, Bartc wrote: > On 23/06/2015 11:07, Bartc wrote: > >> Before I started using the C library, I used memory allocation routines >> that didn't store the size of the allocation at all. > ... >> Now, I use an allocation system which is a thin wrapper on top of malloc >> and free, and the freeing routine still requires the size. > > Out of interest, I had another look at the 'binary trees' benchmark I > sometimes use. (C version here: http://pastebin.com/D7rniNds. Probably > some mods from the original.) > > This seems to be heavily dependent on the quality of the malloc > implementation. Some quick timings under Windows (with N=15) are as > follows: > > 32-bit 64-bit > > gcc 1.85 - seconds > > (gcc 0.8 - same machine under Ubuntu) > > Pelles C 0.9 0.75 > > lcc-win 1.6 (error) > > DMC 0.8 - > > gcc/TDM - 1.0 > > Clang 1.95 - > > B(1) - 1.25 > > B(2) - 0.25 > > B(3) 0.125 - > > B is my own language and compiler targetting x64. (1) uses malloc/free > and is linked with gcc/TDM so presumably uses the same library. > > (2) uses my own /general purpose/ allocator which runs on top of > malloc/free but does its own handling for small allocations. > > The free routine requires the size to be given. I don't know how much > that helps achieve the speed, but it doesn't seem to hurt! > > (3) is the same code and method as (2) but translated to C then compiled > with gcc/32-bit. This is 15 times as fast as using gcc/32 directly! > Your gcc (and others) numbers are meaningless without noting the version of gcc and the compile flags (at least the basic -O setting). A brief test on my machine (64-bit Linux, i7-920) gives: gcc 4.9, -O0 : 0.632s gcc 4.9, -O1 : 0.529s gcc 4.9, -O2 : 0.489s gcc 4.9, -O3 : 0.443s Running on the same machine, but using "-m32" for 32-bit code gives: gcc 4.9, -m32 -O0 : 0.740s gcc 4.9, -m32 -O1 : 0.621s gcc 4.9, -m32 -O2 : 0.589s gcc 4.9, -m32 -O3 : 0.497s Replacing malloc/free with a static block of memory (512 MB) with malloc giving the next chunk and free doing nothing reduces the time to about 0.230s - much of that is, I think, cache thrashing as without re-use of memory, we can't make much use of the processor's cache. It is not hard to imagine that a more specialised malloc/free could do a lot better.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 15:44 +0100 |
| Message-ID | <mmbrai$nia$1@dont-email.me> |
| In reply to | #63927 |
On 23/06/2015 15:20, David Brown wrote: > On 23/06/15 14:56, Bartc wrote: >> Out of interest, I had another look at the 'binary trees' benchmark I >> sometimes use. (C version here: http://pastebin.com/D7rniNds. Probably >> some mods from the original.) >> >> This seems to be heavily dependent on the quality of the malloc >> implementation. Some quick timings under Windows (with N=15) are as >> follows: >> >> 32-bit 64-bit >> >> gcc 1.85 - seconds >> >> (gcc 0.8 - same machine under Ubuntu) ... > Your gcc (and others) numbers are meaningless without noting the version > of gcc and the compile flags (at least the basic -O setting). Sorry, they all use maximum speed optimisation (and gcc was 4.8.1). But it's the difference in malloc implementations that is of interest. I have to say that I've no idea what runtime library gcc uses. From past experience, it might even be an MS library. (I don't know how to control this aspect, which is odd considering how critical the choice can be.) A brief > test on my machine (64-bit Linux, i7-920) gives: > > gcc 4.9, -O0 : 0.632s > gcc 4.9, -O1 : 0.529s > gcc 4.9, -O2 : 0.489s > gcc 4.9, -O3 : 0.443s > > Running on the same machine, but using "-m32" for 32-bit code gives: > > gcc 4.9, -m32 -O0 : 0.740s > gcc 4.9, -m32 -O1 : 0.621s > gcc 4.9, -m32 -O2 : 0.589s > gcc 4.9, -m32 -O3 : 0.497s > > Replacing malloc/free with a static block of memory (512 MB) with malloc > giving the next chunk and free doing nothing reduces the time to about > 0.230s - much of that is, I think, cache thrashing as without re-use of > memory, we can't make much use of the processor's cache. It is not hard > to imagine that a more specialised malloc/free could do a lot better. But all my tests were with general purpose allocation/deallocation routines where the latter actually freed memory. Yes there are very fast ways of writing dedicated code for particular applications (based around a linked list of free nodes for example), but all the above either used malloc/free or drop-in replacements for malloc/free. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 15:50 +0100 |
| Message-ID | <mmbrkg$nia$3@dont-email.me> |
| In reply to | #63936 |
On 23/06/2015 15:44, Bartc wrote: > But all my tests were with general purpose allocation/deallocation > routines where the latter actually freed memory. Yes there are very fast > ways of writing dedicated code for particular applications (based around > a linked list of free nodes for example), but all the above either used > malloc/free or drop-in replacements for malloc/free. Well, almost drop-in: the free() replacement needs a size argument, which in this benchmark is easily available. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 16:57 +0200 |
| Message-ID | <mmbs2o$qq5$1@dont-email.me> |
| In reply to | #63936 |
On 23/06/15 16:44, Bartc wrote: > On 23/06/2015 15:20, David Brown wrote: >> On 23/06/15 14:56, Bartc wrote: > >>> Out of interest, I had another look at the 'binary trees' benchmark I >>> sometimes use. (C version here: http://pastebin.com/D7rniNds. Probably >>> some mods from the original.) >>> >>> This seems to be heavily dependent on the quality of the malloc >>> implementation. Some quick timings under Windows (with N=15) are as >>> follows: >>> >>> 32-bit 64-bit >>> >>> gcc 1.85 - seconds >>> >>> (gcc 0.8 - same machine under Ubuntu) > ... > > >> Your gcc (and others) numbers are meaningless without noting the version >> of gcc and the compile flags (at least the basic -O setting). > > Sorry, they all use maximum speed optimisation (and gcc was 4.8.1). But > it's the difference in malloc implementations that is of interest. I > have to say that I've no idea what runtime library gcc uses. From past > experience, it might even be an MS library. (I don't know how to control > this aspect, which is odd considering how critical the choice can be.) On linux, gcc normally uses glibc. On Windows, mingw uses MS's C runtime library dll, while mingw-64 (32-bit or 64-bit) uses (I think) glibc. mingw's use of the MS C library is one of its biggest disadvantages - the library is slow, the dll interface makes it slower, and it doesn't support anything beyond C90. This is probably the reason your gcc version was so much slower on Windows than on Linux. > > A brief >> test on my machine (64-bit Linux, i7-920) gives: >> >> gcc 4.9, -O0 : 0.632s >> gcc 4.9, -O1 : 0.529s >> gcc 4.9, -O2 : 0.489s >> gcc 4.9, -O3 : 0.443s >> >> Running on the same machine, but using "-m32" for 32-bit code gives: >> >> gcc 4.9, -m32 -O0 : 0.740s >> gcc 4.9, -m32 -O1 : 0.621s >> gcc 4.9, -m32 -O2 : 0.589s >> gcc 4.9, -m32 -O3 : 0.497s >> >> Replacing malloc/free with a static block of memory (512 MB) with malloc >> giving the next chunk and free doing nothing reduces the time to about >> 0.230s - much of that is, I think, cache thrashing as without re-use of >> memory, we can't make much use of the processor's cache. It is not hard >> to imagine that a more specialised malloc/free could do a lot better. > > But all my tests were with general purpose allocation/deallocation > routines where the latter actually freed memory. Yes there are very fast > ways of writing dedicated code for particular applications (based around > a linked list of free nodes for example), but all the above either used > malloc/free or drop-in replacements for malloc/free. > Yes, I know - I was just giving some other ideas for comparison.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-23 17:38 -0500 |
| Message-ID | <mmcnd1$q32$1@news.albasani.net> |
| In reply to | #63944 |
On 6/23/2015 9:57 AM, David Brown wrote: > On 23/06/15 16:44, Bartc wrote: >> On 23/06/2015 15:20, David Brown wrote: >>> On 23/06/15 14:56, Bartc wrote: >> >>>> Out of interest, I had another look at the 'binary trees' benchmark I >>>> sometimes use. (C version here: http://pastebin.com/D7rniNds. Probably >>>> some mods from the original.) >>>> >>>> This seems to be heavily dependent on the quality of the malloc >>>> implementation. Some quick timings under Windows (with N=15) are as >>>> follows: >>>> >>>> 32-bit 64-bit >>>> >>>> gcc 1.85 - seconds >>>> >>>> (gcc 0.8 - same machine under Ubuntu) >> ... >> >> >>> Your gcc (and others) numbers are meaningless without noting the version >>> of gcc and the compile flags (at least the basic -O setting). >> >> Sorry, they all use maximum speed optimisation (and gcc was 4.8.1). But >> it's the difference in malloc implementations that is of interest. I >> have to say that I've no idea what runtime library gcc uses. From past >> experience, it might even be an MS library. (I don't know how to control >> this aspect, which is odd considering how critical the choice can be.) > > On linux, gcc normally uses glibc. On Windows, mingw uses MS's C > runtime library dll, while mingw-64 (32-bit or 64-bit) uses (I think) > glibc. mingw's use of the MS C library is one of its biggest > disadvantages - the library is slow, the dll interface makes it slower, > and it doesn't support anything beyond C90. This is probably the reason > your gcc version was so much slower on Windows than on Linux. > yes, MS's 'malloc()' is one of the "sucks real hard" varieties: it is slow, with an additional slowness proportional to the total number of allocations; allocating memory from one DLL and trying to free in another is prone to cause crashes (with MSVC); there is considerable storage overhead (lots of small allocations eats huge amounts of memory); ... custom allocators can be both faster and also have a lot less allocation overhead.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 07:49 -0700 |
| Message-ID | <26c838a2-0a36-4c88-8f8d-b7767e8908b9@googlegroups.com> |
| In reply to | #63913 |
On Tuesday, June 23, 2015 at 1:57:10 PM UTC+1, Bart wrote: > > Clang 1.95 - > > B(1) - 1.25 > > B(2) - 0.25 > > B(3) 0.125 - > > B is my own language and compiler targetting x64. (1) uses malloc/free > and is linked with gcc/TDM so presumably uses the same library. > > (2) uses my own /general purpose/ allocator which runs on top of > malloc/free but does its own handling for small allocations. > > The free routine requires the size to be given. I don't know how much > that helps achieve the speed, but it doesn't seem to hurt! > > (3) is the same code and method as (2) but translated to C then compiled > with gcc/32-bit. This is 15 times as fast as using gcc/32 directly! > You can write an extremely fast small fixed size block allocator that simply creates a linked list of blocks, with the next pointer begin at the top of the block itself. When you allocate, you simply take the top of the list, and reset your first pointer. To free, put the block back on the top, setting its next pinter to the first pointer and resetting the first pointer. So two memory writes to free, one to allocate. C malloc() can't easily use that algorithm. But if you are building a structure consisting of many identical sized nodes, then it is attractive, and of course if memory allocation is your bottleneck, you'll get a large speed-up. However generally graph operations spend their time walking the graph, not creating and deleting nodes. So whilst you get a bit of a speed up, it's not a game changer.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-23 17:17 +0200 |
| Message-ID | <mmbt6u$bu$1@dont-email.me> |
| In reply to | #63913 |
Le 23/06/2015 14:56, Bartc a écrit : > lcc-win 1.6 (error) This is NOT TRUE. I downloaded the code in question in the file bm.c I used the 64 bit compiler. Here is the transcript of the compiling session: d:\tmp>lc64 -O bm.c d:\tmp>timethis bm TimeThis : Command Line : bm TimeThis : Start Time : Tue Jun 23 17:10:42 2015 stretch tree of depth 16 check: -1 65536 trees of depth 4 check: -65536 16384 trees of depth 6 check: -16384 4096 trees of depth 8 check: -4096 1024 trees of depth 10 check: -1024 256 trees of depth 12 check: -256 64 trees of depth 14 check: -64 long lived tree of depth 15 check: -1 TimeThis : Command Line : bm TimeThis : Start Time : Tue Jun 23 17:10:42 2015 TimeThis : End Time : Tue Jun 23 17:10:43 2015 TimeThis : Elapsed Time : 00:00:00.670 d:\tmp>gcc -O2 bm.c d:\tmp>timethis a.exe TimeThis : Command Line : a.exe TimeThis : Start Time : Tue Jun 23 17:12:29 2015 stretch tree of depth 16 check: -1 65536 trees of depth 4 check: -65536 16384 trees of depth 6 check: -16384 4096 trees of depth 8 check: -4096 1024 trees of depth 10 check: -1024 256 trees of depth 12 check: -256 64 trees of depth 14 check: -64 long lived tree of depth 15 check: -1 TimeThis : Command Line : a.exe TimeThis : Start Time : Tue Jun 23 17:12:29 2015 TimeThis : End Time : Tue Jun 23 17:12:30 2015 TimeThis : Elapsed Time : 00:00:00.624 lcc-win has almost the same speed as gcc in this benchmark!
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 18:34 +0100 |
| Message-ID | <mmc580$3rb$1@dont-email.me> |
| In reply to | #63950 |
On 23/06/2015 16:17, jacobnavia wrote: > Le 23/06/2015 14:56, Bartc a écrit : >> lcc-win 1.6 (error) > > This is NOT TRUE. lcc-win64 crashed running the benchmark. This was a version downloaded today. It seems to be to do with the pow() line to calculate number of iterations. The line can be replied with this (which is what I use elsewhere): iterations = 1<<(maxDepth - depth + minDepth); Then, runtime is better than 1.2 seconds on my machine. (I thought it was 0.12 seconds for a minute, then realised that in 64-bit mode, clock() returns a different sized unit, I think 100ths of second instead of milliseconds.) (That pow() expression is a crazy way to work out the iteration, however it should still work.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-23 20:08 +0200 |
| Message-ID | <mmc782$c4t$1@dont-email.me> |
| In reply to | #63966 |
Le 23/06/2015 19:34, Bartc a écrit : > On 23/06/2015 16:17, jacobnavia wrote: >> Le 23/06/2015 14:56, Bartc a écrit : >>> lcc-win 1.6 (error) >> >> This is NOT TRUE. > > lcc-win64 crashed running the benchmark. This was a version downloaded > today. > > It seems to be to do with the pow() line to calculate number of iterations. > > The line can be replied with this (which is what I use elsewhere): > > iterations = 1<<(maxDepth - depth + minDepth); > > Then, runtime is better than 1.2 seconds on my machine. (I thought it > was 0.12 seconds for a minute, then realised that in 64-bit mode, > clock() returns a different sized unit, I think 100ths of second instead > of milliseconds.) > > (That pow() expression is a crazy way to work out the iteration, however > it should still work.) > Hi Bart Please send me some reproducible problem... You know I will fix it :-) The pow() function crashes???
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web