6 ms·

It's not really "go" that makes the difference. it's how the runtimes and frameworks are used and/or made. frameworks on top of frameworks, all being over engi

by zobzu 14y ago

It's not really "go" that makes the difference. it's how the runtimes and frameworks are used and/or made. frameworks on top of frameworks, all being over engineered, with poor understanding of what the system actually does, result in super slow apps on top, that you generally go to aws to scale. It's not the first time that I see people reducing a dozen servers that were "always maxed out" by a couple of servers "that can barely feel the load". Yeah throwing hardware at the issues is fine'n all but we're been way over the limit too many times in too many directions. Go provides a clear start/APIs/framework, and the language enforces good habits. Also, it doesnt have things like global interpreter locks. The lesson? Stop using cool techs because there's blogs about them. UNDERSTAND the tech before using it.

pjscott 14y ago
Nice rant, and I mostly agree with it, but there are a few slow things about the ways that some languages are usually implemented that don't really have much to do with over-engineering. Let's take this line of Python code, for example, and look at how the CPython interpreter runs it: return x + 42 This turns into the following bytecode instructions: LOAD_FAST 0 (x) LOAD_CONST 1 (42) BINARY_ADD RETURN_VALUE First we get the x variable from the local namespace. This is an array of PyObject pointers; the LOAD_FAST oepration simply does an array lookup and puts the result on the stack, incrementing the reference count. Pretty fast. Next is LOAD_CONST, which is even faster; it takes an already-allocated PyObject and puts a pointer to it on the stack, incrementing the reference count. BINARY_ADD removes two numbers from the stack, dereferences the pointers to get the integer values, allocates a new PyObject with the resulting integer inside, bumps up its reference count, decrements the reference count of the two operands, and pushes the result on the stack. Finally, RETURN_VALUE jumps back to the caller of the function. In Go, the corresponding code would be compiled to two, maybe three machine code instructions. There are good reasons why Python does it this way, but it does suffer some inherent slowdown.
- kevingadd 14y ago
  A more interesting comparison would be the PyPy-generated native code for the expression versus the compiled code from Go. Comparing an interpreter with a compiler is generally uninteresting; the compiler almost always wins. If you look at the code that comes out of various modern JITs you often will find really interesting differences in the native code they produce, even for simple constructs like arithmetic. Type checks, barriers, bailouts, etc - in addition to more mundane differences, like one using SSE to do floating point and the other using x87, and one JIT having a better register allocator.
- ralph 14y ago
  > dereferences the pointers to get the integer values Doesn't it find a method of x that implements addition?
  - pjscott 14y ago
    Nope! There's a branch in the interpreter that checks if both operands are Python's built-in int objects. If they are, and the result can fit in a C int without overflow, then the interpreter adds the numbers directly. This is by far the most common case.
    - ralph 14y ago
      Interesting, thanks.
    - tjgq 14y ago
      How can the interpreter know, at bytecode compilation time, that x is bound to an int? Surely it generates two code paths, one for the "common case" and another for when x is a general object with an __add__ method?
      - ralph 14y ago
        The test is in the interpreter, not the compiler to byte-code. Every time the + is evaluated, the interpreter checks for the common case before resorting to finding the first object's method.
        tjgq 14y ago
        Okay, I think I get it now. The check you refer to is done inside the BINARY_ADD implementation. That's why the bytecode is the same for both cases. Am I right?
        ralph 14y ago
        Yes, as you say, it's not known at compile-time and is checked at interpretation time, each time. http://hg.python.org/cpython/file/b49971a1e70d/Python/ceval.c#l1522 http://hg.python.org/cpython/file/b49971a1e70d/Python/ceval....
quaunaut 14y ago
Maybe I'm just a new and terrible programmer, but I feel like if you wait to fully understand whatever tech is out there in terms of what to use, you'll never get started.
- paddyforan 14y ago
  Let's be new and terrible programmers together, because I feel like the only way to fully understand whatever tech is out there is to actually use it.
- hvidgaard 14y ago
  In reality you have to follow the buzz in the tech to understand new technology. If something sounds like you could use it, take a few days out to toy with it. If you still want to use it, try it out for a small project and the rest will come automatically if it is the right choice.
