Announcement

Collapse
No announcement yet.

How A KDE Developer Used C++17 & Boost.Python For About A 8,000x Speed-Up

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

  • #51
    Originally posted by starshipeleven View Post
    So, you really think that if people stopped using lesser languages like Python we would get more programs written in superior languages like C++?

    That's... not going to happen. As in all cases where someone advocates removing the "competition" to strenghten their own pet project. In practice you would just end up with less available stuff, as people working in the "competitors" will very likely never merge with your pet project, but just disappear. None wins, all lose.
    No, we'll have less available stuff. That's a good thing. Quality over quantity after all.

    Originally posted by starshipeleven View Post
    Guess what? even a shitty program is better than no program. And people is still very happy about that.
    Not at all. In many cases (especially in Windows because it has 90% of the software ecosystem, not hating), there's *way* too much redundant software. In many cases you aren't even aware of the great C/C++ alternative to some Python app because there's too fucking many.

    So yeah, trim off the fat and the stupid shitty Python (or whatever) "alternative" projects made by an inexperienced guy from existence. Then we'll all have only quality to choose from. Sometimes less to choose from is better when there's simply way too many choices, objectively inferior (use more resources etc).

    Originally posted by starshipeleven View Post
    Technically speaking this is correct. Programming is "teaching someone to do some job", which is basically logic and ability to communicate your intentions. Most people are able to do this to some extent because it's a basic life skill, so get off that horse plz.

    Mastering a programming language is a different thing, just like mastering English writing skills. Not everyone can be an awesome writer, but with languages like Python everyone can actually write something a PC can read, to do some complex job, this isn't a small feat.
    Intentions like not even understanding basic things as managing your own resources? This is tedious only for people who lack the capacity to do it. Hardware development takes logic and ability as well and yet they don't have the same "privilege" of easy-going as most software devs.

    English is a good example. If I went to a library and 90% of the books were in broken English because "everyone can understand crap quality and bad English! let them write!!" that would be deserving a hall of shame.

    I don't care if by removing 90% of the bad English books from people with poor grammar you have only 10% left in the library. At least the library will have quality: when you look and browse, you know all the books are in proper English. You don't waste time or even worse, manage to pick up a bad English book and can't find the rare good one on the same subject. It just makes finding the good ones a needle in a haystack kind of thing, when there's too much junk.

    Hey, my English is not perfect nor native, but I don't claim to be an English writer, nor do I pollute people who want quality books with my crap writing. Don't excuse the software writers, they shouldn't get any.

    Originally posted by starshipeleven View Post
    Modern drives are huge, it makes no sense to allocate the very scarce time/resources most developers have on optimizing what is a very secondary thing.
    Maybe the modern drives (or space wasted) should be paid by the developers for the millions of users they infect their garbage with. Then, maybe they'll learn to appreciate product quality instead of their shitty selves (unless it's open source / free).

    Furthermore, it takes time to load that crap and not everyone has SSDs or want to use up space on their SSDs for someone's bloated junk. A 50MB crappy thing would take half a second to load the first time in a typical HDD. Unacceptable.

    Comment


    • #52
      Originally posted by kpedersen View Post
      I never have this problem. Mostly because I start every project in C or C++.
      ...
      I'm finding Python useful as prototyping language that can be fairly easily translated into C++.

      The problem as I see with Python is lack of whole program parsing when i run a script: a branch can have syntax errors and they only show up when the branch is executed. A C or C++ compiler will simply reject a file with bad syntax, the linker will bork on unresolved symbols.

      Comment


      • #53
        Originally posted by starshipeleven View Post
        Really I'm going to be very blunt with this, all this rhetoric just does not fly in my vicinity.

        So, you really think that if people stopped using lesser languages like Python we would get more programs written in superior languages like C++?

        That's... not going to happen. ...
        Lot of good points you make, and I'm speaking as someone who thinks C++ really is the King of languages! It's a subtle and in some ways complex language, for a lot of stuff I don't need it's precision or picky-ness and I use Python or cmdline PHP instead.

        Comment


        • #54
          Originally posted by stibium View Post

          GCC compile flags are bad enough but C++ devs have to grapple with even more esoteric declarations in the code? Spoken languages might need dictionaries to use well, but you shouldn't need to keep a library of C++ encyclopedias because the compiler is too lazy to know what native tuning is. Ridiculous things like this is why I'm glad I noped out of C++ and stuck with C.
          Look at it this way:

          Practical C or C++ programmers use types like int32_t or uint32_t or int64_t (so we at least know the variable is x number of bits) and then compile with -O2 or -O3. They leave the command line option esoterica to language lawyers and such people.

          OTOH C and C++ are third gen languages, they're pretty close to the metal. So all those options can be useful in the right situation.

          Comment


          • #55
            Originally posted by Michael_S View Post
            *snip*
            Java has stack allocations, what makes it do more heap allocations than C# or other languages? I've never heard this before.

            My understanding, which could be wildly wrong, is that Java uses a lot of memory for this reason: .NET and many similar programs do Just-in-Time (JIT) compilation of any given piece of code once, and then continue using the JIT-ed results until program exit. Java does JIT and adds monitoring instrumentation as it runs code, and after a certain number of executions run through any particular function - usually 10,000 or so - it will examine the profiled results and decide whether to re-JIT it with different optimizations to improve performance. If you read about Java server total throughput benchmarking, all of the websites and books recommend running the benchmark software for a little while and not collecting any results. Once the code has run long enough that the first pass of instrumentation, monitoring, and if necessary revising the JIT has passed then start collecting performance data.

            (Edit: to be clear, I'm 99% sure the runtime continuous profiling and optimization I described is part of the Java Virtual Machine and adds to the JVM's memory usage. I'm considerably less sure that it is the reason Java is so memory-hungry compared to .NET.)
            In Java you have Primitive types that are allocated on the stack, and Class types that are allocated on the heap, nothing more, nothing less. In .NET you have an additional type that is Struct which is a stack allocated Class (the difference being "invisible" to the user of the Struct/Class other than for the sake of performance, although there are limitations on the person writing it).

            In OOP software it is exceedingly rare that you're just going to use a Primitive type on its own rather than being wrapped up in a more complex data type for example say you want to represent a complex number, your type would be:
            Code:
            class Complex {
                double real;
                double imaginary;
            };
            In Java that now has to be heap allocated. whereas in C# I can declare it to be a struct and follow the rules around "value types" and I can still use it on the stack like I could in C++ or similar languages. Obviously if I then include that complex struct in a class it then goes onto the heap with the enclosing object. What this means is that you save on unnecessarily generating a bunch of garbage in C# vs Java because in C# the stack handles it for you in those cases, whereas Java requires the Garbage Collector to do it. In C++ you make the active choice as the user of the type whether you'd prefer stack allocation or heap allocation.

            There's a variety of other much smaller things that add further to the memory efficiency of C# vs Java such as having unsigned types, and letting you choose which methods are virtual, but while a few bytes saved here and there does have a cumulative effective, that's not quite on the same scale as whole objects.

            You'll also note that in equivalent real programs C# and C++ use roughly the same amount of memory. In toys you can make C++ use vastly less memory but in the real world C++ memory management is done through schemes like parent-child hierarchies, reference counting smart pointers, etc, and thus you retain the same pointer overhead that you would if you were using a garbage collector. Meanwhile Java uses multiple times more memory.

            As to what you're talking about, both the JVM and CLR do roughly the same set of tricks (No surprise there as the CLR and C# were Microsoft's take on the JVM and Java). There are differences but it's not exactly like Java is doing some extra super memory consumptive magic sauce to improve their performance vs C#, especially as these are very long standing traits of the two languages.

            Comment


            • #56
              Originally posted by hoohoo View Post
              I'm finding Python useful as prototyping language that can be fairly easily translated into C++.

              The problem as I see with Python is lack of whole program parsing when i run a script: a branch can have syntax errors and they only show up when the branch is executed. A C or C++ compiler will simply reject a file with bad syntax, the linker will bork on unresolved symbols.
              My experience has been that it does do whole-program parsing... it's just that the vast majority of errors are not syntax errors but, rather, errors which can only be caught at runtime because the language is too dynamic. (Same problem as JavaScript has in that respect)

              You might want to try MyPy. (It's a verifier for Python's optional type annotations that serves a role similar to TypeScript.)

              Comment


              • #57
                Originally posted by Luke_Wolf View Post

                In Java you have Primitive types that are allocated on the stack, and Class types that are allocated on the heap, nothing more, nothing less. In .NET you have an additional type that is Struct which is a stack allocated Class (the difference being "invisible" to the user of the Struct/Class other than for the sake of performance, although there are limitations on the person writing it).

                In OOP software it is exceedingly rare that you're just going to use a Primitive type on its own rather than being wrapped up in a more complex data type for example say you want to represent a complex number, your type would be:
                Code:
                class Complex {
                double real;
                double imaginary;
                };
                In Java that now has to be heap allocated. whereas in C# I can declare it to be a struct and follow the rules around "value types" and I can still use it on the stack like I could in C++ or similar languages. Obviously if I then include that complex struct in a class it then goes onto the heap with the enclosing object. What this means is that you save on unnecessarily generating a bunch of garbage in C# vs Java because in C# the stack handles it for you in those cases, whereas Java requires the Garbage Collector to do it. In C++ you make the active choice as the user of the type whether you'd prefer stack allocation or heap allocation.

                There's a variety of other much smaller things that add further to the memory efficiency of C# vs Java such as having unsigned types, and letting you choose which methods are virtual, but while a few bytes saved here and there does have a cumulative effective, that's not quite on the same scale as whole objects.

                You'll also note that in equivalent real programs C# and C++ use roughly the same amount of memory. In toys you can make C++ use vastly less memory but in the real world C++ memory management is done through schemes like parent-child hierarchies, reference counting smart pointers, etc, and thus you retain the same pointer overhead that you would if you were using a garbage collector. Meanwhile Java uses multiple times more memory.

                As to what you're talking about, both the JVM and CLR do roughly the same set of tricks (No surprise there as the CLR and C# were Microsoft's take on the JVM and Java). There are differences but it's not exactly like Java is doing some extra super memory consumptive magic sauce to improve their performance vs C#, especially as these are very long standing traits of the two languages.
                Thanks for the explanations. Everything you wrote makes sense except for one bit. With respect to performance, my understanding is that in long-running applications Java has an edge over C# for performance but not memory use because of its more sophisticated JIT + monitor and profile + re-JIT model. Thus the better Java applications generally outdo C# and in some cases outdo even C++ and Rust in the Techempower benchmarks at https://www.techempower.com/benchmarks/

                Comment


                • #58
                  Originally posted by cen1 View Post
                  Yet another example how C++ with STL and OpenMP (and threading in general) is superior to anything else.

                  Now waiting for Rust zealots to hijack the thread.
                  C/++/17 is a great language. And so is Rust, GoLang, C#, Python, etc.
                  Everyone has their place. There's no tool that can do it all...

                  Comment


                  • #59
                    Originally posted by Michael_S View Post

                    Thanks for the explanations. Everything you wrote makes sense except for one bit. With respect to performance, my understanding is that in long-running applications Java has an edge over C# for performance but not memory use because of its more sophisticated JIT + monitor and profile + re-JIT model. Thus the better Java applications generally outdo C# and in some cases outdo even C++ and Rust in the Techempower benchmarks at https://www.techempower.com/benchmarks/
                    Take a closer look at that table here's the ranking of the Java and C# entries from the first 100 places:
                    Java C#
                    3 7
                    6 11
                    8 17
                    12 33
                    13 36
                    15 39
                    18 44
                    19 72
                    26 80
                    34 82
                    41 89
                    45
                    46
                    47
                    53
                    59
                    60
                    61
                    62
                    63
                    65
                    68
                    69
                    91
                    98
                    100
                    Average Average
                    45.46 46.36
                    46.36/45.46 45.46/46.36
                    1.019 0.9805
                    You'll notice that basically all the numbers in the C# side line up with one of the clusters of numbers on the Java side, and are generally trading blows, and you'll further note that if you dig into their performance scores on that page that the C# and Java webservers are basically performing within the same scope as one another. The only exception is vertx-postgres which is much faster than the rest. What that tells me is that vertx-postgres has a much faster architecture than it's other managed language competitors, not that Java itself is faster, and even if it were... the difference based on ranking is 2%.
                    Last edited by Luke_Wolf; 13 July 2018, 07:36 PM.

                    Comment


                    • #60
                      Originally posted by ssokolow View Post

                      My experience has been that it does do whole-program parsing... it's just that the vast majority of errors are not syntax errors but, rather, errors which can only be caught at runtime because the language is too dynamic. (Same problem as JavaScript has in that respect)

                      You might want to try MyPy. (It's a verifier for Python's optional type annotations that serves a role similar to TypeScript.)
                      You're right. I was not being precise. What I run into is not syntax but undeclared/uninitialized variables, in branches that don't get run until they crash the program. Oh well, as a language it does encourage 100% unit test coverage. And this in PyCharm, quite possibly on the commandline it would not happen. Honestly I should have stayed quiet, I think I'm digging the hole deeper...
                      Last edited by hoohoo; 13 July 2018, 08:49 PM.

                      Comment

                      Working...
                      X