Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90419 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-15 23:36 +0200 |
| Last post | 2016-08-02 13:20 -0700 |
| Articles | 20 on this page of 164 — 22 participants |
Back to article view | Back to comp.lang.c
High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-15 23:36 +0200
Re: High level C supercat@casperkitty.com - 2016-07-15 15:17 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:09 +0200
Re: High level C supercat@casperkitty.com - 2016-07-17 20:02 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-15 15:17 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-07-31 23:55 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:13 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 02:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 11:07 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:29 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:40 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 11:57 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 11:30 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:53 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 07:49 -0700
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-16 17:08 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 09:09 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 16:26 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 18:05 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 20:15 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 23:44 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:39 +0000
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:58 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:52 +0000
Re: High level C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 16:29 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:38 +0000
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 14:17 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:46 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:05 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 11:03 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 03:39 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 18:20 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 14:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:13 +0530
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 20:14 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-17 20:14 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 20:45 +0100
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-07-17 21:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 09:48 +0530
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 00:55 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:25 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 11:40 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 05:05 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:59 +0530
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:50 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 19:07 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:53 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 11:15 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 14:00 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:01 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:26 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:57 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:13 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 18:14 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:20 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 19:46 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:44 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-20 10:59 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 01:44 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:58 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 17:20 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 20:52 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:14 +0100
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-21 13:23 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:50 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 12:52 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 04:03 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:56 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:09 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:49 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:37 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 19:16 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:17 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 21:07 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:36 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:27 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 16:27 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:14 +0100
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 10:08 +0200
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:04 +0530
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 10:18 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:26 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:21 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-25 10:19 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:31 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-28 21:13 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 09:05 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-29 09:30 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 10:08 -0700
Re: High level C Ike Naar <ike@iceland.freeshell.org> - 2016-07-29 17:57 +0000
Re: High level C supercat@casperkitty.com - 2016-07-29 11:50 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 07:16 -0700
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:34 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 14:55 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 03:10 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:40 -0700
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-01 19:43 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 10:21 -0500
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-03 13:14 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:40 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:28 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-05 09:55 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:51 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:43 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:43 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:52 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:42 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 12:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-07-31 16:42 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:59 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-07-31 17:12 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:12 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 00:54 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 08:08 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 12:58 -0500
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 12:25 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:44 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 11:56 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 19:29 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-03 13:45 -0400
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 13:23 -0500
Re: High level C BartC <bc@freeuk.com> - 2016-08-03 19:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 21:04 +0200
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-03 20:08 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:09 -0500
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:06 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 23:36 +0200
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 19:44 -0500
Re: High level C supercat@casperkitty.com - 2016-08-03 15:03 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 19:17 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 05:48 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 08:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:30 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 10:34 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 20:50 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:39 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:50 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 17:08 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 02:23 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:03 +0000
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 12:13 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:10 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:40 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:56 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:51 +0200
Re: High level C supercat@casperkitty.com - 2016-08-08 09:12 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 22:07 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 15:05 -0700
Re: High level C Ian Collins <ian-news@hotmail.com> - 2016-08-03 11:22 +1200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:50 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 01:12 +0100
Re: High level C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 20:16 -0400
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:17 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 08:20 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 17:24 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 09:24 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:15 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:22 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 23:58 +0200
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-02 13:20 -0700
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-01 19:43 +0100 |
| Message-ID | <87pops2uv2.fsf@gmail.com> |
| In reply to | #91483 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > IMO these comments don't offer any substance of interest to > the discussion. That's our Malcolm
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-01 10:21 -0500 |
| Message-ID | <nnnp4i$a3a$1@dont-email.me> |
| In reply to | #91464 |
Malcolm McLean wrote: > On Sunday, July 31, 2016 at 10:55:58 PM UTC+1, Tim Rentsch wrote: >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> It's also a silly number >> >> If it is an accurate reporting of an actual measurement of >> productivity, how is it silly? Do you think that the kind of >> activities involved are not typical of most code development? >> Wouldn't that depend on what programming tasks were measured? >> Or do you think the number is silly for some other reason? >> > Plenty of C coding is done in an environment where there is no dynamic > memory at all. So no measure of the impact of GC can be truly > representative of a cross-section of C programming. > Really the question is, what type of coding, what type of productivity gain, > and is it in an area that is a risk to the business. > > For example, you might have one person you can't easily replace doing > core mathematical algorithms, and ten people putting up windows and > writing SQL queries and doing all the other jobs needed to gather the > data to feed to those algorithms and present the results to the user. > Now it's unlikely your pay your mathematician ten times as much as your > other programmers, probably more like 50% more and less than than lead > programmer on the project. So on one level, if we double everyone else's > productivity, and halve the mathematician's we've essentially halved the > cost of development. However we've also doubled the development time, > and we've doubled the risk that our mathematician will go under a bus before > the project is completed. > So the move to GC wouldn't really be a good idea, under those hypothetical > circumstances. The scenario is a bit extreme, to make the point, but not > fundamentally unrealistic. Not all lines of code are worth the same. The more important point is that it's very nearly impossible to predict the outcome of a move to GC. Let me try an alternate derivation. I don't think you gain that much from having GC available to anyone on the team. Any given SQL query has a finite lifetime. In order to completely test a reasonable subset of SQL queries, you have to be able to reason effectively about the lifetime of SQL queries. If there's a hole in the use cases used for development, then you'll have some sort of problem proportional to that hole no matter what. The *larger* problem is that people are doing automation work where the outcome of said work has no predictable payback vs. predictable cost. If the automation itself is self-evident then all these problems fall away. >> >> But suppose we back up and guess that these reports are not >> typical, and that a more representative number is 1.25 times. >> Doesn't that already seem like a signifcant factor? Being >> able to accomplish a task that would have taken five weeks >> in only four weeks? I still would put that in the big win >> category. >> > I don't think there's any dispute that proper handling of memory allocation failure > and freeing of allocated structures adds a lot of unnecessary complexity to > C code. Oh, I think there is lots of room for saying that. > Made worse because many people won't use a goto on malloc() > failure, so the complexity goes into their main control flow. Also because > some people insist that root objects be allocated on the stack, which saves > one malloc() call, at cost of complicating the create / destroy paradigm. > Creating furniture which "does allocation" with reasonable paths on failure is rather boring but necessary in 'C'. And second, why are you creating and destroying all the time? If you are creating and destroying all the time, why don't you have instrumentation and other support scaffolding to to show that this operates properly? > It also means that some methodolgies, like closures which survive the return > from the captured scope, can't easily be implemented in C. I'd rather strenuously disagree in that exact case - indeed, that's the main technology I find somewhat "easier" in 'C' than in languages where scope and lifespan are differently entangled. > You can easily > enough malloc a chunk of memory to take a snapshot of the scope, but you can't > then destroy it when the closure is finally got rid of. > There are more strategies for solving that problem than I can recount. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-08-03 13:14 +0000 |
| Message-ID | <57a1ebcd.5945000@news.xs4all.nl> |
| In reply to | #91430 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > >> Don't get me wrong, there are consequences for adopting a > >> GC-based model for memory allocation. Certainly there are > >> contexts (writing OS kernels being an obvious one) where using GC > >> is rightly viewed with great skepticism. But I think most C > >> programs would benefit from switching to a GC-based model. The > >> reason is a gain in developer productivity: studies that have > >> been done show a productivity improvement in the range of 60 to > >> 100 percent. That is, writing code where there is no need for > >> manual deallocation produces somewhere between 1.6 times and 2 > >> times as many lines of code per day. That is a huge win. > > > > It's also a silly number > > If it is an accurate reporting of an actual measurement of > productivity, how is it silly? Do you think that the kind of > activities involved are not typical of most code development? > Wouldn't that depend on what programming tasks were measured? > Or do you think the number is silly for some other reason? I think it's silly because I've never written code where memory management _could_ increase production by that much. _Resource_ management, yes, perhaps. But if you let GC demolish your structures without handling all the insignificant details like, oh, closing files, committing databases, and so on, you're in for a lot of pain and lost data; whereas if you _do_ take good care of all your resources, mere memory management is just one among many details, and not even the most onerous. Of course, this does assume that you write your code intelligently. You don't write code to deallocate payload, then call a function to decouple the node from the tree, then write more code to deallocate the node. You write a function to do all that, _once_, and then everytime you need to remove and destroy a tree node, you call that function knowing that it handles the memory management for you _as well as_ the more essential data management. > > which I have a hard time believing. How much of > > your code is spent doing allocation tasks, compared to computation and > > other data manipulation? How much bookkeeping involves not _just_ > > free(), but also, I dunno, data_structure_destroy()? I'd need a very > > atypical project for it even to be _possible_ for me to write twice as > > many lines of code if I could forget about free(), never mind likely. > > I think the key question is not about how much code but about how > much mental effort is required. Most of the related mental > energy in code that requires manual freeing goes into not having > to call malloc()/free() in the first place. Library functions > like strcpy(), strcat(), snprintf() reflect this. How much time > goes into avoiding overflow of finite buffers? That problem goes > away if functions like these allocate new memory for their > results, to be automatically freed at a later appropriate moment. I thought we were talking about GC? This goes much further than that. If you want to re-write strcpy() to manage its own memory (and, I have to assume, crash and burn, deep inside your program, without you getting a say-in, if it can't get any more), feel free, but that's not the C strcpy() any more. At that point, it becomes easier to switch to another language. I dunno, Lua? Visual Basic? > But suppose we back up and guess that these reports are not > typical, and that a more representative number is 1.25 times. Still a ridiculously high number. In my code, a sane, C-compatible GC which does not involve Basic-ifying the whole library but only automates memory handling itself, directly, could increase my productivity by, perhaps, .1%. And increase its running time by 10%. I run my code more often than I write it. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-05 08:40 -0700 |
| Message-ID | <kfna8gri5rj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91600 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>> >>>> Don't get me wrong, there are consequences for adopting a >>>> GC-based model for memory allocation. Certainly there are >>>> contexts (writing OS kernels being an obvious one) where using GC >>>> is rightly viewed with great skepticism. But I think most C >>>> programs would benefit from switching to a GC-based model. The >>>> reason is a gain in developer productivity: studies that have >>>> been done show a productivity improvement in the range of 60 to >>>> 100 percent. That is, writing code where there is no need for >>>> manual deallocation produces somewhere between 1.6 times and 2 >>>> times as many lines of code per day. That is a huge win. >>> >>> It's also a silly number >> >> If it is an accurate reporting of an actual measurement of >> productivity, how is it silly? Do you think that the kind of >> activities involved are not typical of most code development? >> Wouldn't that depend on what programming tasks were measured? >> Or do you think the number is silly for some other reason? > > I think it's silly because I've never written code where memory > management _could_ increase production by that much. _Resource_ > management, yes, perhaps. But if you let GC demolish your structures > without handling all the insignificant details like, oh, closing files, > committing databases, and so on, you're in for a lot of pain and lost > data; whereas if you _do_ take good care of all your resources, mere > memory management is just one among many details, and not even the most > onerous. > Of course, this does assume that you write your code intelligently. You > don't write code to deallocate payload, then call a function to decouple > the node from the tree, then write more code to deallocate the node. You > write a function to do all that, _once_, and then everytime you need to > remove and destroy a tree node, you call that function knowing that it > handles the memory management for you _as well as_ the more essential > data management. I understand you believe all this to be true. But until you have tried an alternate mode, how do you know what the results will actually be? Is there any experiential evidence you can offer, or is it all just supposition? >>> which I have a hard time believing. How much of >>> your code is spent doing allocation tasks, compared to computation and >>> other data manipulation? How much bookkeeping involves not _just_ >>> free(), but also, I dunno, data_structure_destroy()? I'd need a very >>> atypical project for it even to be _possible_ for me to write twice as >>> many lines of code if I could forget about free(), never mind likely. >> >> I think the key question is not about how much code but about how >> much mental effort is required. Most of the related mental >> energy in code that requires manual freeing goes into not having >> to call malloc()/free() in the first place. Library functions >> like strcpy(), strcat(), snprintf() reflect this. How much time >> goes into avoiding overflow of finite buffers? That problem goes >> away if functions like these allocate new memory for their >> results, to be automatically freed at a later appropriate moment. > > I thought we were talking about GC? This goes much further than that. If > you want to re-write strcpy() to manage its own memory (and, I have to > assume, crash and burn, deep inside your program, without you getting a > say-in, if it can't get any more), feel free, but that's not the C > strcpy() any more. At that point, it becomes easier to switch to another > language. I dunno, Lua? Visual Basic? I'm not talking about replacing the standard library, but augmenting it with user-written functions that are more convenient. All the regular standard library functions are still there, for situations where they might be useful. >> But suppose we back up and guess that these reports are not >> typical, and that a more representative number is 1.25 times. > > Still a ridiculously high number. In my code, a sane, C-compatible GC > which does not involve Basic-ifying the whole library but only automates > memory handling itself, directly, could increase my productivity by, > perhaps, .1%. And increase its running time by 10%. [...] Again, how do you know? Like performance, what makes a difference to productivity (and how much) can be determined reliably only by measurement. Furthermore, the results you expect don't match what has been observed experimentally. In all cases I am aware of where an apples-and-apples comparison is done (meaning, no changes to the language other than how memory allocation is handled), removing the burden of manual memory management gives a significant increase in productivity. For the sake of argument let's suppose that would not happen for you and the projects you work on. Do you think the same is true for all other projects and all other competent developers (or development teams)? If so, why do you? What evidence do you have that suggests the (assumed) results for yourself can be extrapolated to other projects and teams?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-05 09:28 -0700 |
| Message-ID | <1cf7bb19-84b5-4346-a0a8-e802a4eb68f9@googlegroups.com> |
| In reply to | #91737 |
On Friday, August 5, 2016 at 4:40:09 PM UTC+1, Tim Rentsch wrote: > > Again, how do you know? Like performance, what makes a > difference to productivity (and how much) can be determined > reliably only by measurement. > Measuring things is important. But something isn't important because you can measure it. That's what many managers don't understand.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-08-05 09:55 -0700 |
| Message-ID | <9deb9784-cb4a-467a-ba4a-0068f2ec7cd0@googlegroups.com> |
| In reply to | #91740 |
W dniu piątek, 5 sierpnia 2016 18:28:32 UTC+2 użytkownik Malcolm McLean napisał: > On Friday, August 5, 2016 at 4:40:09 PM UTC+1, Tim Rentsch wrote: > > > > Again, how do you know? Like performance, what makes a > > difference to productivity (and how much) can be determined > > reliably only by measurement. > > > Measuring things is important. > But something isn't important because you can measure it. > That's what many managers don't understand. performance and productivity is important (same as quality) but guess what is maybe most important.. . . . . . . . . 'obtainability' - i mean the overall posibility to code/obtain/get something
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-05 15:51 -0700 |
| Message-ID | <kfnoa56hlrw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91740 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 5, 2016 at 4:40:09 PM UTC+1, Tim Rentsch wrote: > >> Again, how do you know? Like performance, what makes a >> difference to productivity (and how much) can be determined >> reliably only by measurement. > > Measuring things is important. > But something isn't important because you can measure it. > That's what many managers don't understand. IMO these comments aren't relevant to what I was saying and don't contribute anything to the discussion.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-05 18:43 +0200 |
| Message-ID | <20160805184316.65887824@maxa-pc> |
| In reply to | #91737 |
On Fri, 05 Aug 2016 08:40:00 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: In all cases I am aware of where an > apples-and-apples comparison is done (meaning, no changes to > the language other than how memory allocation is handled), > removing the burden of manual memory management gives a > significant increase in productivity. I would like more standard library string then GC ;) That would significantly increase productivity. Memory management is not such big issue anyway ;) Again Rust ditched GC for some reason. Language now uses same techniques as C++...
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-05 15:43 -0700 |
| Message-ID | <kfnshuihm5a.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91743 |
Melzzzzz <mel@zzzzz.com> writes: > On Fri, 05 Aug 2016 08:40:00 -0700 > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > In all cases I am aware of where an >> apples-and-apples comparison is done (meaning, no changes to >> the language other than how memory allocation is handled), >> removing the burden of manual memory management gives a >> significant increase in productivity. > > I would like more standard library string then GC ;) > That would significantly increase productivity. > Memory management is not such big issue anyway ;) [...] Your opinion is at odds with the results of experimental studies that measure differences in productivity between the two cases. Do you have any actual evidence to offer?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 00:52 +0200 |
| Message-ID | <20160806005217.64926ac6@maxa-pc> |
| In reply to | #91784 |
On Fri, 05 Aug 2016 15:43:45 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > > On Fri, 05 Aug 2016 08:40:00 -0700 > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > > In all cases I am aware of where an > >> apples-and-apples comparison is done (meaning, no changes to > >> the language other than how memory allocation is handled), > >> removing the burden of manual memory management gives a > >> significant increase in productivity. > > > > I would like more standard library string then GC ;) > > That would significantly increase productivity. > > Memory management is not such big issue anyway ;) [...] > > Your opinion is at odds with the results of experimental studies > that measure differences in productivity between the two cases. > Do you have any actual evidence to offer? Show me yours first. GC was there for functional languages to solve specific problems... it is not necessary in majority of cases...
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-08-10 12:42 +0000 |
| Message-ID | <57ab1ea0.6353656@news.xs4all.nl> |
| In reply to | #91737 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > I think it's silly because I've never written code where memory > > management _could_ increase production by that much. _Resource_ > > management, yes, perhaps. But if you let GC demolish your structures > > without handling all the insignificant details like, oh, closing files, > > committing databases, and so on, you're in for a lot of pain and lost > > data; whereas if you _do_ take good care of all your resources, mere > > memory management is just one among many details, and not even the most > > onerous. > I understand you believe all this to be true. But until you have > tried an alternate mode, how do you know what the results will > actually be? Is there any experiential evidence you can offer, > or is it all just supposition? Well, it's the same reaction I have when people claim that I should replace the sugar in my cooking with Stevia because that'll cut the calories in half at least and miraculously make me much healthier. Yes, they might have a point if I were baking a cake, but I'm cooking sambal goreng hati, and the sugar is a teaspoon at most of gula jawa. There isn't enough sugar in the first place that replacing it _could possibly_ make much of a difference, and the taste _will_ be different because it isn't refined sugar. Similarly in my code: there just isn't enough _for_ GC to replace that it could make that much difference in the first place. And what little there is, is tightly and automagically coupled to other functions that _must not_ be removed lest my database gets corrupted. Hell, in the more trivial of my programs I have so little memory management that replacing malloc() with GC would be more like replacing the sugar with Stevia in my boiled eggs... > Furthermore, the results you expect don't match what has been > observed experimentally. In all cases I am aware of where an > apples-and-apples comparison is done (meaning, no changes to > the language other than how memory allocation is handled), > removing the burden of manual memory management gives a > significant increase in productivity. Even when there barely is any manual memory management in the first place? I call shenanigans. Again, I can see that it would be more important if I wrote code which repeatedly and nakedly malloc()ed large amounts of data and had to be careful about free()ing it. Even then I'd prefer to automate it under my own control rather than trust the GC, but under those circumstances I'd believe you if you predicted a decent improvement of productivity. Even then I'd never believe 60 to 100%, but still, 10%, sounds plausible. But... that's not the kind of code I write. And if it were, I might well use another language than C. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-11 12:24 -0700 |
| Message-ID | <kfn7fbnglc4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92058 |
raltbos@xs4all.nl (Richard Bos) writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> raltbos@xs4all.nl (Richard Bos) writes:
>>
>>> I think it's silly because I've never written code where memory
>>> management _could_ increase production by that much. _Resource_
>>> management, yes, perhaps. But if you let GC demolish your structures
>>> without handling all the insignificant details like, oh, closing files,
>>> committing databases, and so on, you're in for a lot of pain and lost
>>> data; whereas if you _do_ take good care of all your resources, mere
>>> memory management is just one among many details, and not even the most
>>> onerous.
>>
>> I understand you believe all this to be true. But until you have
>> tried an alternate mode, how do you know what the results will
>> actually be? Is there any experiential evidence you can offer,
>> or is it all just supposition?
>
> Well, it's the same reaction I have when people claim that I should
> replace the sugar in my cooking with Stevia because that'll cut the
> calories in half at least and miraculously make me much healthier. Yes,
> they might have a point if I were baking a cake, but I'm cooking sambal
> goreng hati, and the sugar is a teaspoon at most of gula jawa. There
> isn't enough sugar in the first place that replacing it _could possibly_
> make much of a difference, and the taste _will_ be different because it
> isn't refined sugar.
> Similarly in my code: there just isn't enough _for_ GC to replace that
> it could make that much difference in the first place.
I think I said something about this before but let me say it
again. A major part of the {design,coding} effort that takes
place in a non-automatic memory management environment is not
the malloc()'s and free()'s, but coping with the implications
of all the stuff that is done to avoid having to do memory
management to begin with.
> And what little
> there is, is tightly and automagically coupled to other functions that
> _must not_ be removed lest my database gets corrupted. Hell, in the more
> trivial of my programs I have so little memory management that replacing
> malloc() with GC would be more like replacing the sugar with Stevia in
> my boiled eggs...
Of course. No one is saying the productivity results scale
down to very small programs.
>> Furthermore, the results you expect don't match what has been
>> observed experimentally. In all cases I am aware of where an
>> apples-and-apples comparison is done (meaning, no changes to
>> the language other than how memory allocation is handled),
>> removing the burden of manual memory management gives a
>> significant increase in productivity.
>
> Even when there barely is any manual memory management in the first
> place? I call shenanigans.
I think you're reading something into my comment that I didn't
mean to say. Let me pick an arbitrary number of, say, 10,000
lines of code. No one is going to bother doing any sort of
controlled comparison for programs of 10,000 lines of code or
less, because: (a) the differences are likely to be small in
absolute terms; (b) noise in the measuring process will tend to
drown out whatever signal there is; and (c) the cost of running
the experiment will likely outweigh the payback. What people are
interested in is situations where memory management is thought to
be a significant fraction of overall development cost, and where
the absolute development cost is large. A reasonable guess for a
lower bound is 50-100 KLOC, and an application area that expects
a fair amount of memory allocation. It is only cases where
actual comparisons have been tried that I was talking about, and
these will naturally select for projects where differences are
likely to show up.
> Again, I can see that it would be more important if I wrote code which
> repeatedly and nakedly malloc()ed large amounts of data and had to be
> careful about free()ing it. Even then I'd prefer to automate it under my
> own control rather than trust the GC, but under those circumstances I'd
> believe you if you predicted a decent improvement of productivity.
Note that the numbers I quoted were measurements, not
predictions. There is of course no guarantee that these numbers
will hold in other circumstances. Still, any expectations about
what will happen are better based on empirical evidence than
just on what we think will happen.
> Even
> then I'd never believe 60 to 100%, but still, 10%, sounds plausible.
> But... that's not the kind of code I write. And if it were, I might well
> use another language than C.
I think a lot of people would agree with you on the last point.
Now here is an interesting question: How much is that preference
influenced by a manual-rather-than-automatic mindset for memory
management? That isn't an easy question to answer. There are
some obvious dependencies on several factors: what kind of
application is it, how big is it likely to be, how much
allocation does it do. But there are also less obvious factors.
Notably, the existence (or not) of suitable third-party libraries
sometimes depends on how memory management is done. Simple data
structures in other languages, eg sets and maps, are pretty much
a headache in C, largely because of not having automatic memory
management. Having automatic management available - let me
emphasize, as an option - would help expand the boundary of where
using C makes sense. Is that a good thing? Personally, I think
it is. Even if you think the code that you work on would never
make use of such an option, does that mean the same is true for
other developers and other projects? To me it isn't always yes
or always no - automatic memory management is just another tool
in the bag, to be used if and when appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-07-31 16:42 +0200 |
| Message-ID | <20160731164221.2f1d338d@maxa-pc> |
| In reply to | #91389 |
On Sun, 31 Jul 2016 07:16:58 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: > > There is a common belief in some circles that GC incurs a > substantial performance penalty relative to manual coding of > free(), etc. Experience with actual systems does not bear this > out. Indeed, the experience in some large code bases has been > that switching to GC actually improves performance. Care to show links? I find hardly to believe that deallocation increase performance... Stopping program to perform memory scan and trashing memory in process is faster? how so? Or one doesn't have to stop whole program to perform scan but it must issue synchronization on every pointer access is faster? Language Rust is major point against GC. Language is designed with GC in the beginning, but experience showed against it and they finally dumped GC from language...
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 12:59 -0700 |
| Message-ID | <kfna8gxmve1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91391 |
Melzzzzz <mel@zzzzz.com> writes: > On Sun, 31 Jul 2016 07:16:58 -0700 > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> There is a common belief in some circles that GC incurs a >> substantial performance penalty relative to manual coding of >> free(), etc. Experience with actual systems does not bear this >> out. Indeed, the experience in some large code bases has been >> that switching to GC actually improves performance. > > Care to show links? Unfortunately I don't know any. The only specific examples I know of are proprietary. I am not aware of any where the results are publically available. > I find hardly to believe that deallocation increase > performance... > Stopping program to perform memory scan and trashing memory in process > is faster? how so? I think it's pretty easy to understand. If you do manual deallocation, bookkeeping needs to be done to keep track of what is referenced to know when something can be deallocated. A well-written garbage collector can do a better job of doing that bookkeeping efficiently. That isn't to say that the manual bookkeeping code has to run slower than what the GC does, only that it did in the particular cases. > Or one doesn't have to stop whole program to perform scan but it must > issue synchronization on every pointer access is faster? These days garbage collectors rarely do full memory sweeps. Most of the time they use generational collectors that scan only a very small part of memory. Eventually a point can be reached where a full mark/sweep is needed, but these happen so rarely that they have hardly any impact on performance. > Language Rust is major point against GC. Language is designed with GC > in the beginning, but experience showed against it and they finally > dumped GC from language... I don't know much about Rust, but what I have read indicates that the language does provide some form of automatic deallocation (in particular, it claims to be safe from "dangling pointers"). Using a mark/sweep garbage collector is just one approach to accomplish automatic (and safe) reclamation. In my view the key distinction is whether reclamation is automated (or mostly automated) and always safe. Whether that is done using mark/sweep garbage collection or some other method is relatively unimportant.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-31 17:12 -0500 |
| Message-ID | <nnlsql$7td$1@dont-email.me> |
| In reply to | #91423 |
Tim Rentsch wrote: > Melzzzzz <mel@zzzzz.com> writes: > >> On Sun, 31 Jul 2016 07:16:58 -0700 >> Tim Rentsch <txr@alumni.caltech.edu> wrote: >> >>> There is a common belief in some circles that GC incurs a >>> substantial performance penalty relative to manual coding of >>> free(), etc. Experience with actual systems does not bear this >>> out. Indeed, the experience in some large code bases has been >>> that switching to GC actually improves performance. >> >> Care to show links? > > Unfortunately I don't know any. The only specific examples I > know of are proprietary. I am not aware of any where the > results are publically available. > >> I find hardly to believe that deallocation increase >> performance... >> Stopping program to perform memory scan and trashing memory in process >> is faster? how so? > > I think it's pretty easy to understand. If you do manual > deallocation, bookkeeping needs to be done to keep track of what > is referenced to know when something can be deallocated. No, you simply have to have an explicit context for the lifetime of objects. I personally have never witnessed where this was all that onerous. Most things we do can be chunked into "frames" like that. The principle problem with C++-style new()/delete() is the one that causes RAII to be necessary. I don't consider 'C' to be infected by that. > A > well-written garbage collector can do a better job of doing that > bookkeeping efficiently. That isn't to say that the manual > bookkeeping code has to run slower than what the GC does, only > that it did in the particular cases. > To me, trying to pretend that object lifetime can be automated seems questionable at best. I'm not saying interpreters which use GC are bad, just that this solves a rather small problem <snip> -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 17:12 -0700 |
| Message-ID | <kfnfuqpl53h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91434 |
Les Cargill <lcargill99@comcast.com> writes: > Tim Rentsch wrote: >> Melzzzzz <mel@zzzzz.com> writes: >> >>> On Sun, 31 Jul 2016 07:16:58 -0700 >>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>> >>>> There is a common belief in some circles that GC incurs a >>>> substantial performance penalty relative to manual coding of >>>> free(), etc. Experience with actual systems does not bear this >>>> out. Indeed, the experience in some large code bases has been >>>> that switching to GC actually improves performance. >>> >>> Care to show links? >> >> Unfortunately I don't know any. The only specific examples I >> know of are proprietary. I am not aware of any where the >> results are publically available. >> >>> I find hardly to believe that deallocation increase >>> performance... >>> Stopping program to perform memory scan and trashing memory in process >>> is faster? how so? >> >> I think it's pretty easy to understand. If you do manual >> deallocation, bookkeeping needs to be done to keep track of what >> is referenced to know when something can be deallocated. > > No, you simply have to have an explicit context for the lifetime of > objects. I personally have never witnessed where this was all that > onerous. Most things we do can be chunked into "frames" like that. Certainly that can be done in some cases. I believe there are also cases where it cannot be done, or at least cannot be done without a fair amount of difficulty. I didn't mean to say that getting a performance improvement is typical, only that it does sometimes occur in real cases. >> A >> well-written garbage collector can do a better job of doing that >> bookkeeping efficiently. That isn't to say that the manual >> bookkeeping code has to run slower than what the GC does, only >> that it did in the particular cases. > > To me, trying to pretend that object lifetime can be automated seems > questionable at best. I have found that how I think a system will behave and how it actually behaves are sometimes quite different. That is why whenever possible I prefer to give results from actual experiments rather than thought experiments. > I'm not saying interpreters which use GC are bad, just that this solves > a rather small problem Certainly there are some applications that do not (or would not) benefit from using automatic storage reclamation (eg, garbage collection). But I think there are some that do (or would), and it would be nice to have choice for working in those areas.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-01 00:54 -0500 |
| Message-ID | <nnmntn$4ps$1@dont-email.me> |
| In reply to | #91445 |
Tim Rentsch wrote: > Les Cargill <lcargill99@comcast.com> writes: > >> Tim Rentsch wrote: >>> Melzzzzz <mel@zzzzz.com> writes: >>> >>>> On Sun, 31 Jul 2016 07:16:58 -0700 >>>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>> >>>>> There is a common belief in some circles that GC incurs a >>>>> substantial performance penalty relative to manual coding of >>>>> free(), etc. Experience with actual systems does not bear this >>>>> out. Indeed, the experience in some large code bases has been >>>>> that switching to GC actually improves performance. >>>> >>>> Care to show links? >>> >>> Unfortunately I don't know any. The only specific examples I >>> know of are proprietary. I am not aware of any where the >>> results are publically available. >>> >>>> I find hardly to believe that deallocation increase >>>> performance... >>>> Stopping program to perform memory scan and trashing memory in process >>>> is faster? how so? >>> >>> I think it's pretty easy to understand. If you do manual >>> deallocation, bookkeeping needs to be done to keep track of what >>> is referenced to know when something can be deallocated. >> >> No, you simply have to have an explicit context for the lifetime of >> objects. I personally have never witnessed where this was all that >> onerous. Most things we do can be chunked into "frames" like that. > > Certainly that can be done in some cases. I believe there > are also cases where it cannot be done, or at least cannot > be done without a fair amount of difficulty. I didn't > mean to say that getting a performance improvement is > typical, only that it does sometimes occur in real cases. > I'm not sure what you're after here. Most 'C' programs I've used may use dynamic ( or, more probably semi-dynamic) allocation behind the scenes but applications I've dealt with largely tended to accumulate a set of buffers and working storage, and after a short while, became memory-stable. For the curious, this does indeed include things that have significant levels of dynamically configured objects that get created and destroyed. You can often see the same sort of approach taken in the Linux kernel - configuration options for the maximum number of object <x> are part of the kernel build. This creates arrays that are then dynamically used. This is just a very 'C' thing to do. >>> A >>> well-written garbage collector can do a better job of doing that >>> bookkeeping efficiently. That isn't to say that the manual >>> bookkeeping code has to run slower than what the GC does, only >>> that it did in the particular cases. >> >> To me, trying to pretend that object lifetime can be automated seems >> questionable at best. > > I have found that how I think a system will behave and how it > actually behaves are sometimes quite different. That is why > whenever possible I prefer to give results from actual > experiments rather than thought experiments. > Sure. >> I'm not saying interpreters which use GC are bad, just that this solves >> a rather small problem > > Certainly there are some applications that do not (or would not) > benefit from using automatic storage reclamation (eg, garbage > collection). But I think there are some that do (or would), > and it would be nice to have choice for working in those areas. > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-01 08:08 -0700 |
| Message-ID | <kfnlh0gjzll.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91454 |
Les Cargill <lcargill99@comcast.com> writes: > Tim Rentsch wrote: >> Les Cargill <lcargill99@comcast.com> writes: >> >>> Tim Rentsch wrote: >>>> Melzzzzz <mel@zzzzz.com> writes: >>>> >>>>> On Sun, 31 Jul 2016 07:16:58 -0700 >>>>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>>> >>>>>> There is a common belief in some circles that GC incurs a >>>>>> substantial performance penalty relative to manual coding of >>>>>> free(), etc. Experience with actual systems does not bear this >>>>>> out. Indeed, the experience in some large code bases has been >>>>>> that switching to GC actually improves performance. >>>>> >>>>> Care to show links? >>>> >>>> Unfortunately I don't know any. The only specific examples I >>>> know of are proprietary. I am not aware of any where the >>>> results are publically available. >>>> >>>>> I find hardly to believe that deallocation increase >>>>> performance... >>>>> Stopping program to perform memory scan and trashing memory in process >>>>> is faster? how so? >>>> >>>> I think it's pretty easy to understand. If you do manual >>>> deallocation, bookkeeping needs to be done to keep track of what >>>> is referenced to know when something can be deallocated. >>> >>> No, you simply have to have an explicit context for the lifetime of >>> objects. I personally have never witnessed where this was all that >>> onerous. Most things we do can be chunked into "frames" like that. >> >> Certainly that can be done in some cases. I believe there >> are also cases where it cannot be done, or at least cannot >> be done without a fair amount of difficulty. I didn't >> mean to say that getting a performance improvement is >> typical, only that it does sometimes occur in real cases. > > I'm not sure what you're after here. Most 'C' programs I've used > may use dynamic ( or, more probably semi-dynamic) allocation behind > the scenes but applications I've dealt with largely tended to > accumulate a set of buffers and working storage, and after a short > while, became memory-stable. > > For the curious, this does indeed include things that have significant > levels of dynamically configured objects that get created and > destroyed. You can often see the same sort of approach taken in the > Linux kernel - configuration options for the maximum number of object > <x> are part of the kernel build. This creates arrays that are then > dynamically used. > > This is just a very 'C' thing to do. Obviously the behavior depends a lot on the application. At one end of the spectrum, a program to do base64 encoding/decoding is likely to need essentially zero allocated memory. Closer to the other end of the spectrum, a web browser is going to need new memory every time a new web page is opened (and ideally discard it when the page is closed). As a rule in my own browser usage, I always open news tabs, and hardly ever close them. (Of course I do close most of them eventually, but not right away.) Somewhere in between the end points we might put a compiler. It starts off using a small amount of memory, and allocates as it reads more source. Then there is more allocation during semantic analysis to do type checking, optimization, checks for warning conditions, etc. Of course a compiler might adopt a strategy of simply never deallocating, which is probably workable in some cases. But that's just a poor man's GC - if a program is going to call malloc() and never call free(), assuming it doesn't hide pointers in some sneaky way then it might as well take advantage of drop-in conservative collector, which could allow it to compile larger programs than it could otherwise. Long story short: yes, it depends on the application. But in general the larger the application the more likely it is to be doing a lot of allocation and deallocation, and the more likely it is that deallocation doesn't follow an easily predictable pattern. If we weight our samples by how many lines of code are involved, I think most of the code will allocating and deallocating a fair amount. Do you agree with that, or disagree? Your example of the Linux kernel is a good one. However, I think it is not typical of most large C programs.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-01 12:58 -0500 |
| Message-ID | <nno29s$csj$1@dont-email.me> |
| In reply to | #91487 |
Tim Rentsch wrote: > Les Cargill <lcargill99@comcast.com> writes: > >> Tim Rentsch wrote: >>> Les Cargill <lcargill99@comcast.com> writes: >>> >>>> Tim Rentsch wrote: >>>>> Melzzzzz <mel@zzzzz.com> writes: >>>>> >>>>>> On Sun, 31 Jul 2016 07:16:58 -0700 >>>>>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>>>> >>>>>>> There is a common belief in some circles that GC incurs a >>>>>>> substantial performance penalty relative to manual coding of >>>>>>> free(), etc. Experience with actual systems does not bear this >>>>>>> out. Indeed, the experience in some large code bases has been >>>>>>> that switching to GC actually improves performance. >>>>>> >>>>>> Care to show links? >>>>> >>>>> Unfortunately I don't know any. The only specific examples I >>>>> know of are proprietary. I am not aware of any where the >>>>> results are publically available. >>>>> >>>>>> I find hardly to believe that deallocation increase >>>>>> performance... >>>>>> Stopping program to perform memory scan and trashing memory in process >>>>>> is faster? how so? >>>>> >>>>> I think it's pretty easy to understand. If you do manual >>>>> deallocation, bookkeeping needs to be done to keep track of what >>>>> is referenced to know when something can be deallocated. >>>> >>>> No, you simply have to have an explicit context for the lifetime of >>>> objects. I personally have never witnessed where this was all that >>>> onerous. Most things we do can be chunked into "frames" like that. >>> >>> Certainly that can be done in some cases. I believe there >>> are also cases where it cannot be done, or at least cannot >>> be done without a fair amount of difficulty. I didn't >>> mean to say that getting a performance improvement is >>> typical, only that it does sometimes occur in real cases. >> >> I'm not sure what you're after here. Most 'C' programs I've used >> may use dynamic ( or, more probably semi-dynamic) allocation behind >> the scenes but applications I've dealt with largely tended to >> accumulate a set of buffers and working storage, and after a short >> while, became memory-stable. >> >> For the curious, this does indeed include things that have significant >> levels of dynamically configured objects that get created and >> destroyed. You can often see the same sort of approach taken in the >> Linux kernel - configuration options for the maximum number of object >> <x> are part of the kernel build. This creates arrays that are then >> dynamically used. >> >> This is just a very 'C' thing to do. > > Obviously the behavior depends a lot on the application. At one > end of the spectrum, a program to do base64 encoding/decoding is > likely to need essentially zero allocated memory. Closer to the > other end of the spectrum, a web browser is going to need new > memory every time a new web page is opened (and ideally discard > it when the page is closed). So the total number of web browsers in the world probably fits in one digit. This is hardly an argument for a language system providing all the support for that level of dynamic-ness. > As a rule in my own browser usage, > I always open news tabs, and hardly ever close them. (Of course > I do close most of them eventually, but not right away.) I close them as soon as I'm done. I have little doubt that they leak memory, at least in terms of how the instrumentation for "memory used" is concerned. I can close the whole thing ( after individually closing tabs) and memory used drops. But there's a hunk of the executable that stays resident after. > Somewhere in between the end points we might put a compiler. > It starts off using a small amount of memory, and allocates as > it reads more source. Then there is more allocation during > semantic analysis to do type checking, optimization, checks > for warning conditions, etc. Of course a compiler might adopt > a strategy of simply never deallocating, which is probably > workable in some cases. But that's just a poor man's GC - > if a program is going to call malloc() and never call free(), > assuming it doesn't hide pointers in some sneaky way then > it might as well take advantage of drop-in conservative > collector, which could allow it to compile larger programs > than it could otherwise. > "A compiler" is generally multiple executables. Each has a pretty proscribed, even pipe-ey task to perform. They're kinda "stream in, stream out" sorts of programs. > Long story short: yes, it depends on the application. But > in general the larger the application the more likely it is > to be doing a lot of allocation and deallocation, and the > more likely it is that deallocation doesn't follow an easily > predictable pattern. So color me less than sympathetic. It all just sounds like people throwing up their hands to me. If I have a point, it is that developing a culture of rational ignorance about object lifetimes seems risky to me. I *perceive* this as an artifact of people being...traumatized by memory leaks in their CS 101 phase and becoming somewhat over-sensitive to it. Or something. In the larger scheme of things, it's a sufficiently proscribed problem that we believe it can be automated, so it should not be too much afraid of doing in in other ways, if that makes any sense in the first place. And to be even more specific, I own things that obviously run Java and they tend to be less reliable than the things that run 'C'. I have a BluRay player and you have to unplug it from the wall now and again and let all the "memory to go a ground state" type thing. > If we weight our samples by how many > lines of code are involved, I think most of the code will > allocating and deallocating a fair amount. Do you agree > with that, or disagree? > I have to admit that I only know on a shallow level. > Your example of the Linux kernel is a good one. However, > I think it is not typical of most large C programs. > Yeah, it could easily be a bias - most things I do are closer to your base64 converter. They may be in user space, but they tend to be very "driver-ey". -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-01 12:25 -0700 |
| Message-ID | <270499a2-bfaa-4ab2-bb5a-b5a31d7d0e01@googlegroups.com> |
| In reply to | #91504 |
On Monday, August 1, 2016 at 6:53:09 PM UTC+1, Les Cargill wrote: > Tim Rentsch wrote: > > > If we weight our samples by how many > > lines of code are involved, I think most of the code will > > allocating and deallocating a fair amount. Do you agree > > with that, or disagree? > > > > I have to admit that I only know on a shallow level. > It just depends on the programs. Many programs take N at invocation or in response to relatively rare user inputs, and can certainly be written so that they allocate all required memory at that point. However often that adds complexity. If you want a median, to take a simple example, you can specify that the input shall be corrupted, or you can write it to find the median by binary search, but the easy and obvious way to write the function is to take a copy of the input, sort it, then return the middle value or values. So you often find that code does quite a bit of allocation and reallocation, to allow functions to scale without being passed workspace. But not all programs, by any means.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web