rektide 14y ago
I'm very sympathetic to your tech-on-tech-on-tech-on-tech hogwashery promulgated by open sourcers & vendors prosteltyzing their wonderful solutions and the other acculturation factors that permits developers approaches other than trying & seeing & exploring- That said, you are wrong. I'm not a Go user and I don't care for it, but Go is fundamentally different and better than most runtimes. Go has it's own green threading, which allows it to start new tasks using extremely small amounts of memory, and it can switch between tasks without the normal cost of context switching full on threads. That is a huge difference. Node has some elements in play here, with it's event loop and callbacks, but really the only thing in the field that compares to Go that's in use is Erlang, and there's no frameworking on top of Erlang that wouldn't cause most PHP or nine tenths the Python developers to curl into a weeping ball at the Eldritch horrors they'd been exposed to: even ASM code is not nearly so effective, being clearly a low level somewhat harmless thing. Being able to kick off small processes, that can sit around for a really long time, awaiting data- that's a model of computation we haven't done in decades, never with the mass popularity- there's a TLA for this kind of processing- Communication Sequential Processes, and Go is it. It's entirely different from the procedural model, from the Python and Perl and PHP scripting, where concurrency is a carefully waded into thing- Go is a concurrent first runtime, about ongoing, enduring, concurrent processes, and that's huge, HUGE I say, huge.
- jaggederest 14y ago
  Ia, Ia, Erlang Ftagn! I agree though, I just wish that Go would have developed from Erlang as a runtime. The Erlang virtual machine and systems are beautiful things - I used them for some wire-level work on a project and bitfields are awesome, and it provided a clean interface to a more 'normal' language to display to the user, fail-fast fault tolerance on a public safety project, neat stuff. It's just erlang-the-programming-language that has all the Prolog warts that scares people, I think.
  - rektide 14y ago
    Per your queueing, I'll toss in the Elixer chip- http://elixir-lang.org/ http://elixir-lang.org/ - it's a rather rote, boring, routine language that we all can be semi familiar with, with some aberrations carried over - pattern matched dispatch is still there, for example, making people wonder wtc. The web-page highlights it's advancements, it's "features," which is mildly amusing to me in that the biggest draw is that it's an Erlang that feels familiar to us Algol-derived unwashed/don't-know-anything-but hordes. Kind of as a foil to that normality, it's similarly remarkable to me that the Prolog asserted-messages/facts & reactive processing cycle of Erlang isn't itself better captured and shown off. It's kind of a middle stage introductory tutorial, after you've made it threw guarded dispatches, yet by itself I think it'd make a great "start with the hard stuff" intro-tutorial to Erlang, and I haven't really seen it presented independently, firstly.
deleted 14y ago
[deleted]
jussij 14y ago
> It's not really "go" that makes the difference But from what I've seen and read about Go, it does seem to have things in it that do make a difference. For example from day one Go was designed for with concurrency in mind and that's a big plus. To see how this can help this Rob Pike video does a good job of showing off Go's version of concurrency: http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html http://blog.golang.org/2013/01/concurrency-is-not-parallelis... Now, you can implement concurrency lots of different ways using many different languages. But I've used a lot of languages and I never seen concurrency done as easily as shown in that video.
- masklinn 14y ago
  > But I've used a lot of languages and I never seen concurrency done as easily as shown in that video. So I take it you never used Erlang.
  - Ziomislaw 14y ago
    Erlang is big and complicated compared to Go. It's not easy, and besides it is functional (not easy) which already makes it unusable by 90% of people.
    - masklinn 14y ago
      > Erlang is big and complicated compared to Go. No. OTP is big (arguably), Erlang isn't even remotely. It's also completely irrelevant to OP's remark. > It's not easy, and besides it is functional (not easy) That doesn't make sense. What's hard in Erlang? That you don't have a for loop?
    - tel 14y ago
      OTP is big an complicated... Erlang really isn't.
vidarh 14y ago
> It's not really "go" that makes the difference. it's how the runtimes and frameworks are used and/or made. Exactly. For the type of product they sell, if the processing time isn't pretty much all going to the actual running of the customer supplied job code and network latency, they're doing something very wrong. The language choice shouldn't be much more than noise in a setup like that. The framework choice, on the other hand... Rails is hardly well optimised for a high traffic API that can't readily be cached. I've done queuing and job processing in Ruby. Spending 90% of the time in kernel space handling network traffic or waiting is not hard to achieve for a pure queuing server. If you add delegating jobs to external code to do the actual work, you should spend less time in userspace in the code actually processing the messages. If language choice nets you more than 10%-20% in a setup like that, something else has changed beyond language. And that's fine. But a post focusing on the language change then makes it seem like they didn't understand what caused the performance problem in the first place.

