Live data from Hacker News

Viewing profile — eklitzke

eklitzke

HN member
Joined
Tue, Mar 03, 2009, 7:02 AM UTC
HN karma
2,848
Public activity
536 items

About eklitzke

https://eklitzke.org/

Recent public activity

  1. comment
    Comment #48201511

    Most of the training cost is not in the final training run, it's in all of the R&D (including salaries, equity, etc.) that it takes to get to the final training run. The actual cos…

  2. comment
    Comment #47943380

    A well run public transit system should obviously be cheaper at scale than robotaxis, but the incentives for Waymo (or Uber, or Lyft, etc.) are very different than the city's incen…

  3. comment
    Comment #47904850

    Yeah, none of this makes sense to me. Allocating memory for stack space is not expensive (and the default isn't even 1MB??) because you're just creating a VMA and probably faulting…

  4. comment
    Comment #47869341

    I can't speak to what every team at Google does, but there are machines with Nvidia GPUs in Borg. However Google charges orgs internally for cpu/memory/gpu/tpu usage and TPUs are *…

  5. comment
    Comment #47837042

    This is true but the relative overhead of this is highly dependent on the protobuf structure in one's schema. For example, fixed integer fields don't need to be decoded (including …

  6. comment
    Comment #46210605

    Pretty much all of the history of HN front pages, posts, and comments are surely in the Gemini training corpus. Therefore it seems totally plausible that Gemini would understand HN…

  7. story
  8. story
  9. comment
    Comment #45572132

    I think it's important to point out the distinction between what POSIX mandates and what actual libc implementations, notably glibc, do. Nearly all non-reentrant POSIX functions ar…

  10. comment
    Comment #45523506

    NUMA has a huge amount of overhead (e.g. in terms of intercore latency), and NUMA server CPUs cost a lot more than single socket boards. If you look at the servers at Google or Fac…

  11. comment
    Comment #45235651

    A few reasons, I think. The first is that getaddrinfo is specified by POSIX, and the POSIX evolve very conservatively and at a glacial pace. The second reason is that specifying a …

  12. comment
    Comment #45111906

    I agree. If you actually know what you're doing you can use perf and/or ftrace to get highly detailed processor metrics over short periods of time, and you can see the effects of t…

  13. comment
    Comment #45070444

    Writing drivers is easy, getting vendors to write *correct* drivers is difficult. At work right now we are working with a Chinese OEM with a custom Wifi board with a chipset with f…

  14. comment
    Comment #45000922

    From what I could tell from the article and the linked videos the innovation here is that it essentially lets you serve the shuttlecock while it's facing the wrong direction. Norma…

  15. comment
    Comment #44893851

    Yeah if you were really trying to make things fast you'd have the compute and NFS server in the same rack connected this way. But you aren't going to get this from any cloud provid…

  16. comment
    Comment #44893335

    NFS can be super fast, in a past life I had to work a lot with a large distributed system of NetApp Filers (hundreds of filers located around the globe) and they have a lot of fanc…

  17. comment
    Comment #43396274

    This is vastly oversimplifying the problem, the difference between IPv4 and IPv6 is not just the format of the address. Different protocols have different features, which is why th…

  18. story
  19. comment
    Comment #42467121

    I don't understand why they say that reference counting is "slow". Slow compared to what? Atomic increments/decrements to integers are one of the fastest operations you can do on m…

  20. story
  21. story
  22. comment
    Comment #41362766

    Just to expand on this, since it wasn't originally clear to me from reading your post, the contact privacy feature is about using SGX enclaves for the purpose of populating your kn…

  23. story
  24. story
  25. story