Conversation

Notices

  1. I feel like if you're using Go for performance reasons you're probably one of those people who was trying to tell us that Visual Basic was faster than C++.

    Sunday, 08-Jan-17 09:54:05 UTC from community.highlandarrow.com
    1. @maiyannah Personally: if you want a new language that's fast, modern, to the metal and safe, then just get Rust. You get better dependency management and native C calling all without a garbage collector.

      Sunday, 08-Jan-17 09:58:56 UTC from social.tpaw.org
      1. @tomascw But why would I program by running around naked hitting things with rocks?

        Sunday, 08-Jan-17 10:01:39 UTC from community.highlandarrow.com
        1. @maiyannah XD Well if you wanna stay hip with the new languages, then Rust is the only other one I can think of that's as fast as C/C++. Can't exactly comment on Swift since I'm stuck on Windows, atm.

          Sunday, 08-Jan-17 10:09:52 UTC from social.tpaw.org
          1. @tomascw Within the environment it was programmed for, Rust is definitely one of the best newer languages.

            Sunday, 08-Jan-17 10:10:38 UTC from community.highlandarrow.com
      2. @tomascw @maiyannah Rust has it's place but you pay a price in being constrained in what you can easily do.

        GC isn't necessarily a performance loss compared to malloc/free btw, the main issue with it is that it introduces unpredictability in timing. E.g. ocaml is pretty darn fast as well with a pretty strong type system but it uses a GC. It's even used fairly close to the metal (https://mirage.io/)

        D is also pretty fast with a GC, though there's a lot of work right now to allow you to turn it off. It's somewhat C++ish though in that it's a pretty big language which gives you all the tools to build something great and to hang yourself.

        Sunday, 08-Jan-17 10:11:04 UTC from community.highlandarrow.com
        1. @verius @maiyannah Huh, # I've been under the impression GC languages had more cons then pros compared to non-GC. Mostly cause of the bad rep Android has gotten and a friend of mine trying to explain how bad their performance may be when I was still fairly new to programming. It's left me kinda split for a long time.

          Sunday, 08-Jan-17 10:17:18 UTC from social.tpaw.org
          1. @tomascw @verius GC stuff is something you really gotta know what you're doing with, but you'll generally have much better code if you do in the use cases where GC is strong, if you have good code.  It will really punish you if you don't, however.

            Sunday, 08-Jan-17 10:18:17 UTC from community.highlandarrow.com
            1. @maiyannah @verius Speaking of punishing, I'm apart of (per-se, long story) a open source video game project that successfully reverse engineered another game. It's written entirely in C#. The problem is that AI behind that game is basically a VM too. It's stumbled upon more then a few memory leaks which as me thinking lately, "was writing the entire thing in C# really the best move?"

              Sunday, 08-Jan-17 10:25:38 UTC from social.tpaw.org
            2. @maiyannah @tomascw I'd argue that manual allocation will also really punish you if you don't have good code. It's just the failure patterns that are different. GC code tends to hog memory, manual allocation code additionally can crash or corrupt a program (with security implications).

              In my experience though memory issues with C are easier to debug than Go or PHP since valgrind is such a good tool.

              Sunday, 08-Jan-17 10:27:01 UTC from community.highlandarrow.com
              1. @verius @tomascw PHP memory leaks tend to be easy to diagnose in my experience, but that's mostly because they tend to be as a result of one of a handful of easy mistakes to make.

                Sunday, 08-Jan-17 10:32:11 UTC from community.highlandarrow.com
                1. @maiyannah @tomascw Well the reason tends to be easy: refcycles. But I haven't found a better way to find those than printing objects with Xdebug and carefully looking at the refcount values.

                  Do you know of a better way perchance?

                  Sunday, 08-Jan-17 10:34:35 UTC from community.highlandarrow.com
                  1. @verius @tomascw xhprof and Blackfire are both good tools for that.  Xdebug discontinued proper memory profiling anyways.

                    Sunday, 08-Jan-17 10:39:09 UTC from community.highlandarrow.com
                    1. @verius @tomascw http://php.net/manual/en/book.xhprof.php

                      Sunday, 08-Jan-17 10:40:07 UTC from community.highlandarrow.com
                      1. @maiyannah Thanks.

                        Sunday, 08-Jan-17 10:46:25 UTC from community.highlandarrow.com
                        1. @verius xhprof is definitely one of those things made for programmers.  You'll see what I mean if you play around with it.  But in general I find it's pretty good at finding performance flaws.  Not even neccesarialy leaks.

                          Sunday, 08-Jan-17 10:47:41 UTC from community.highlandarrow.com
                          1. @maiyannah Looks like it's unmaintained and not PHP 7 compatible. :(

                            Sunday, 08-Jan-17 10:54:36 UTC from community.highlandarrow.com
                            1. @verius There was a fork of it for php7 but I forget the name of it offhand.  Actually, I should dig that out since I want to migrate postActiv to purely php7 at some point in the future so we can take advantage of the many improvements php7 has implemented.

                              Sunday, 08-Jan-17 10:55:46 UTC from community.highlandarrow.com
                              1. @maiyannah It's somewhat of a professional interest for me as well as we're looking at migrating the app at work to PHP 7. So far it looks like there's really very little work needed to migrate a 5 app to 7. But postActiv has a longer development history, so there might be some spots here and there.

                                One major thing to keep in mind though is that if you have a class A with a function 'foo()' and a class B that derives from A with a function 'foo($bar)' PHP 7 will error out.

                                A tip: set up a Sentry server and hook postActiv up to it. Sentry will by default catch all those warnings so at least you'll get a list of things that are problems already. 

                                Sunday, 08-Jan-17 11:01:20 UTC from community.highlandarrow.com
                                1. @verius The bigger project will be refactoring code to take advantage of 7, but there's still a few problems you can run into.  There's some stuff that has been depreciated that will likely provide problems with our technical debt.

                                  On the other hand, this will be a very effective means of getting rid of a lot of that technical debt and knowing that there isn't stuff we've missed.  php7 will let us know with the err_deprecated errors.

                                  Sunday, 08-Jan-17 11:08:41 UTC from community.highlandarrow.com
              2. @verius @maiyannah So the benefit of a language like C, for example, is it lends itself better debugging but you trade off the lack of GC. Go's benefit, for example, comes from automatic memory management but debugging could be a little tricky? If I'm understanding correctly.

                Sunday, 08-Jan-17 10:35:58 UTC from social.tpaw.org
                1. @tomascw @maiyannah Roughly, yes.

                  C is the easiest language to debug with standard tools like gdb and valgrind since those are written for it and because it does very little weird things. Compared to Go C has a major downside in that there are many things that are strictly speaking not correct but that the compiler may silently misinterpret. See http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

                  Go has very little undefined behavior but on the flip side that costs performance (undefined behavior lets the compiler take shortcuts to enhance performance). Go's debugging tools are more difficult to use since you need to understand how Go works under the hood to work with gdb. C doesn't do much magic.

                  Go does have benefits with simpler multithreading but I don't know how easy it is to debug stuff with that (in general concurrency is a headache).

                  Sunday, 08-Jan-17 10:45:14 UTC from community.highlandarrow.com
                  1. @verius @tomascw Debugging threaded applications has always been a headache.  I kind of wonder why after so many years now with them being around we haven't developed better tools.

                    Sunday, 08-Jan-17 10:46:37 UTC from community.highlandarrow.com
                    1. @maiyannah @tomascw It's simply a very hard problem. Much of the problems come from race conditions and those are simply hard to detect well.

                      Static analysis has problems computing all possible code paths and thus has to be either conservative and report only problems it's sure of or give a lot of false positives.

                      Dynamic analysis can only see the path code has taken in the run that was measured, so unless you have a really good test suite it's hard to get good coverage. Plus it's hard to get the info without instrumentation but instrumentation will probably alter performance characteristics which can affect whether races occur (this is also a major cause of heisenbugs not showing up in gdb).

                      Sunday, 08-Jan-17 10:53:13 UTC from community.highlandarrow.com
                      1. @verius @tomascw Oh, I'm aware of the difficulties, just seems a little strange to have been a problem that we've had for as long as we've had now, and no one has come up with a solution.

                        Sunday, 08-Jan-17 10:54:41 UTC from community.highlandarrow.com
                        1. @maiyannah @tomascw I don't know if the problem is solvable in general but for free tools tsan (ThreadSanitizer) is pretty decent (the whole suite of sanitizers is recommended to use at least occasionally when you're working with a supported language).

                          Sunday, 08-Jan-17 10:57:32 UTC from community.highlandarrow.com
          2. @tomascw @maiyannah It's actually difficult to compare GC and manual memory allocation in general. Different usage patterns and GC technologies give dramatically different results.

            For example in a functional language like OCaml you have tons of small allocations. But the GC is optimized for that, it expects more allocations to be reclaimed quickly (the so called generational hypothesis) and is optimized accordingly. The Real World OCaml book has a whole chapter about how that's implemented: https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html

            And on the other side malloc/free isn't the only game in town for manual allocations. If you know you will need 1MB which can be freed all at once at the end of a particular function it's massively more efficient to just allocate once and use a really trivial allocation function yourself to deal out pointers to within the allocated block.

            Sunday, 08-Jan-17 10:24:01 UTC from community.highlandarrow.com
    2. @maiyannah Compared to some stuff it's faster. Go with well written queries is a lot faster than PHP with an inefficient half-assed ORM.

      In case you're thinking that's probably due to the DB interaction, yes, that makes all the difference. ;)

      Sunday, 08-Jan-17 10:03:42 UTC from community.highlandarrow.com
      1. @verius PHP can be a lot faster with databases than pretty much any scripting language I've seen other than Rust.

        Completely unrelatedly, I really deeply want to rewrite GS' database handling code.

        Sunday, 08-Jan-17 10:09:27 UTC from community.highlandarrow.com
        1. @verius Though I'm not touching the whether Rust is interpreted/compiled arguement with a ten foot pole.  It's meant to be compiled, but like 99.9999% of the implementations I've seen use interpreters.

          Sunday, 08-Jan-17 10:11:49 UTC from community.highlandarrow.com
          1. @verius (Kind of one of those, "when all you have is a hammer..." sort of things.  In fact, I'd say that's sort of a fundamental problem with new languages in general.  Rather than being happy with a language that does one thing really well, they have to have something that works for all use cases.)

            Sunday, 08-Jan-17 10:13:34 UTC from community.highlandarrow.com
            1. @maiyannah Perhaps that is the success of PHP. How often do you hear of PHP being used for non-web-related purposes? It's a niche specific language. It's a big niche, but it's still not like PHP is used for general system administration.

              Compare that to the nodejs nonsense. Javascript is a language that's not even good at the one thing you cannot avoid using it for. But still people need to run it on the server.

              Sunday, 08-Jan-17 10:17:56 UTC from community.highlandarrow.com
              1. @verius Actually, I know a lot of people who use PHP CLI scripts for server administration or shell scripting.

                Sunday, 08-Jan-17 10:18:55 UTC from community.highlandarrow.com
        2. @maiyannah I don't believe the critical database stuff in PHP is really PHP code though, it's C called by PHP. Much in the way how Python handles performance sensitive things.

          And you know, that's a good thing. Use the best tool for the job rather than mandate that one language or style rules all.

          Sunday, 08-Jan-17 10:14:31 UTC from community.highlandarrow.com
          1. @verius Yes and no, but it doesn't matter how efficient the underlying C code is if the abstraction we push it through is a bottleneck.  You know, like postActiv's :P

            Sunday, 08-Jan-17 10:15:44 UTC from community.highlandarrow.com