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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-26 17:48 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjs7n$jtg$2@speranza.aioe.org> |
| In reply to | #64232 |
On 26.06.2015 16:28, BGB wrote: > 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. What's the bug ID? -Morten
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-26 11:30 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjuul$3al$1@news.albasani.net> |
| In reply to | #64238 |
On 6/26/2015 10:48 AM, Morten W. Petersen wrote: > On 26.06.2015 16:28, BGB wrote: >> 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. > > What's the bug ID? > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 apparently it is in "expand", but little idea what this is. apparently, I had failed to notice the "-v" option in the directions previously, hmm...
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-27 09:00 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmlhkv$21i$1@speranza.aioe.org> |
| In reply to | #64242 |
On 26.06.2015 18:30, BGB wrote: > On 6/26/2015 10:48 AM, Morten W. Petersen wrote: >> On 26.06.2015 16:28, BGB wrote: >>> 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. >> >> What's the bug ID? >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 > > apparently it is in "expand", but little idea what this is. > > apparently, I had failed to notice the "-v" option in the directions > previously, hmm... I had to try getting gcc to fail as well, so I constructed a macro that has (if I'm counting right) over 500M float multiplications and it fails: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66683 Now that's contrived and a huge macro but gcc still gives a good hint on where something is wrong. -Morten
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-27 11:08 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmmi2p$2n1$1@news.albasani.net> |
| In reply to | #64274 |
On 6/27/2015 2:00 AM, Morten W. Petersen wrote: > On 26.06.2015 18:30, BGB wrote: >> On 6/26/2015 10:48 AM, Morten W. Petersen wrote: >>> On 26.06.2015 16:28, BGB wrote: >>>> 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. >>> >>> What's the bug ID? >>> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 >> >> apparently it is in "expand", but little idea what this is. >> >> apparently, I had failed to notice the "-v" option in the directions >> previously, hmm... > > I had to try getting gcc to fail as well, so I constructed a macro > that has (if I'm counting right) over 500M float multiplications > and it fails: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66683 > > Now that's contrived and a huge macro but gcc still gives a good > hint on where something is wrong. > my code wasn't written to break GCC, but rather I had grabbed a piece of code from my VM intended to measure GCC speed with a less-trivial piece of code, and noted that it took abnormally long. apparently, it kills the hash table. I have noted with MSVC, that if macros expand too much, the compiler is essentially like "go f* yourself" (rather than trying to deal with an arbitrarily large amount of data). I am not sure where the limit is exactly, but have run into it before. it is unclear whether it is "better" for the compiler to bail out early or try to deal with excessively large data. but, yeah, the code fragment I had tested, takes my compiler about 6 seconds, but in the process quickly expands the heap to around 500MB. recently, I had ran into an issue with my preprocessor it should probably check: IOW, make sure code does not overflow buffers; overflowing a buffer (say, 1MB for a single macro expansion, or 64MB for a compilation unit), may result in the compiler aborting with a fatal error or similar. partly though this is because rejecting if limits are exceeded would be less effort than dynamically resizing the buffers in this case. looking around, may also need to deal with the issue of the potential of excessively long string literals.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-28 18:07 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmp9h7$mm5$1@dont-email.me> |
| In reply to | #64242 |
On 26/06/2015 17:30, BGB wrote: ` > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 I think this will be an excellent test (the attached source in that link) for anyone thinking of working on a C compiler, parser, or even just a preprocessor. Because if it manages this, it should cope with anything! And the expanded output from that code (-E option with gcc), contains some of the most gorgeous C code I've ever seen (I've got a solid, word-wrapped block of it as my desktop background at the moment). However, it's also another good test that an aspiring parser should be able to take in its stride. (Apparently it's this last part that gcc has some trouble with.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-28 22:26 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmqe5l$q2i$1@news.albasani.net> |
| In reply to | #64380 |
On 6/28/2015 12:07 PM, Bartc wrote: > On 26/06/2015 17:30, BGB wrote: > ` >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 > > I think this will be an excellent test (the attached source in that > link) for anyone thinking of working on a C compiler, parser, or even > just a preprocessor. Because if it manages this, it should cope with > anything! > > And the expanded output from that code (-E option with gcc), contains > some of the most gorgeous C code I've ever seen (I've got a solid, > word-wrapped block of it as my desktop background at the moment). > > However, it's also another good test that an aspiring parser should be > able to take in its stride. (Apparently it's this last part that gcc has > some trouble with.) > a lot of the VM is code like this. macros expand to large numbers of specialized functions, mostly as this strategy allows making the interpreter go reasonably fast. there is another interpreter which doesn't expand out so much, instead executing operations mostly using switches, but this is slower.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-29 09:49 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmqt8j$pa4$1@dont-email.me> |
| In reply to | #64380 |
On 28/06/15 19:07, Bartc wrote: > On 26/06/2015 17:30, BGB wrote: > ` >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 > > I think this will be an excellent test (the attached source in that > link) for anyone thinking of working on a C compiler, parser, or even > just a preprocessor. Because if it manages this, it should cope with > anything! > > And the expanded output from that code (-E option with gcc), contains > some of the most gorgeous C code I've ever seen (I've got a solid, > word-wrapped block of it as my desktop background at the moment). > > However, it's also another good test that an aspiring parser should be > able to take in its stride. (Apparently it's this last part that gcc has > some trouble with.) > You mean /had/ trouble with - the bug report shows clearly that the problem was fixed over a year ago.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-29 09:05 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mmrjk4$qm6$1@news.albasani.net> |
| In reply to | #64425 |
On 6/29/2015 2:49 AM, David Brown wrote: > On 28/06/15 19:07, Bartc wrote: >> On 26/06/2015 17:30, BGB wrote: >> ` >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 >> >> I think this will be an excellent test (the attached source in that >> link) for anyone thinking of working on a C compiler, parser, or even >> just a preprocessor. Because if it manages this, it should cope with >> anything! >> >> And the expanded output from that code (-E option with gcc), contains >> some of the most gorgeous C code I've ever seen (I've got a solid, >> word-wrapped block of it as my desktop background at the moment). >> >> However, it's also another good test that an aspiring parser should be >> able to take in its stride. (Apparently it's this last part that gcc has >> some trouble with.) >> > > You mean /had/ trouble with - the bug report shows clearly that the > problem was fixed over a year ago. > though the fixed version doesn't seem to have yet propagated to the various Linux distros.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-29 16:54 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmrm4j$1hr$1@dont-email.me> |
| In reply to | #64451 |
On 29/06/15 16:05, BGB wrote: > On 6/29/2015 2:49 AM, David Brown wrote: >> On 28/06/15 19:07, Bartc wrote: >>> On 26/06/2015 17:30, BGB wrote: >>> ` >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 >>> >>> I think this will be an excellent test (the attached source in that >>> link) for anyone thinking of working on a C compiler, parser, or even >>> just a preprocessor. Because if it manages this, it should cope with >>> anything! >>> >>> And the expanded output from that code (-E option with gcc), contains >>> some of the most gorgeous C code I've ever seen (I've got a solid, >>> word-wrapped block of it as my desktop background at the moment). >>> >>> However, it's also another good test that an aspiring parser should be >>> able to take in its stride. (Apparently it's this last part that gcc has >>> some trouble with.) >>> >> >> You mean /had/ trouble with - the bug report shows clearly that the >> problem was fixed over a year ago. >> > > though the fixed version doesn't seem to have yet propagated to the > various Linux distros. > gcc >= 4.8.5 is standard on a number of distros, though by no means all. <http://distrowatch.com/search.php?pkg=gcc&pkgver=4.9#pkgsearch> It is not hard to get a fixed gcc for whatever distro you use for development, but it would be tougher if you are distributing the source code and insist that users have a new enough version of the compiler.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-29 12:39 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <mms057$9sd$1@news.albasani.net> |
| In reply to | #64459 |
On 6/29/2015 9:54 AM, David Brown wrote: > On 29/06/15 16:05, BGB wrote: >> On 6/29/2015 2:49 AM, David Brown wrote: >>> On 28/06/15 19:07, Bartc wrote: >>>> On 26/06/2015 17:30, BGB wrote: >>>> ` >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682 >>>> >>>> I think this will be an excellent test (the attached source in that >>>> link) for anyone thinking of working on a C compiler, parser, or even >>>> just a preprocessor. Because if it manages this, it should cope with >>>> anything! >>>> >>>> And the expanded output from that code (-E option with gcc), contains >>>> some of the most gorgeous C code I've ever seen (I've got a solid, >>>> word-wrapped block of it as my desktop background at the moment). >>>> >>>> However, it's also another good test that an aspiring parser should be >>>> able to take in its stride. (Apparently it's this last part that gcc has >>>> some trouble with.) >>>> >>> >>> You mean /had/ trouble with - the bug report shows clearly that the >>> problem was fixed over a year ago. >>> >> >> though the fixed version doesn't seem to have yet propagated to the >> various Linux distros. >> > > gcc >= 4.8.5 is standard on a number of distros, though by no means all. > > <http://distrowatch.com/search.php?pkg=gcc&pkgver=4.9#pkgsearch> > > It is not hard to get a fixed gcc for whatever distro you use for > development, but it would be tougher if you are distributing the source > code and insist that users have a new enough version of the compiler. > current ones I use are mostly Ubuntu and Raspbian. had updated Ubuntu recently (via 'apt-get'), but it seems to have simply moved from GCC 4.8.2 to 4.8.4. Raspbian is running 4.6.3. not like it really matters though, since most of my test-builds are on the PC (win MSVC), and I only occasionally recompile for the RPi (usually to test the thing with the actual HW).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-26 14:05 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjf4i$cud$1@dont-email.me> |
| In reply to | #64180 |
On 25/06/15 23:32, BGB wrote: > 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. > Let me give some statistics on a project I am working on. Compilation is using gcc 4.8 for ARM, using pre-built binaries from Freescale, on 64-bit Linux (old Fedora) and 64-bit Windows (Win7) with similarly powered machines (i7, 4+4 cores, lots of ram - the Windows one is somewhat newer and faster - 3.2 GHz vs. 2.67 GHz). Header files - 114 files, total 148 KLOC (including header files describing all the I/O registers on the chip, but excluding system headers). C files - 91 files, total 55 KLOC All builds here are done twice to get files and programs in the cache (assuming the OS keeps them there between runs). Builds include dependency file creation (using gcc), compilation (using lots of optimisations and warnings, and creating listing files), and linking. Linux ----- time make clean (after a full build): real 0.092s user 0.026s sys 0.064s time make: real 48.129s user 39.686s sys 7.628s time make -j 8 clean: real 0.091s user 0.018s sys 0.070s time make -j 8 : real 11.413s user 1m6.342s sys 11.144s time make (when there is nothing to do but check time-stamps) : real 0.068s user 0.037s sys 0.031s Windows ----- (I don't know quite how the "time" version I have on windows determines user and sys times - "time" is not native to Windows. But the "real" time is valid.) time make clean (after a full build): real 2.525s user 0.217s sys 0.966s time make: real 1m12.459s user 2.096s sys 3.569s time make -j 8 clean: real 2.500s user 0.434s sys 0.763s time make -j 8 : real 27.548s user 1.865s sys 3.911s time make (when there is nothing to do but check time-stamps) : real 1.134s user 0.372s sys 0.810s What does this tell us? The total pre-processed source code of all the files is about 750 KLOC. On Linux, with serial build, that's an average of 15.6 K lines per second. With realistic builds using parallel make, the effective figure is 65 K lines per second. For serial builds, gcc takes about 66% of the time of gcc on Windows. But for parallel builds, it takes 41% of the time. If we factor in the differences in the cpu clock (I know the speed of software is not linear in the cpu clock speed), that would be 55% and 34% respectively - gcc is twice as fast in Linux, when running serially, and three times as fast in parallel builds. Windows is painfully slow at dealing with files, especially when there are a lot of them - Linux is 25 times as fast at simple file operations such as deleting trees, or checking timestamps for make. And it is painfully slow at dealing with multiple processes - parallel builds on Linux scale at 4.2, while they scale at 2.6 on Windows. This is, of course, just one test - one project, one compiler version, one set of flags, on one pair of non-identical computers. But since it is the project I am working with, they are realistic numbers for me. They show that I can re-build the project in a little over 10 seconds - most incremental builds are done in a couple of seconds. They show that Linux is a much better platform than Windows for compilation and working with lots of files (obviously there are many other features of different platforms that are more important for productivity than compilation speed).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-27 11:40 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmlug2$lkp$1@dont-email.me> |
| In reply to | #64215 |
On 26/06/2015 13:05, David Brown wrote: > On 25/06/15 23:32, BGB wrote: > Let me give some statistics on a project I am working on. Compilation > is using gcc 4.8 for ARM, using pre-built binaries from Freescale, on > 64-bit Linux (old Fedora) and 64-bit Windows (Win7) with similarly > powered machines (i7, 4+4 cores, lots of ram - the Windows one is > somewhat newer and faster - 3.2 GHz vs. 2.67 GHz). > > Header files - 114 files, total 148 KLOC (including header files > describing all the I/O registers on the chip, but excluding system headers). > > C files - 91 files, total 55 KLOC > time make: > real 48.129s user 39.686s sys 7.628s > Windows > real 2.525s user 0.217s sys 0.966s > What does this tell us? The total pre-processed source code of all the > files is about 750 KLOC. On Linux, with serial build, that's an average > of 15.6 K lines per second. With realistic builds using parallel make, > the effective figure is 65 K lines per second. This is not really about Linux vs. Windows. I'm sure that gcc and its toolset, developed on Linux, will be highly optimised for Linux. (Maybe these tools are part /of/ Linux and therefore even more streamlined; I don't know.) But other compilers /are/ capable of running very quickly under Windows. I've just dug up an old compiler of mine (not interpreted this time), and an old project, and it managed about 100K lines per second - on a single core. (60K lines of code in 22 modules, plus 140K lines of headers; one big header is frequently included unnecessarily, nevertheless it totalled 200K lines and it compiled that lot in about 2 seconds.) (This does generate .asm instead of .obj, but given that .asm files are 2-3 times as big as .obj ones, it's probably more of a handicap! I've fairly certain that if I was to generate .obj directly, it wouldn't be any slower, and probably faster.) I also use different approaches to get a fast development cycle, without needing to use optimisations such as incremental linking, or checking time stamps or needing multiple cores or whatever. For example, applications tend to use dynamic languages which can make use of fast byte-code compilers, and don't need linking or building. In fact code could be developed not only while the rest of the application is still running, but from inside it! (I've just tested an old non-interpreted byte-code compiler, and it processed 200,000 lines per second. That compiler wasn't written in C so wouldn't have been able to take advantage of -O3 optimisations, otherwise we could be talking about 300K lines per second.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-27 16:33 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmmfm4$jft$1@dont-email.me> |
| In reply to | #64282 |
On 27/06/2015 11:40, Bartc wrote: > On 26/06/2015 13:05, David Brown wrote: >> On Linux, with serial build, that's an average >> of 15.6 K lines per second. With realistic builds using parallel make, >> the effective figure is 65 K lines per second. > (I've just tested an old non-interpreted byte-code compiler, and it > processed 200,000 lines per second. I tested it more carefully (these fast programs are harder to measure), and it's more like 260-280K lines per second. This was created without an optimising compiler, neither was it particularly designed for speed. This is on the same platform that you said was too slow to work with. I think I'll try and find some time later this year (if I still have an interest in it), to put together a C compiler front end, and to do so in a compiled language, just to see exactly what the problem is in writing a fast C compiler. It's possible that the design of C makes it hard to do so (so you are forced to recompile large headers for example, as differences in context could make it compile differently). However my tests didn't have very challenging headers. (The first language product I tested was an assembler, it managed 1700 lines per second, on a 2.5MHz Z80 in 1981. I think I would have been surprised that 34 years later, on hardware 1000-10000 times more powerful, that the lines-per-second figure had only just managed to creep over the 2000 lps threshold! Yes, I understand you can't compare a simple, crude assembler with a sophisticated super-optimising compiler, but you still have to hang about waiting. And the sources now are bigger...) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-27 12:24 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <lnh9pteyzv.fsf@kst-u.example.com> |
| In reply to | #64282 |
Bartc <bc@freeuk.com> writes:
[...]
> This is not really about Linux vs. Windows. I'm sure that gcc and its
> toolset, developed on Linux, will be highly optimised for Linux. (Maybe
> these tools are part /of/ Linux and therefore even more streamlined; I
> don't know.)
gcc predates Linux.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-27 22:37 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmn1gf$pb8$1@dont-email.me> |
| In reply to | #64282 |
On 27/06/15 12:40, Bartc wrote: > On 26/06/2015 13:05, David Brown wrote: >> On 25/06/15 23:32, BGB wrote: > >> Let me give some statistics on a project I am working on. Compilation >> is using gcc 4.8 for ARM, using pre-built binaries from Freescale, on >> 64-bit Linux (old Fedora) and 64-bit Windows (Win7) with similarly >> powered machines (i7, 4+4 cores, lots of ram - the Windows one is >> somewhat newer and faster - 3.2 GHz vs. 2.67 GHz). >> >> Header files - 114 files, total 148 KLOC (including header files >> describing all the I/O registers on the chip, but excluding system >> headers). >> >> C files - 91 files, total 55 KLOC > >> time make: >> real 48.129s user 39.686s sys 7.628s > >> Windows > >> real 2.525s user 0.217s sys 0.966s > >> What does this tell us? The total pre-processed source code of all the >> files is about 750 KLOC. On Linux, with serial build, that's an average >> of 15.6 K lines per second. With realistic builds using parallel make, >> the effective figure is 65 K lines per second. > > This is not really about Linux vs. Windows. I'm sure that gcc and its > toolset, developed on Linux, will be highly optimised for Linux. (Maybe > these tools are part /of/ Linux and therefore even more streamlined; I > don't know.) No, gcc is not part of Linux (though currently it is the only compiler that can be used to compile the Linux kernel, due to the kernel's use of gcc extensions - clang support is close, however). If you are interested in the "open source software" vs. "free software" debates, you would quickly see that gcc and Linux are not nearly as closely tied as you think. (I am not suggesting that these OSS vs. FS arguments are at all interesting.) gcc is "native" to any POSIX system. That does mean it fits better with Linux than Windows, but that's all. To be honest, I have somewhat lost track of what the discussion was supposed to be about. All I can really say is that any compilation involving a number of files is much faster under Linux than Windows (with gcc or with the CodeWarrior compiler I tested), and that gcc is nowhere near as slow as you suggest. The key differences in the speed are due to Linux being far more efficient at file handling, and far more efficient at process handling. (For the record, I had no anti-virus of any sort during my Windows tests.) > > But other compilers /are/ capable of running very quickly under Windows. gcc is certainly a slow compiler - benchmarks suggest that it is about half the speed of clang, though the generated code is faster. Apparently gcc 5 compiles faster, however. But for any benchmarks, you have to use /your/ code to get truly relevant results. So again, I have no quarrels about suggestions that gcc is slow compared to other compilers - merely that it is not as slow as you had claimed. > > I've just dug up an old compiler of mine (not interpreted this time), > and an old project, and it managed about 100K lines per second - on a > single core. (60K lines of code in 22 modules, plus 140K lines of > headers; one big header is frequently included unnecessarily, > nevertheless it totalled 200K lines and it compiled that lot in about 2 > seconds.) > > (This does generate .asm instead of .obj, but given that .asm files are > 2-3 times as big as .obj ones, it's probably more of a handicap! I've > fairly certain that if I was to generate .obj directly, it wouldn't be > any slower, and probably faster.) > > I also use different approaches to get a fast development cycle, without > needing to use optimisations such as incremental linking, or checking > time stamps or needing multiple cores or whatever. > > For example, applications tend to use dynamic languages which can make > use of fast byte-code compilers, and don't need linking or building. In > fact code could be developed not only while the rest of the application > is still running, but from inside it! > > (I've just tested an old non-interpreted byte-code compiler, and it > processed 200,000 lines per second. That compiler wasn't written in C so > wouldn't have been able to take advantage of -O3 optimisations, > otherwise we could be talking about 300K lines per second.) >
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-27 22:31 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmn4ka$4g3$1@dont-email.me> |
| In reply to | #64324 |
On 27/06/2015 21:37, David Brown wrote: > To be honest, I have somewhat lost track of what the discussion was > supposed to be about. The sub-thread was started by someone who objected to my saying that gcc was getting bigger and slower. But it seems to be generally agreed that it /is/ quite big and it /is/ fairly slow among C compilers, and it /is/ getting bigger and slower, so I wasn't wrong. (And, now that I've had a look at one or two old compilers of mine that seem to run at astonishing speed, its even slower than I'd thought.) Although my calling it a 'monster' was just in my view, as my compiler projects are one thousandth the size. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-28 00:47 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmn948$mjv$1@dont-email.me> |
| In reply to | #64330 |
On 27/06/15 23:31, Bartc wrote: > On 27/06/2015 21:37, David Brown wrote: > >> To be honest, I have somewhat lost track of what the discussion was >> supposed to be about. > > The sub-thread was started by someone who objected to my saying that gcc > was getting bigger and slower. > > But it seems to be generally agreed that it /is/ quite big and it /is/ > fairly slow among C compilers, and it /is/ getting bigger and slower, so > I wasn't wrong. > Actually, it appears to be getting faster again (tests show gcc 5 is faster than 4.9). Certainly 3.x and 4.x gcc are a lot slower than the old 2.x generations - but they are vastly more advanced compilers with lots more features, and better code generation. > (And, now that I've had a look at one or two old compilers of mine that > seem to run at astonishing speed, its even slower than I'd thought.) > > Although my calling it a 'monster' was just in my view, as my compiler > projects are one thousandth the size. > Yes, but that's an apples to farming village comparison (or an MS-DOS to FreeBSD comparison).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-28 11:28 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmoi6h$1oe$1@dont-email.me> |
| In reply to | #64333 |
On 27/06/2015 23:47, David Brown wrote: >> Although my calling it a 'monster' was just in my view, as my compiler >> projects are one thousandth the size. >> > > Yes, but that's an apples to farming village comparison Or like comparing using the corner shop 50 yards away, to driving to the mega-store on the other side of town (on the Saturday before Christmas). But you can appreciate the advantages when you just want a pint of milk. > (or an MS-DOS to FreeBSD comparison). I don't know what FreeBSD is, but looking at Wikipedia: "The FreeBSD Project is run by around 500 committers". So sounds like another monster! I've never been into OSes, it was enough that MSDOS provided a disk file system, everything else I was happy to supply (for graphics, fonts, printers, plotters, mice and tablets, that sort of stuff). I suspect that FreeBSD /at the time/, whatever other dull OS benefits it might had, didn't provide that much more. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-28 14:00 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmonj5$jnv$1@dont-email.me> |
| In reply to | #64341 |
On 28/06/15 12:28, Bartc wrote: > On 27/06/2015 23:47, David Brown wrote: > >>> Although my calling it a 'monster' was just in my view, as my compiler >>> projects are one thousandth the size. >>> >> >> Yes, but that's an apples to farming village comparison > > Or like comparing using the corner shop 50 yards away, to driving to the > mega-store on the other side of town (on the Saturday before Christmas). > > But you can appreciate the advantages when you just want a pint of milk. Yes, I can quite understand that little C compilers can have their uses (and if they are for different languages, or have different extensions, then obviously these can be a major advantage for some people). But it is wrong to compare the mega-store and the corner-store by saying they both sell milk, but you can buy milk in 5 minutes at the corner store, while it takes an hour at the mega-store - therefore the mega-store is an inefficient overly complex monstrosity. > > > (or an MS-DOS to FreeBSD comparison). > > I don't know what FreeBSD is, but looking at Wikipedia: > > "The FreeBSD Project is run by around 500 committers". So sounds like > another monster! FreeBSD is a large unix-like system. While Linux is technically just the kernel, and you need something like Red Hat, Debian, Linux Mint, etc., to provide the distribution with filesystems, basic software, Windowing system, apps, and everything else, FreeBSD provides all that as well as the kernel. (It's mostly just the kernel and a few libraries that are FreeBSD specific - the rest of the software is standard *nix open source software which the FreeBSD folks test and package. And they use clang rather than gcc.) > > I've never been into OSes, it was enough that MSDOS provided a disk file > system, everything else I was happy to supply (for graphics, fonts, > printers, plotters, mice and tablets, that sort of stuff). I suspect > that FreeBSD /at the time/, whatever other dull OS benefits it might > had, didn't provide that much more. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-28 05:44 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <1d41303c-2464-41a9-b48f-d7e3108be3d4@googlegroups.com> |
| In reply to | #64352 |
On Sunday, June 28, 2015 at 1:01:04 PM UTC+1, David Brown wrote: > > Yes, I can quite understand that little C compilers can have their uses > (and if they are for different languages, or have different extensions, > then obviously these can be a major advantage for some people). But it > is wrong to compare the mega-store and the corner-store by saying they > both sell milk, but you can buy milk in 5 minutes at the corner store, > while it takes an hour at the mega-store - therefore the mega-store is > an inefficient overly complex monstrosity. > The mega store is inefficient and over-complex if your grocery needs are bottles of milk and occasional jars of coffee and tea for the office. If you're doing a weekly shop for a family of wife and two kids, you can get the particular brand of cornflakes the kids insist on at the mega-store, often the little corner shop won't sell it. So then you need the mega store.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web