Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: "Forth is Sudoku for programmers" Date: Sat, 13 Aug 2016 21:53:12 -0700 Organization: A noiseless patient Spider Lines: 49 Message-ID: <87k2fkvtmv.fsf@jester.gateway.pace.com> References: <1e1c16c6-300f-4c4f-8590-379029478232@googlegroups.com> <-pednXDWiZK50jDKnZ2dnUU7-bfNnZ2d@supernews.com> <8cb43dc0-f642-442f-b2ce-72650caa544b@googlegroups.com> <37e2ee67-95ab-4f05-9f30-30c4e89059ab@googlegroups.com> <9f9b8329-a9c7-4eee-a09c-cdae3b30ae68@googlegroups.com> <007681f6-8931-4f83-9b38-1ab0741d663b@googlegroups.com> <4ca2cd93-3d8a-4d6f-8fa5-c50b68bbf286@googlegroups.com> <57ae8058$0$292$14726298@news.sunsite.dk> <50343a03-5565-4931-8025-1668726797c6@googlegroups.com> <065b6c2a-66ea-4f31-998d-e50f6b9ebd7e@googlegroups.com> <1f719a0d-3e81-48d3-8a49-ae06b189babe@googlegroups.com> <878tw1xi2y.fsf@jester.gateway.pace.com> <57af05e8$0$303$14726298@news.sunsite.dk> <43c75549-01ee-4b62-bad5-21596ff0ad95@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="afb9df5a762ad8974cbd7e506bdf03a5"; logging-data="15705"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19aEg9vC4IE0yijZC+cq1Zu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:LVIIa4nRty4gVlkcNiCvLOnJ8pc= sha1:SIyxyLUag4hppmDso+16lQQ7qpY= Xref: csiph.com comp.lang.forth:50079 Julian Fondren writes: > I suspect - just based on usage by different programming languages, > for example, anything used by Python is suspect - that reference > counting isn't great for performance, in addition to its other > problems, but I didn't look hard for sources on that. Refcounting in single threaded CPython works ok. It has caused a lot of pain with multi-threading because have to put locks around the refcounts (killing performance in the single threaded case), or lock the whole interpreter (the infamous Global Interpreter Lock or GIL) when executing bytecodes. One "advantage" of refcounts was that objects are freed as soon as the last reference disappeared, so people relied on that for timely release of stuff like file descriptors, a lame style imho. Later the "with" statement was added to Python which explicitly releases stuff at the end of its scope, which is preferable. Micropython uses pure gc instead of refcounts, if that matters. > http://codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html That article is pretty unpersuasive. C++ smart pointers work pretty well if you remember that C++ is a totally different language than C and don't use legacy C stuff in your program. The refcounted pointers are useful when they are needed, but unique_ptr is good enough most of the time, and has almost no overhead. unique_ptr means the pointer has a single owner, so the object is freed when the owner goes out of scope, unless you transfer the ownership to another unique_ptr first. C++ std::shared_ptr (the ref counted ones) do have locks around the refcounts, which must be expensive. I believe Seastar has its own version of shared_ptr that can't be shared across threads, so that would get rid of the need for locks. There's some hooks in C++ for a real GC but I don't know of any implementations or what the obstacles to them are. But, part of the idea of C++ is to control your program's memory resources. If you want a GC'd language you might as well use one designed for GC from the start. > You can find a conservative GC for Forth at: > http://www.complang.tuwien.ac.at/projects/forth.html Yes, that's way cool. >> * The reference must reside on the data stack,.... I would have liked >> to add the return and locals stack, but unfortunately there is no >> standard way to access them, so they are out. I think it's worth supporting the return and locals stack in specific implementations using carnal knowledge of those implementations.