Live data from Hacker News

Viewing profile — tychver

tychver

HN member
Joined
Mon, Aug 22, 2016, 3:26 PM UTC
HN karma
22
Public activity
38 items

About tychver

No profile information was provided.

Recent public activity

  1. comment
    Comment #16050438

    Running T-Mobile's Erlang powered LTE network.

  2. comment
    Comment #15865675

    Sure they can. There’s a separate shared heap which uses atomic ref counting.

  3. comment
    Comment #15865634

    Did you check stack overflow jobs? What people are currently earning and what people are openly offering now has diverged quite a bit just in 18 months or so. It’s hurting the smal…

  4. comment
    Comment #15862114

    Berlin is a bit odd because of the huge changes in the last few years in companies starting offices here and the influx of VC funding. SoundCloud for example, had a bunch of engine…

  5. comment
    Comment #15861192

    Erlang has a really nice solution here by using a separate heap per Erland "process", and because they're owned by that process, can do a copying/compacting GC without having to ta…

  6. comment
    Comment #15861149

    Go merely adopts a different strategy which quietly fucks you in a different set of circumstances: https://news.ycombinator.com/item?id=15823683

  7. comment
    Comment #15823683

    Yeah, it mostly happens when you have a server which runs an abnormally large task or payload, causes the heap to grow, and does it in a way that Go can't release the memory back t…

  8. comment
    Comment #15821389

    Go trades the complexity of a compacting GC for forcing you to restart the app regularly if you have a workload with plenty of heap allocation.

  9. comment
    Comment #15798803

    I would also say the same if you host a Ruby or Python app, or anything using forking really. Similar to the issues you had with Redis, the kernel change to THP on by default total…

  10. comment
    Comment #15787677

    Do you mean: "take a few thousand rows and map them to a different data structure"? Because I benchmarked that recently and mapping 16,000 rows of GPS points using haversine distan…

  11. comment
    Comment #15785683

    500MB per worker is totally standard. What happens is a job causes a huge array or hash to be allocated, and after it‘s finished the memory can’t be returned to the OS due to heap …

  12. comment
    Comment #15785316

    The class definitions will be a tiny fraction of memory usage. A template Rails app memory usage only has about 20% managed by Ruby. The rest is the VM, C libraries, maybe long str…

  13. comment
    Comment #15784043

    Nah, unfortunately simply moving the GC bits from the object itself to bitmap in the page header made Ruby CoW friendlier but not CoW friendly! Each Ruby page is 4x OS pages on Lin…

  14. comment
    Comment #15783910

    Ruby is actually pretty good in this regard. If you define your module or class anonymously, but give it a name using a constant, Ruby will GC it when possible. The standard way of…

  15. comment
    Comment #15783446

    This was probably true 10 years ago, but these days it's basically FUD. Since then Ruby improved performance something like 5-80x from 1.8 to 2.5 and moved from an interpreted lang…

  16. comment
    Comment #15783296

    This is basically my job at ChartMogul and we've pretty much solved this problem. The two biggest issues for us were: Ruby prefers to grow the heap really quickly rather than spend…

  17. comment
    Comment #15783248

    You should really only need one process per core, plus a few thread per process. Obviously, this is a problem on Heroku where they give you 8 "cores" but only 512mb of RAM per 1x d…

  18. comment
    Comment #15783198

    Yes, but you only need one process per core, just like NodeJS. Since 1.9 you can use real OS threads to achieve parallel IO, and certain parallel computations which can proceed wit…

  19. comment
    Comment #15627685

    There's nothing really that special about Goroutines. Ruby also introduced Fibres in 2007. There's been some discussion of adding a more automatic M:N threading model to Ruby 3.

  20. comment
    Comment #15627569

    Patrick, on the 2.6+ Linux kernels, is there a significant difference between threads and processes? It seems like both threads and processes are created via clone and the only dif…

  21. comment
    Comment #15602235

    Yeah, that'll do it! C extensions are a core part of Ruby. A big chunk of the std lib is implemented in C. You shouldn't be afraid of writing a tiny bit of C. Ruby and Python are s…

  22. comment
    Comment #15575015

    Using Haversine distance increases it to only 13ms. I'm not sure why your Python implementation is so slow? In the real world, things like haversine are implemented as C extensions…

  23. comment
    Comment #15552219

    The whole Ruby VM only takes ~50ms to start, so that sounds a bit slow. I wrote a quick version in Ruby and it only takes 5ms: https://gist.github.com/jamatthews/d910a2b39c87a87126…

  24. comment
    Comment #15514492

    Not for almost a decade. Ruby web servers and job processing frameworks have used forking out of the box since the release of Phusion Passanger 2 in 2008 and Resque in 2009.

  25. comment
    Comment #15508740

    Forking 10 processes does not use 10x the memory of a single process starting 10 threads. It's actually almost identical. Both are implemented by the kernel using clone(). Many old…