by zobzu 14y ago

pjscott 14y ago

Nice rant, and I mostly agree with it, but there are a few slow things about the ways that some languages are usually implemented that don't really have much to do with over-engineering. Let's take this line of Python code, for example, and look at how the CPython interpreter runs it: return x + 42 This turns into the following bytecode instructions: LOAD_FAST 0 (x) LOAD_CONST 1 (42) BINARY_ADD RETURN_VALUE First we get the x variable from the local namespace. This is an array of PyObject pointers; the LOAD_FAST oepration simply does an array lookup and puts the result on the stack, incrementing the reference count. Pretty fast. Next is LOAD_CONST, which is even faster; it takes an already-allocated PyObject and puts a pointer to it on the stack, incrementing the reference count. BINARY_ADD removes two numbers from the stack, dereferences the pointers to get the integer values, allocates a new PyObject with the resulting integer inside, bumps up its reference count, decrements the reference count of the two operands, and pushes the result on the stack. Finally, RETURN_VALUE jumps back to the caller of the function. In Go, the corresponding code would be compiled to two, maybe three machine code instructions. There are good reasons why Python does it this way, but it does suffer some inherent slowdown.

kevingadd 14y ago
A more interesting comparison would be the PyPy-generated native code for the expression versus the compiled code from Go. Comparing an interpreter with a compiler is generally uninteresting; the compiler almost always wins. If you look at the code that comes out of various modern JITs you often will find really interesting differences in the native code they produce, even for simple constructs like arithmetic. Type checks, barriers, bailouts, etc - in addition to more mundane differences, like one using SSE to do floating point and the other using x87, and one JIT having a better register allocator.
ralph 14y ago
> dereferences the pointers to get the integer values Doesn't it find a method of x that implements addition?
- pjscott 14y ago
  Nope! There's a branch in the interpreter that checks if both operands are Python's built-in int objects. If they are, and the result can fit in a C int without overflow, then the interpreter adds the numbers directly. This is by far the most common case.
  - ralph 14y ago
    Interesting, thanks.
  - tjgq 14y ago
    How can the interpreter know, at bytecode compilation time, that x is bound to an int? Surely it generates two code paths, one for the "common case" and another for when x is a general object with an __add__ method?
    - ralph 14y ago
      The test is in the interpreter, not the compiler to byte-code. Every time the + is evaluated, the interpreter checks for the common case before resorting to finding the first object's method.
      - tjgq 14y ago
        Okay, I think I get it now. The check you refer to is done inside the BINARY_ADD implementation. That's why the bytecode is the same for both cases. Am I right?
        ralph 14y ago
        Yes, as you say, it's not known at compile-time and is checked at interpretation time, each time. http://hg.python.org/cpython/file/b49971a1e70d/Python/ceval.c#l1522 http://hg.python.org/cpython/file/b49971a1e70d/Python/ceval....

quaunaut 14y ago

Maybe I'm just a new and terrible programmer, but I feel like if you wait to fully understand whatever tech is out there in terms of what to use, you'll never get started.

paddyforan 14y ago
Let's be new and terrible programmers together, because I feel like the only way to fully understand whatever tech is out there is to actually use it.
hvidgaard 14y ago
In reality you have to follow the buzz in the tech to understand new technology. If something sounds like you could use it, take a few days out to toy with it. If you still want to use it, try it out for a small project and the rest will come automatically if it is the right choice.

rektide 14y ago

