Announcement

Collapse
No announcement yet.

Initial Patches Wire In C++20 Coroutines For The GCC Compiler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by discordian View Post
    C++ can allocate objects on stack (amortized cost: 0 instructions), Clang can remove new/delete (and reuse memory or the stack, see N3664)
    Opportunities for doing so in C++ are limited. A static compiler does not have enough information to know for sure that a pointer to an object can't escape due to method overriding. A dynamic compiler can do this kind of analysis repeatedly while the code is running.

    Originally posted by discordian View Post
    if you think deallocation is anything close to free, you have no idea how GC works. The work is shifted to finding the objects you can free/reuse, just because you cant measure it in a short loop doesn't mean elsewhere CPU cycles arent wasted, cold memory has to be brought in (whether you actually find anything useful or not), further allocations might happen during deallocation.
    If you ever wondered why a Java app you havent used in a while will totally bog down when you open it up again: Thats the GC running over the whole process space.
    You should get a refund from whatever school you got your education from. Most objects that are allocated are not long-lived, they become garbage very quickly. What that means in practice is that since a generational GC only pays attention to live objects, dead objects do not contribute anything to the cost of collection. (they are ignored during compaction) Since over 95% of objects fall into this category, deallocation is virtually free.

    Comment


    • #32
      Originally posted by pal666 View Post
      c++ doesn't lack a gc. it doesn't require gc, but it can use gc(and gcc itself uses gc, jvm itself is c++ app which uses gc). and surely it can do object allocation even faster with proper allocator. there is no garbage collector without overhead. you either have huge runtime one, or huge memory one (or both). and c++ doesn't need garbage collector because it doesn't produce garbage
      A copying GC is faster than malloc at allocations, largely because it does compaction. Thus there is no maintenance of a "free list". Free memory is a contiguous block, which means that allocation is as simple as checking if there is free memory in the heap and if so, moving a pointer. Of course C++ produces garbage, the difference is that you have to clean it up yourself.

      Comment


      • #33
        Originally posted by cynical View Post
        Opportunities for doing so in C++ are limited. A static compiler does not have enough information to know for sure that a pointer to an object can't escape due to method overriding. A dynamic compiler can do this kind of analysis repeatedly while the code is running.
        And of course this analysis does not run on a CPU, hence its free?

        Originally posted by cynical View Post
        You should get a refund from whatever school you got your education from. Most objects that are allocated are not long-lived, they become garbage very quickly. What that means in practice is that since a generational GC only pays attention to live objects, dead objects do not contribute anything to the cost of collection. (they are ignored during compaction) Since over 95% of objects fall into this category, deallocation is virtually free.
        Read up what "heuristic" means, and how your generational GCs have to deal with it. Maybe you would have arguments then and not need to resort to petty insults.
        Short-lived objects end up on the stack, or in a private pools in C++, there is no need for tracing origins, continuously shuffling groups and making bad guesses at whether the object is alive - all having a runtime cost.

        Comment


        • #34
          Originally posted by discordian View Post
          And of course this analysis does not run on a CPU, hence its free?
          Of course it is not free, but it lets you change heap allocations to stack allocations where C++ cannot even think to do so. You think they would have this kind of analysis in the JVM if the performance benefit wasn't greater than the cost? It would be simpler not to have it at all lol.

          Originally posted by discordian View Post
          Read up what "heuristic" means, and how your generational GCs have to deal with it. Maybe you would have arguments then and not need to resort to petty insults.
          Short-lived objects end up on the stack, or in a private pools in C++, there is no need for tracing origins, continuously shuffling groups and making bad guesses at whether the object is alive - all having a runtime cost.
          Umm, I'm talking about the heuristic. You really should know about GCs if you are going to criticize someone's knowledge of them. By private pool, are you referring to a custom allocator? Do I really need to explain why a GC is better? I mean, what you are saying is that you are going to throw out any chance of portability to compete with Java's GC lol. Yes sure, you can optimize for a particular case, but then you are dealing with all the downsides of optimization.

          Have you ever considered why malloc or free list allocators exist, when their performance is always worse than writing a custom one? Just think about it for a minute. Also, you don't need to guess if an object is alive, you just follow references until you don't have any. Yes you have runtime costs, but so do C++ memory allocators. You also have to deal with situations that Java doesn't, like memory fragmentation.

          The biggest benefit imo is that in Java, all of this is done automatically for you whether you are a good programmer or not. You get excellent performance and you can solve your problem directly instead of worrying about details that are not relevant to the problem at hand.

          Comment


          • #35
            Originally posted by cynical View Post
            Of course it is not free, but it lets you change heap allocations to stack allocations where C++ cannot even think to do so. You think they would have this kind of analysis in the JVM if the performance benefit wasn't greater than the cost?
            If you can prove an allocation can be on the stack in a dynamic context, then you can prove it in a static context even easier.
            Goes with pretty much everything JIT'ers do, static can do everything and way more. The only advantage would be if you can use optimizations that weren't active on the static compilation.
            Originally posted by cynical View Post
            It would be simpler not to have it at all lol.
            Yeah, that's why JIT'ers barely do anything but a single one-time compilation, the rest are still theoretical pipedreams.

            Originally posted by cynical View Post
            Umm, I'm talking about the heuristic. You really should know about GCs if you are going to criticize someone's knowledge of them.
            Do I really have to spell it out? The heuristic will leave dead objects around, and GCs will still do a mark and sweep regularly. I t doesnt matters how few objects are classified wrong, you have to look at all of them to find those few.
            Originally posted by cynical View Post
            By private pool, are you referring to a custom allocator? Do I really need to explain why a GC is better? I mean, what you are saying is that you are going to throw out any chance of portability to compete with Java's GC lol. Yes sure, you can optimize for a particular case, but then you are dealing with all the downsides of optimization.
            You have to write really really bad C++ so that Java even has a chance of competing. Sure, using a GC is easier to write, and you don't have to know anything about managing resources, you can consider that an advantage. But then I would just use Python. And talking about performance while dissing optimization?

            Originally posted by cynical View Post
            Have you ever considered why malloc or free list allocators exist, when their performance is always worse than writing a custom one? Just think about it for a minute. Also, you don't need to guess if an object is alive, you just follow references until you don't have any. Yes you have runtime costs, but so do C++ memory allocators. You also have to deal with situations that Java doesn't, like memory fragmentation.
            The point is, you can use custom allocators - and that rather easily, there are alot usecases like parsing an XML file, getting/copying the contents you need and then just deallocate a single blob of memory not thousands of objects. How hard is that to do? just download RapidXML and use it, you might not even know why its that fast.

            Originally posted by cynical View Post
            The biggest benefit imo is that in Java, all of this is done automatically for you whether you are a good programmer or not. You get excellent performance and you can solve your problem directly instead of worrying about details that are not relevant to the problem at hand.
            Moving goalposts? Yeah, Id like inepts staying with Java and not polluting threads about C++ with their lack of knowledge.

            Comment


            • #36
              Originally posted by discordian View Post
              If you can prove an allocation can be on the stack in a dynamic context, then you can prove it in a static context even easier.
              Goes with pretty much everything JIT'ers do, static can do everything and way more. The only advantage would be if you can use optimizations that weren't active on the static compilation.
              It's the exact opposite. JITs have runtime information that static compilers cannot have, while they also know everything that static compilers do. If you don't see how a runtime mechanism can have more information than a static mechanism that is only looking at your source code, there is nothing I can say to convince you otherwise.

              Originally posted by discordian View Post
              Yeah, that's why JIT'ers barely do anything but a single one-time compilation, the rest are still theoretical pipedreams.
              Ah that makes sense. You think they don't do anything more than static compilers anyway.

              Originally posted by discordian View Post
              Do I really have to spell it out? The heuristic will leave dead objects around, and GCs will still do a mark and sweep regularly. I t doesnt matters how few objects are classified wrong, you have to look at all of them to find those few.
              If by regularly, you mean rarely... then sure. And? Have you ever heard of amortization?

              Originally posted by discordian View Post
              You have to write really really bad C++ so that Java even has a chance of competing. Sure, using a GC is easier to write, and you don't have to know anything about managing resources, you can consider that an advantage. But then I would just use Python. And talking about performance while dissing optimization?
              I wasn't dissing optimization, I was saying that optimization comes with tradeoffs. Like when you use that "one neat trick" to make C++ faster but harder to comprehend, and the standard is updated so that the common case actually ends up faster later, while being easier to understand. Most times that people do optimization it isn't because their program needs it to do the job, they are doing it because they think they are clever.

              Originally posted by discordian View Post
              The point is, you can use custom allocators - and that rather easily, there are alot usecases like parsing an XML file, getting/copying the contents you need and then just deallocate a single blob of memory not thousands of objects. How hard is that to do? just download RapidXML and use it, you might not even know why its that fast.
              Well yeah because you are forced to, since C++ doesn't have fast object allocations by default. Java does.

              Originally posted by discordian View Post
              Moving goalposts? Yeah, Id like inepts staying with Java and not polluting threads about C++ with their lack of knowledge.
              Not everyone likes to solve the same boring memory problems again and again. Clearly you do, so have fun!

              Comment


              • #37
                Originally posted by cynical View Post
                A copying GC is faster than malloc at allocations, largely because it does compaction. Thus there is no maintenance of a "free list". Free memory is a contiguous block, which means that allocation is as simple as checking if there is free memory in the heap and if so, moving a pointer.
                does anything from this text contradict my "there is no garbage collector without overhead. you either have huge runtime one, or huge memory one (or both)." ? no, it doesn't. i didn't discuss speed of malloc. i discussed memory management overhead. 1) that includes not only allocation time 2) that includes not only time. i literally spelled it that gc can gain some speed by wasting more memory. why do you post something completely irrelevant? and 3) c++ doesn't have to use malloc. i.e. malloc is the slowest allocation strategy out of available to c++ program. there are much better ones
                Originally posted by cynical View Post
                Of course C++ produces garbage, the difference is that you have to clean it up yourself.
                i'm sure it does produce garbage in your hands. in hands of people who know how to use c++ it doesn't. "have to clean it up youself" is clear sign of someone who shouldn't be allowed to write c++ code. if you have to cleanup something yourself, you are doing it in non-c++ way. and btw "garbage" which isn't produced by c++, refers not to just memory, it refers to any resource. while inferior languages for inferior developers can only garbage collect memory, leaving all other kinds of garbage uncollected. and even there they trip over trivial stuff like publish-subscribe pattern
                Last edited by pal666; 22 November 2019, 10:23 PM.

                Comment


                • #38
                  Originally posted by pal666 View Post
                  does anything from this text contradict my "there is no garbage collector without overhead. you either have huge runtime one, or huge memory one (or both)." ? no, it doesn't. i didn't discuss speed of malloc. i discussed memory management overhead. 1) that includes not only allocation time 2) that includes not only time. i literally spelled it that gc can gain some speed by wasting more memory. why do you post something completely irrelevant?
                  You missed my point. You are dealing with heap-allocated reference types instead of primitive, stack-allocated types, right? Which means you must track and manage that memory somehow. There is no escape from that. The overhead is always going to be there because there is always an overhead in dealing with references, so the question is not if you have overhead or not, it's what form the overhead takes.

                  If you aren't dealing with GC overhead, then you are dealing with memory fragmentation or the overhead of your chosen allocation/deallocation method. (which on Java is low by default and needs no intervention from you)

                  Originally posted by pal666 View Post
                  and 3) c++ doesn't have to use malloc. i.e. malloc is the slowest allocation strategy out of available to c++ program. there are much better ones
                  Wow brilliant, so you can write a custom allocator. Why does malloc exist then?

                  Right, because 99% of the time it's not worth it to write your own. So the point of my post is that 99% of the time, the JVM is doing a better job than you and your malloc. If you want to optimize, great but then that's time you are spending on writing something that is not portable and is ancillary to the problem at hand. It's also terrible software engineering practice, unless it is absolutely required, for the same reason it's terrible to write everything yourself instead of just using libraries that have been thoroughly vetted.

                  Custom allocators also don't necessarily provide the benefit people think. It's more like folklore.

                  Originally posted by pal666
                  i'm sure it does produce garbage in your hands. in hands of people who know how to use c++ it doesn't.


                  Originally posted by pal666
                  "have to clean it up youself" is clear sign of someone who shouldn't be allowed to write c++ code. if you have to cleanup something yourself, you are doing it in non-c++ way. and btw "garbage" which isn't produced by c++, refers not to just memory, it refers to any resource. while inferior languages for inferior developers can only garbage collect memory, leaving all other kinds of garbage uncollected. and even there they trip over trivial stuff like publish-subscribe pattern
                  Writing destructors is still having to clean it up yourself, even if you aren't freeing explicitly. It's 2019 man, there's no reason for developers to be doing that crap manually anymore. We've had enough security problems related to mismanaging memory... Even Rust sets the proper example. You think Java doesn't have a way of dealing with resources automatically? Treating resources the same way you treat local memory is dumb anyway. And what's complicated about publish-subscribe?

                  I'm not even trying to come across as a defender of Java. It's a good language, but it is far from my favorite or what I would want to use daily. But outside of kernel development or gaming, Java is vastly superior. In terms of safety, it's not even close.

                  Edit: Besides, it's a dumb discussion anyway. Nowadays you can use something like GraalVM to natively compile Java or other higher level languages, so you get the benefits of the safety + the same efficiency you expect of C++.
                  Last edited by cynical; 25 November 2019, 03:51 PM.

                  Comment


                  • #39
                    Originally posted by cynical View Post
                    On Github or wherever, but I was thinking deployed code.
                    You literally said "popular language". By some measurements, like google searches, python is the most popular.

                    But OK, "deployed code". How do you define that? Pretty much every distribution ships with python code for example. Very few ship with java. I could count that as "deployed".

                    Or do some deployments matter more to you than others?

                    Comment


                    • #40
                      Originally posted by fuzz View Post

                      You literally said "popular language". By some measurements, like google searches, python is the most popular.

                      But OK, "deployed code". How do you define that? Pretty much every distribution ships with python code for example. Very few ship with java. I could count that as "deployed".

                      Or do some deployments matter more to you than others?
                      No, I literally said "most popular language to write in". Glue code that ships with Linux obviously doesn't count. I mean it counts once because someone wrote it, but I'm not counting the deployment of a million Linux distributions the same as the deployment of a million individual code bases. Google searches are obviously not a good metric... I mean for one thing, you are more likely measuring how popular a certain breed of snake is. Github is also terrible since much of what you are measuring is glue code used in many projects that might be mostly in C++ or some other language.

                      The language that dominates for back-end servers and now mobile applications is clearly Java. Look at the number of unique applications in the Android app store, and add to that all the code developed in enterprise situations. I don't think any other language comes close except for JavaScript because of it's special relationship to the web.

                      Comment

                      Working...
                      X