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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 12:38 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmgp4t$ev0$1@dont-email.me> |
| In reply to | #64117 |
On 25/06/2015 12:11, David Brown wrote: > On 25/06/15 12:34, Bartc wrote: > >> I've just download the gcc sources again (it only took ten minutes to >> locate them because the links kept going around in circles, like >> everything to do with gcc on the web). >> >> The sources are 94,000 files and directories. 80,000 files in 14,000 >> directories, which are astronomical figures. >> > > Something like 50K of these files are in the test suite. How > comprehensive is /your/ automatic test suite? That's beside the point. I don't want to run the test suite. Many just want to download the sources because there isn't a ready-made executable, or they fancy tweaking it (fat chance) then they're faced with all this. > And remember, the sources support some 30-odd targets and a range of > languages (C, C++, Objective C, Objective C++, Java, Go, Fortran, Ada). I was only disputing the claim that it wasn't complex. I think it is. (Even if it might be dwarfed by the apparent 1.5 million source files of MS' Visual Studio iirc. I wander how many targets /that/ supports?) > The sizes here are big - gcc is not a small or simple project by any > reckoning. But comparing it to your compiler is not just an > apples-to-oranges comparison, it is a an apples to a farming community > comparison. It shows what is possible. I'm not saying real compiler systems need to be that small, but some of them certainly seem to have got out of hand. The trouble is that if no one ever makes an objection but just accepts things, always justifying the size complexity because it's got a test suite, or it supports this or that or whatever, then how do you know that it doesn't actually contain a lot of bloat? Maybe you could have a perfectly valid test suite in only 10,000 files. Or 1000. Perhaps supporting 100 different targets might only require 100N extra files, with N being a small number (in my case N is 4). With the installations, gcc does seems to include a lot of third party headers and libraries, but then it omits a C runtime library! (Apparently using the MS library under Windows). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-25 16:13 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmh271$g5u$1@dont-email.me> |
| In reply to | #64118 |
On 25/06/15 13:38, Bartc wrote: > On 25/06/2015 12:11, David Brown wrote: >> On 25/06/15 12:34, Bartc wrote: >> >>> I've just download the gcc sources again (it only took ten minutes to >>> locate them because the links kept going around in circles, like >>> everything to do with gcc on the web). >>> >>> The sources are 94,000 files and directories. 80,000 files in 14,000 >>> directories, which are astronomical figures. >>> >> >> Something like 50K of these files are in the test suite. How >> comprehensive is /your/ automatic test suite? > > That's beside the point. I don't want to run the test suite. Many just > want to download the sources because there isn't a ready-made > executable, or they fancy tweaking it (fat chance) then they're faced > with all this. The number of source files doesn't really matter when you are compiling - if you have not enabled building the test suite, or supporting Fortran, then those source files do no harm. And if you want to do some tweaking, then it is probably not hard to narrow it down to a directory or two of files that might interest you - but of course you still have a challenge finding what you want in there! > >> And remember, the sources support some 30-odd targets and a range of >> languages (C, C++, Objective C, Objective C++, Java, Go, Fortran, Ada). > > I was only disputing the claim that it wasn't complex. > I don't think anyone claimed that gcc isn't complex. People merely objected to your characterisation of it as unnecessarily big and complex with "astronomical" size, especially compared to small compilers like yours or lcc-win. gcc /is/ big and complex, but there is a lot involved in it. > I think it is. (Even if it might be dwarfed by the apparent 1.5 million > source files of MS' Visual Studio iirc. I wander how many targets /that/ > supports?) It supports a few - Windows 32-bit, Windows 64-bit, dotnet, etc. But I doubt if that justifies quite that many source files! > >> The sizes here are big - gcc is not a small or simple project by any >> reckoning. But comparing it to your compiler is not just an >> apples-to-oranges comparison, it is a an apples to a farming community >> comparison. > > It shows what is possible. I'm not saying real compiler systems need to > be that small, but some of them certainly seem to have got out of hand. I don't disagree that gcc probably has a good deal more files than might be necessary - it is a project that has grown over many years, and it is easier to accumulate bulk than for someone to say "lets re-organise /everything/ for the next version!". I haven't looked at the source code for clang/llvm, but I would expect it to be clearer and more compact than gcc, since it is a much younger project. > > The trouble is that if no one ever makes an objection but just accepts > things, always justifying the size complexity because it's got a test > suite, or it supports this or that or whatever, then how do you know > that it doesn't actually contain a lot of bloat? Projects like that are well beyond the understanding of any individual. Bloat is almost inevitable, because it is usually more efficient to build on what you have than remove code and restructure. Fixing bugs, adding features, improving code generation, and developer time efficiency are far more important priorities than reducing the size of the code or number of files. It only makes sense to reduce bloat or code size if it is an investment in long-term maintenance improvements. For comparison, look at the Linux kernel. The sources have grown enormously over the years as new features, ports and drivers abound - but many changes are actually to remove outdated or unneeded source code, or to make the source smaller and clearer, as well as to make the resulting build smaller. That is because for the kernel, reducing source code (if it is clearly no longer needed by /anyone/) is one of the aims of the development. > > Maybe you could have a perfectly valid test suite in only 10,000 files. > Or 1000. Perhaps supporting 100 different targets might only require > 100N extra files, with N being a small number (in my case N is 4). > > With the installations, gcc does seems to include a lot of third party > headers and libraries, but then it omits a C runtime library! > (Apparently using the MS library under Windows). > That varies quite a lot between targets. And many of the libraries installed by gcc itself are from the same people (GNU), even if they are developed separately from the compiler. But packages of pre-built gcc along with additional libraries, headers and utilities are common - you cannot blame gcc alone for the other parts of the toolchain.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-25 09:49 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <498a4bd7-1ab3-495f-871a-f2c69ccac55a@googlegroups.com> |
| In reply to | #64124 |
On Thursday, June 25, 2015 at 3:13:15 PM UTC+1, David Brown wrote: > > Projects like that [gcc] are well beyond the understanding of any individual. > Bloat is almost inevitable, > That's because people don't understand the costs of bloat. Disk space is essentially free, memory is not usually a restricting resource at compile time, and compilation time, though an issue, isn't a game changer. So it's easy to add feature after feature. But the result is that if something goes wrong, it's impossible to fix it, unless you're a developer on the project yourself. And even then it can be very hard. All you need is for one file to contain some obscure bit of syntax that isn't supported correctly, either breaking on your machine or incorrectly doing the "right" thing on the author's machine, and you are in deep trouble. Supporting a large range of languages also encourages the use of those languages, and thus bloat and complexity in user code. Almost every algorithm can be specified easily and simply in ANSI C, and compiled with a good complier that runs in a few kilobytes of executable. That's how it should be done, then you can spend your time programming new algorithms rather than endlessly recasting old code to work in new environments.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-25 11:32 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmhamd$kth$1@news.albasani.net> |
| In reply to | #64113 |
On 6/25/2015 5:34 AM, Bartc wrote:
> On 25/06/2015 08:57, Noob wrote:
>> On 24/06/2015 10:53, Bartc wrote:
>>
>>>>> gcc is a monster that keeps getting bigger - and slower. I'm not
>>>>> surprised that hundreds of people are needed to keep feeding it.
>>
>> [ Typical barely accurate FUD and half-truths ]
>
>>
>> Did you ever consider that it is getting bigger because...
>>
>> 1) it supports an increasing number of platforms (mostly embedded)
>> 2) it supports an increasing number of sophisticated optimization passes
>> 3) some languages such as C++ are constantly evolving, and compilers
>> have to support language standards for decades
>
> I have two Windows gcc installations: mingw/32-bit (as I found it
> impossible to install mingw-w64), and TDM/64-bit.
>
> The installation of TDM comprises 6100 files and directories, about 375MB.
>
> The installation of mingw has 14000 files and directories, some 1200MB.
>
> Wow! But I've just realised TDM is short by 8000 files. I haven't missed
> them so far but should I be worried about it? But if I can lose 8000
> files and something still works, how many of the remaining 6000 are
> actually needed?
>
> Is it possible that my Windows installation include support for dozens
> of different targets? That would be crazy if it was the case.
>
> (My own compiler comprises about a dozen files in one directory, and
> comes to 0.3MB. However it uses a 3rd party assembler and linker,
> otherwise it might be 1 more file (the compiler would generate object
> code directly) and be big enough to fill a third of a floppy disk.)
>
my C compiler:
about 80kLOC at present.
front-end parsers:
C / C-Aux, partial C++ parsing (lacks things like templates, ...)
Java and C# (unmaintained, conjoined parser)
an earlier BGBScript2 effort (also conjoined into same parser)
BS2 would have basically been Java-like.
newer BGBScript-RT effort (about 20kLOC of the above)
output:
RPNIL (an older stack-based IL, used a textual representation)
was loosely akin to Forth or PostScript, just nastier.
FRBC2C (newer 3-address-code bytecode format)
some complexity exists due to trying to gloss over
sizeof(void*) and sizeof(long) and similar.
bytecode should be word-size neutral.
doesn't support 8/16 bits, partly as sizeof(int) is currently fixed.
other features:
creation of metadata databases (for FFI uses)
metadata is represented as a heirarchical database.
dealing with ExWAD packaging
this is a WAD-based format used for resources and bytecode.
loosely related to Quake's WAD2 format.
in concept similar to Doom's WAD files.
also loosely similar in concept to 'ar' files.
also supports hierarchies and an escape-case for long names.
also supports Deflate and Deflate64 compression.
'GAST', which was an attempt at a language-neutral binary AST format.
loosely related in concept to WebAssembly.
was more-or-less useless in my use-cases.
ASTs don't also really gloss over language semantics that well.
ASTs as S-Expressions would may have been better.
typically, it has used external code to execute or produce native code.
for FRBC2C, this means an external VM backend.
in the past, an RPNIL backend existed which converted this to native code.
it can be used either as a tool or as a library, but has mostly ended up
used as a tool.
if it were stripped down to just C, and maybe a codegen and
assembler/linker were added built-in, who knows?...
current estimate is somewhere around 120-160 kLOC.
>> Slower. Slower how? At what setting? Could you /be/ more vague?
>
> Execution speed (of the compiler) is not that terrible, however it is
> decidedly sluggish. Other C compilers are up to 4 times as fast; Clang
> however was 40% slower than gcc!
>
> (On my machine gcc compiles at around 3000 lines per second on one test
> compiling a dozen files.
>
> My own compiler runs at about 5000 lines/second, but is hampered (1) by
> using a slow external assembler (Nasm); (2) by /being interpreted/!)
>
> This is with gcc -O0; at -03, gcc reduces to 2000 lines per second.)
>
not formally tested, but general experience implies that more modern
versions (say, 4.x) of GCC are a fair bit slower than 2.x versions (ex:
2.8 or 2.95).
what evidence I can find was that there was a considerable drop in GCC
compiler speeds around the transition from the 2.x to 3.x lines, but
don't know how 3.x compares with present.
do know that compiling on lower-stat MHz class hardware, modern GCC is
unbearably slow, whereas 2.x is a lot more useable.
one partial reason for my using MS's compiler on Windows, is mostly how
much faster it is compared with GCC. it is basically enough to offset
the lack of C99 features.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 18:37 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmhe6h$m5$1@dont-email.me> |
| In reply to | #64134 |
On 25/06/2015 17:32, BGB wrote: > On 6/25/2015 5:34 AM, Bartc wrote: >> (On my machine gcc compiles at around 3000 lines per second on one test >> compiling a dozen files. >> >> My own compiler runs at about 5000 lines/second, but is hampered (1) by >> using a slow external assembler (Nasm); (2) by /being interpreted/!) >> >> This is with gcc -O0; at -03, gcc reduces to 2000 lines per second.) >> > > not formally tested, but general experience implies that more modern > versions (say, 4.x) of GCC are a fair bit slower than 2.x versions (ex: > 2.8 or 2.95). > > what evidence I can find was that there was a considerable drop in GCC > compiler speeds around the transition from the 2.x to 3.x lines, but > don't know how 3.x compares with present. > > do know that compiling on lower-stat MHz class hardware, modern GCC is > unbearably slow, whereas 2.x is a lot more useable. > > > one partial reason for my using MS's compiler on Windows, is mostly how > much faster it is compared with GCC. it is basically enough to offset > the lack of C99 features. Yes, I think I will make an effort to make my generated C code more acceptable to other, snappier C compilers. That means dropping or disabling label pointers to make it possible. Because, first thing in the morning especially, you can count to 10 while waiting for gcc to compile even Hello World! It would be nice to remove the dependency on gcc (but I might still to rely on gcc/TDM's 64-bit linker when generating x64 code directly; others seem to give problems). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-25 19:56 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <87a8vnvcq6.fsf@bsb.me.uk> |
| In reply to | #64149 |
Bartc <bc@freeuk.com> writes: <snip> > Because, first thing in the morning especially, you can count to 10 > while waiting for gcc to compile even Hello World! I suspect that's a Windows thing: $ time gcc -std=c11 -o arith arith.c gcc -std=c11 -o arith arith.c 0.01s user 0.02s system 80% cpu 0.035 total $ wc -l arith.c 44 arith.c (unless your machine is very old, maybe.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 20:33 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmhkvd$s8l$1@dont-email.me> |
| In reply to | #64162 |
On 25/06/2015 19:56, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: > <snip> >> Because, first thing in the morning especially, you can count to 10 >> while waiting for gcc to compile even Hello World! > > I suspect that's a Windows thing: > > $ time gcc -std=c11 -o arith arith.c > gcc -std=c11 -o arith arith.c 0.01s user 0.02s system 80% cpu 0.035 total > $ wc -l arith.c > 44 arith.c > > (unless your machine is very old, maybe.) Maybe the 10 seconds is exaggerated or it was another C program that was being compiled (sometimes I can zip through a compile-all on non-C sources, then it come to a halt for a few seconds, and it will be the one C module that is the cause). However, compiling Hello World does take 4-5 seconds first thing after a full reset, 1.5 seconds after turning on from hibernation, then it consistently takes 0.5 seconds (from command line and using -c switch). That is with Mingw/gcc under Windows. gcc/TDM under Windows is double the speed, while lccwin32 is faster still (at this point you stop noticing). I don't think it's an anti-virus thing (as I turned it off for the test). gcc under Ubuntu is fine, and I get similar timings to yours. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruz <chine.bleu@yahoo.com> |
|---|---|
| Date | 2015-06-25 12:46 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <chine.bleu-21BD51.12460625062015@88-209-239-213.giganet.hu> |
| In reply to | #64168 |
In article <mmhkvd$s8l$1@dont-email.me>, Bartc <bc@freeuk.com> wrote: > However, compiling Hello World does take 4-5 seconds first thing after a > full reset, 1.5 seconds after turning on from hibernation, then it > consistently takes 0.5 seconds (from command line and using -c switch). That means it has to do with virtual memory, not the program itself. It means it take about four and half seconds to allocate page frames, read in from executable, possibly allocate writable pages to backing store, and only then transfer control to the executable. All runtime initialisation (which would be one visible sign of bloat) occurs within that 0.5 run time. The total size of the executable shouldn't have much effect on the initial VM allocation unless the kernel is doing a horrible guess of the initial working set. That would still be a VM problem, not an executable problem. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' When is a Kenyan not a Kenyan? When he's a Canadian. That's People's Commissioner Siri Cruz now. Punch!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-26 13:08 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjbos$1ik$1@dont-email.me> |
| In reply to | #64168 |
On 25/06/15 21:33, Bartc wrote: > On 25/06/2015 19:56, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: >> <snip> >>> Because, first thing in the morning especially, you can count to 10 >>> while waiting for gcc to compile even Hello World! >> >> I suspect that's a Windows thing: >> >> $ time gcc -std=c11 -o arith arith.c >> gcc -std=c11 -o arith arith.c 0.01s user 0.02s system 80% cpu 0.035 >> total >> $ wc -l arith.c >> 44 arith.c >> >> (unless your machine is very old, maybe.) > > Maybe the 10 seconds is exaggerated or it was another C program that was > being compiled (sometimes I can zip through a compile-all on non-C > sources, then it come to a halt for a few seconds, and it will be the > one C module that is the cause). > > However, compiling Hello World does take 4-5 seconds first thing after a > full reset, 1.5 seconds after turning on from hibernation, then it > consistently takes 0.5 seconds (from command line and using -c switch). > > That is with Mingw/gcc under Windows. gcc/TDM under Windows is double > the speed, while lccwin32 is faster still (at this point you stop > noticing). I don't think it's an anti-virus thing (as I turned it off > for the test). gcc under Ubuntu is fine, and I get similar timings to > yours. > Compiling a "hello world" C program on Windows, with gcc 4.9 from mingw-w64 (the installation of which was not remotely difficult) takes 0.07s total time on my Windows machine. There is no doubt that gcc is a relatively slow compiler, especially compared to clang or to simpler tools. But it is not nearly as slow as you are making out. Compilation (with any tools) is always slower on Windows than Linux when you are dealing with larger projects, since Windows is much poorer at dealing quickly with files or with multiple processes, and particularly bad at dealing with lots of files in use by lots of parallel processes (assuming a "make -j" build). I have measured the difference to be a factor of about 2 on similar hardware (using a CodeWarrior compiler).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-26 13:22 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjg40$gnj$1@dont-email.me> |
| In reply to | #64211 |
On 26/06/2015 12:08, David Brown wrote:
> On 25/06/15 21:33, Bartc wrote:
>> However, compiling Hello World does take 4-5 seconds first thing after a
>> full reset, 1.5 seconds after turning on from hibernation, then it
>> consistently takes 0.5 seconds (from command line and using -c switch).
> There is no doubt that gcc is a relatively slow compiler, especially
> compared to clang or to simpler tools. But it is not nearly as slow as
> you are making out.
The 8-9 seconds it sometimes takes is only sometimes. Maybe it's AV
related, or some complicated system thing going on. But that's how long
it can take.
> Compilation (with any tools) is always slower on Windows than Linux when
> you are dealing with larger projects, since Windows is much poorer at
> dealing quickly with files or with multiple processes, and particularly
> bad at dealing with lots of files in use by lots of parallel processes
> (assuming a "make -j" build). I have measured the difference to be a
> factor of about 2 on similar hardware (using a CodeWarrior compiler).
I've done a test using a batch file containing 100 command-line
invocations of each compiler (compiling to .obj file only) to compile
classic Hello World. The results are these:
Mingw 32-bit: 24 seconds
gcc/TDM 64-bit: 9 seconds
Clang 32-bit: 8 seconds
lccwin 32-bit: 2 seconds
(Mine 64:bit: 2 seconds **)
These were with AV turned off (otherwise Clang was taking 35 seconds).
(** My compiler generated .asm not .obj, but arguably generating text
can take longer especially with the long qualified names I used. But
also, I believe that my compiler is the only one running interpreted
bytecode, so that's a pretty good result considering.)
> Compiling a "hello world" C program on Windows, with gcc 4.9 from
> mingw-w64 (the installation of which was not remotely difficult)
I've tried it again. This time I managed to get past the repository
error that made it crash out last time.
But looking inside the installed directory, instead of bin, there's a
further subdirectory called mingw32, which doesn't bode well. Working
inside mingw3\bin I try and compile test.c (to print the size of a
pointer), and it says: error: CreateProcess: etc.
Investigating further, if I do: set path=, so losing *all* existing
search paths, it will run. Now the test program says the pointer size is
4 bytes.
I now compile again using the -m64 switch. Now it says:
test.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
#include <stdio.h>
^
I try installing again. There are a list of options: Version 5.1.0,
Architecture i686, Threads posix, Exception dwarf, Building revision 0,
the sort of stuff that usually make your eyes glaze over, and I click on
i686. *Now* it gives a choice of i686/x86-64!
The 64-bit capability must be the biggest single reason why anyone would
bother to download (it's called "*W64"), yet they hide it away in little
sub-option, *and* they make it default to 32-bit mode!
Anyway it now reports pointer sizes are 8, but it still doesn't like my
path set up.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-25 11:57 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <lnioabhayx.fsf@kst-u.example.com> |
| In reply to | #64149 |
Bartc <bc@freeuk.com> writes:
[...]
> Because, first thing in the morning especially, you can count to 10
> while waiting for gcc to compile even Hello World!
Perhaps you have a slow computer, or you count quickly?
"gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast
machine. Running it again took 0.024 seconds, probably because of
caching effects.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-25 16:32 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmhs80$b4t$1@news.albasani.net> |
| In reply to | #64163 |
On 6/25/2015 1:57 PM, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] >> Because, first thing in the morning especially, you can count to 10 >> while waiting for gcc to compile even Hello World! > > Perhaps you have a slow computer, or you count quickly? > > "gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast > machine. Running it again took 0.024 seconds, probably because of > caching effects. > IME, my issue isn't with small pieces of code, but rather with larger pieces of code. compiling around 100 kLOC on my PC (3.4GHz K10 running Win7) takes about 18 seconds with MSVC, and about 2 minutes with GCC. likewise, a clean rebuild of a 1 MLOC program takes about 3 minutes with MSVC, and about 20 minutes with GCC. if recompiling something on a 700 MHz system (on Linux), a 100 kKLOC library takes around an hour or so to recompile. as for Linux vs Windows, I have noticed that on Linux (in VMware), GCC on Linux seems to go a bit faster than building on Windows. timing building a small program (single source file tool, after 3 runs): MSVC(18.0): 0.202s MinGW(4.5.2): 0.605s Cygwin(4.5.3): 2.210s Linux (4.8.2): 0.236s testing a slightly larger piece of code (single C file with large amounts of macro expansions, *): MSVC: 2.320s MinGW: 2m37s Cygwin: 2m45s Linux: 7m10s *: basically, code for calling functions with a number of potential argument lists. macros are used to generate the various possible argument lists (ILFDP for up to 5 args). IOW: a big function-call dispatcher.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 23:11 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmhu8g$3i3$1@dont-email.me> |
| In reply to | #64180 |
On 25/06/2015 22:32, BGB wrote: > On 6/25/2015 1:57 PM, Keith Thompson wrote: >> "gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast >> machine. Running it again took 0.024 seconds, probably because of >> caching effects. >> > > IME, my issue isn't with small pieces of code, but rather with larger > pieces of code. > > compiling around 100 kLOC on my PC (3.4GHz K10 running Win7) takes about > 18 seconds with MSVC, and about 2 minutes with GCC. 800 lines/second with gcc. Not far off the 2000 lines I was getting with -O3, so this might be about right, if the code is challenging (or denser etc). > likewise, a clean rebuild of a 1 MLOC program takes about 3 minutes with > MSVC, and about 20 minutes with GCC. > > if recompiling something on a 700 MHz system (on Linux), a 100 kKLOC > library takes around an hour or so to recompile. 28 lines/second? ro expansions, *): > MSVC: 2.320s > MinGW: 2m37s > Cygwin: 2m45s And gcc is here over 60 times slower. Something is badly wrong! This just makes me want to dash off my own C compiler just to see how fast *I* can make it. But delving into all that yucky syntax puts me off. Then there's the preprocessor. And the code generator. And object files. And the runtime library. Maybe I'll think about it... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-25 20:09 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmi908$sj2$1@news.albasani.net> |
| In reply to | #64186 |
On 6/25/2015 5:11 PM, Bartc wrote:
> On 25/06/2015 22:32, BGB wrote:
>> On 6/25/2015 1:57 PM, Keith Thompson wrote:
>
>>> "gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast
>>> machine. Running it again took 0.024 seconds, probably because of
>>> caching effects.
>>>
>>
>> IME, my issue isn't with small pieces of code, but rather with larger
>> pieces of code.
>>
>> compiling around 100 kLOC on my PC (3.4GHz K10 running Win7) takes about
>> 18 seconds with MSVC, and about 2 minutes with GCC.
>
> 800 lines/second with gcc. Not far off the 2000 lines I was getting with
> -O3, so this might be about right, if the code is challenging (or denser
> etc).
>
most of this was code with considerable amounts of arithmetic and
pointer operations, namely signal-processing code.
>> likewise, a clean rebuild of a 1 MLOC program takes about 3 minutes with
>> MSVC, and about 20 minutes with GCC.
>>
>> if recompiling something on a 700 MHz system (on Linux), a 100 kKLOC
>> library takes around an hour or so to recompile.
>
> 28 lines/second?
>
yeah, it is pretty slow...
testing my own compiler with the small tool: 0.370s
> ro expansions, *):
>> MSVC: 2.320s
>> MinGW: 2m37s
>> Cygwin: 2m45s
>
> And gcc is here over 60 times slower. Something is badly wrong!
>
it is possible the code steps on an adverse situation for GCC.
the generated code mostly consists of large amounts of generated
single-line functions, and some very large switch blocks.
curious was in this case, Linux got the worst performance, whereas in
most other cases it was faster than the Windows run.
testing with my compiler, this code causes the compiler to crash in the
preprocessor (with a corrupted stack). need to investigate, I suspect
buffer overruns.
looking: yep, macro-expansion was producing large (64-100kB or more)
outputs (one macro call may expand to a large amount of output). a
better solution would be to dynamically expand the buffer (as-is,
fixed-size buffers are used, I just kicked them up to around 1MB...).
compiler execution time: around 6 seconds (4s in PP, 2s in parse/compile).
so, yeah, it appears as if the code steps on an evil case in terms of
GCC's performance.
> This just makes me want to dash off my own C compiler just to see how
> fast *I* can make it. But delving into all that yucky syntax puts me
> off. Then there's the preprocessor. And the code generator. And object
> files. And the runtime library. Maybe I'll think about it...
>
yeah. I have wondered as well. my C compiler isn't exactly all that
fast, and a lot of the code is really nasty.
when I first wrote it, it took about 6 months of effort before I really
had it compiling anything. granted, I had little idea what I was doing
at the time, and threw together something which was unusably slow,
unreliable, and basically an abomination of code.
then it spent years relegated to being a simple tool, but has been
resurrected recently for sake of the FRVM/C-Aux thing.
but, it actually goes acceptably fast considering it is internally built
around a mockup of XML/DOM and long winding messes of:
if(!strcmp(...)) { ... }
if(!strcmp(...)) { ... }
if(!strcmp(...)) { ... }
...
OTOH, off in the FRVM backend, I am off looking into a mechanism to
intern strings in a way where I can quickly do relative comparisons
without needing to use "strcmp()", mostly for efficiently performing
operations on small in-memory B-Trees (and for other reasons need the
ability to keep the trees in lexicographic order).
the mechanism would allow for fairly fast relative comparisons at the
cost of a fairly high cost for interning new strings (namely O(n^2), in
particular, it is essentially insertion-sort, mapping each string to a
number representing its current ranking).
likewise, sadly, a presorted string table isn't really an option in this
case (will not know the set of symbols in advance).
the other option is, of course, good old strcmp...
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-26 10:15 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmj1ll$hua$1@speranza.aioe.org> |
| In reply to | #64188 |
>> ro expansions, *): >>> MSVC: 2.320s >>> MinGW: 2m37s >>> Cygwin: 2m45s >> >> And gcc is here over 60 times slower. Something is badly wrong! >> > > it is possible the code steps on an adverse situation for GCC. > > the generated code mostly consists of large amounts of generated > single-line functions, and some very large switch blocks. > > curious was in this case, Linux got the worst performance, whereas in > most other cases it was faster than the Windows run. > > > testing with my compiler, this code causes the compiler to crash in the > preprocessor (with a corrupted stack). need to investigate, I suspect > buffer overruns. > > looking: yep, macro-expansion was producing large (64-100kB or more) > outputs (one macro call may expand to a large amount of output). a > better solution would be to dynamically expand the buffer (as-is, > fixed-size buffers are used, I just kicked them up to around 1MB...). > > compiler execution time: around 6 seconds (4s in PP, 2s in parse/compile). > > > so, yeah, it appears as if the code steps on an evil case in terms of > GCC's performance. If it is a bug and not a result of your code, have you reported it? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-26 01:54 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <b57e20b0-8b67-4022-8ffd-b7412501a1a0@googlegroups.com> |
| In reply to | #64196 |
On Friday, June 26, 2015 at 9:14:59 AM UTC+1, Morten W. Petersen wrote: > > > so, yeah, it appears as if the code steps on an evil case in terms of > > GCC's performance. > > If it is a bug and not a result of your code, have you reported it? > Its a bug for a compiler to crash on any input. However with highly nested macros which expand to huge quantities of text, it is hardly surprising. Attempting to process can produce a slowdown which, in practice, is worse than a crash.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-26 11:17 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmj59c$qn6$1@speranza.aioe.org> |
| In reply to | #64198 |
On 26.06.2015 10:54, Malcolm McLean wrote: > On Friday, June 26, 2015 at 9:14:59 AM UTC+1, Morten W. Petersen wrote: >> >>> so, yeah, it appears as if the code steps on an evil case in terms of >>> GCC's performance. >> >> If it is a bug and not a result of your code, have you reported it? >> > Its a bug for a compiler to crash on any input. > However with highly nested macros which expand to huge quantities of text, it > is hardly surprising. Attempting to process can produce a slowdown which, > in practice, is worse than a crash. Yeah, that's true. In any case, might be contrived and should be reported so it can be fixed. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-26 13:36 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <87wpyqhcjs.fsf@bsb.me.uk> |
| In reply to | #64198 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, June 26, 2015 at 9:14:59 AM UTC+1, Morten W. Petersen wrote: >> >> > so, yeah, it appears as if the code steps on an evil case in terms of >> > GCC's performance. >> >> If it is a bug and not a result of your code, have you reported it? >> > Its a bug for a compiler to crash on any input. > However with highly nested macros which expand to huge quantities of text, it > is hardly surprising. Attempting to process can produce a slowdown which, > in practice, is worse than a crash. I think that's an overly-generous assumption. If the "crash" is guaranteed to be provoked at the first sign of trouble you maybe be right, but it is often the result of some subsequent problem caused by the first sign of trouble. That means there may well be cases that go wrong but *don't* crash, and that is the worst situation of all. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-26 17:45 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjs0r$jtg$1@speranza.aioe.org> |
| In reply to | #64224 |
On 26.06.2015 14:36, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Friday, June 26, 2015 at 9:14:59 AM UTC+1, Morten W. Petersen wrote: >>> >>>> so, yeah, it appears as if the code steps on an evil case in terms of >>>> GCC's performance. >>> >>> If it is a bug and not a result of your code, have you reported it? >>> >> Its a bug for a compiler to crash on any input. >> However with highly nested macros which expand to huge quantities of text, it >> is hardly surprising. Attempting to process can produce a slowdown which, >> in practice, is worse than a crash. > > I think that's an overly-generous assumption. If the "crash" is > guaranteed to be provoked at the first sign of trouble you maybe be > right, but it is often the result of some subsequent problem caused by > the first sign of trouble. That means there may well be cases that go > wrong but *don't* crash, and that is the worst situation of all. Ahh, good one. So it should definitely be reported. Better that things pop up in development rather than in production. I had to test a bit after this was mentioned, and the following file: https://github.com/morphex/smash_xml/blob/7a9b38d26596e9e2bc1e84288fc6c1babbacb52a/crash_gcc_float.c Crashes a fairly recent version of GCC on Cygwin 64 bit, Windows 7. The bug report is here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66683 -Morten
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-26 09:28 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjnpa$4fe$1@news.albasani.net> |
| In reply to | #64196 |
On 6/26/2015 3:15 AM, Morten W. Petersen wrote: >>> ro expansions, *): >>>> MSVC: 2.320s >>>> MinGW: 2m37s >>>> Cygwin: 2m45s >>> >>> And gcc is here over 60 times slower. Something is badly wrong! >>> >> >> it is possible the code steps on an adverse situation for GCC. >> >> the generated code mostly consists of large amounts of generated >> single-line functions, and some very large switch blocks. >> >> curious was in this case, Linux got the worst performance, whereas in >> most other cases it was faster than the Windows run. >> >> >> testing with my compiler, this code causes the compiler to crash in the >> preprocessor (with a corrupted stack). need to investigate, I suspect >> buffer overruns. >> >> looking: yep, macro-expansion was producing large (64-100kB or more) >> outputs (one macro call may expand to a large amount of output). a >> better solution would be to dynamically expand the buffer (as-is, >> fixed-size buffers are used, I just kicked them up to around 1MB...). >> >> compiler execution time: around 6 seconds (4s in PP, 2s in >> parse/compile). >> >> >> so, yeah, it appears as if the code steps on an evil case in terms of >> GCC's performance. > > If it is a bug and not a result of your code, have you reported it? > it may be a bug, dunno. it may also just be a result of poor optimization, such as using a simpler algorithm somewhere with high computational complexity. found the place, submitted report, will see what happens. > -Morten >
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web