I'm very sympathetic to your tech-on-tech-on-tech-on-tech hogwashery promulgated by open sourcers & vendors prosteltyzing their wonderful solutions and the other acculturation factors that permits developers approaches other than trying & seeing & exploring- That said, you are wrong. I'm not a Go user and I don't care for it, but Go is fundamentally different and better than most runtimes. Go has it's own green threading, which allows it to start new tasks using extremely small amounts of memory, and it can switch between tasks without the normal cost of context switching full on threads. That is a huge difference. Node has some elements in play here, with it's event loop and callbacks, but really the only thing in the field that compares to Go that's in use is Erlang, and there's no frameworking on top of Erlang that wouldn't cause most PHP or nine tenths the Python developers to curl into a weeping ball at the Eldritch horrors they'd been exposed to: even ASM code is not nearly so effective, being clearly a low level somewhat harmless thing. Being able to kick off small processes, that can sit around for a really long time, awaiting data- that's a model of computation we haven't done in decades, never with the mass popularity- there's a TLA for this kind of processing- Communication Sequential Processes, and Go is it. It's entirely different from the procedural model, from the Python and Perl and PHP scripting, where concurrency is a carefully waded into thing- Go is a concurrent first runtime, about ongoing, enduring, concurrent processes, and that's huge, HUGE I say, huge.

jaggederest 14y ago
Ia, Ia, Erlang Ftagn! I agree though, I just wish that Go would have developed from Erlang as a runtime. The Erlang virtual machine and systems are beautiful things - I used them for some wire-level work on a project and bitfields are awesome, and it provided a clean interface to a more 'normal' language to display to the user, fail-fast fault tolerance on a public safety project, neat stuff. It's just erlang-the-programming-language that has all the Prolog warts that scares people, I think.
- rektide 14y ago
  Per your queueing, I'll toss in the Elixer chip- http://elixir-lang.org/ http://elixir-lang.org/ - it's a rather rote, boring, routine language that we all can be semi familiar with, with some aberrations carried over - pattern matched dispatch is still there, for example, making people wonder wtc. The web-page highlights it's advancements, it's "features," which is mildly amusing to me in that the biggest draw is that it's an Erlang that feels familiar to us Algol-derived unwashed/don't-know-anything-but hordes. Kind of as a foil to that normality, it's similarly remarkable to me that the Prolog asserted-messages/facts & reactive processing cycle of Erlang isn't itself better captured and shown off. It's kind of a middle stage introductory tutorial, after you've made it threw guarded dispatches, yet by itself I think it'd make a great "start with the hard stuff" intro-tutorial to Erlang, and I haven't really seen it presented independently, firstly.

deleted 14y ago

[deleted]

jussij 14y ago

> It's not really "go" that makes the difference But from what I've seen and read about Go, it does seem to have things in it that do make a difference. For example from day one Go was designed for with concurrency in mind and that's a big plus. To see how this can help this Rob Pike video does a good job of showing off Go's version of concurrency: http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html http://blog.golang.org/2013/01/concurrency-is-not-parallelis... Now, you can implement concurrency lots of different ways using many different languages. But I've used a lot of languages and I never seen concurrency done as easily as shown in that video.

masklinn 14y ago
> But I've used a lot of languages and I never seen concurrency done as easily as shown in that video. So I take it you never used Erlang.
- Ziomislaw 14y ago
  Erlang is big and complicated compared to Go. It's not easy, and besides it is functional (not easy) which already makes it unusable by 90% of people.
  - masklinn 14y ago
    > Erlang is big and complicated compared to Go. No. OTP is big (arguably), Erlang isn't even remotely. It's also completely irrelevant to OP's remark. > It's not easy, and besides it is functional (not easy) That doesn't make sense. What's hard in Erlang? That you don't have a for loop?
  - tel 14y ago
    OTP is big an complicated... Erlang really isn't.

vidarh 14y ago

> It's not really "go" that makes the difference. it's how the runtimes and frameworks are used and/or made. Exactly. For the type of product they sell, if the processing time isn't pretty much all going to the actual running of the customer supplied job code and network latency, they're doing something very wrong. The language choice shouldn't be much more than noise in a setup like that. The framework choice, on the other hand... Rails is hardly well optimised for a high traffic API that can't readily be cached. I've done queuing and job processing in Ruby. Spending 90% of the time in kernel space handling network traffic or waiting is not hard to achieve for a pure queuing server. If you add delegating jobs to external code to do the actual work, you should spend less time in userspace in the code actually processing the messages. If language choice nets you more than 10%-20% in a setup like that, something else has changed beyond language. And that's fine. But a post focusing on the language change then makes it seem like they didn't understand what caused the performance problem in the first place.