pizlonator

110 ms·

1. 1741.▲
   by pizlonator 11y ago

   I often hear this kind of claim. Do you have evidence? Because I just presented evidence that locks are awesome.
2. 1742.▲
   by pizlonator 11y ago

   The post details why we spin for the amount of time that we do. It turns out that there is a wealth of measurements that support our 40-spins-while-yielding rule. It worked for a strangely diverse set of workloads: - IBM Research found it
3. 1743.▲
   by pizlonator 11y ago

   The points isn't to have two mutexes in the same cache line. The point is to have a mutex plus the data that the mutex protects in the same cache line.
4. 1744.▲
   by pizlonator 11y ago

   Weakening the consistency of operations on the slow path is not going to be a speed-up. Those paths are not dominated by pipeline effects inside the CPU. They are dominated by context switches and memory contention. So, SC is exactly right:
5. 1745.▲
   Locking in WebKit(webkit.org)

   121 points by pizlonator 11y ago|40 comments
6. 1746.▲
   by pizlonator 11y ago

   We spend time optimizing JavaScriptCore's build time. It's a hard problem and it's important when managing such a large project. People inevitably have to do clean builds and that sucks when you have >400k lines of C++ cod
7. 1747.▲
   by pizlonator 11y ago

   All of this! For example in JS, once you prove that "o.f = v" is not going to hit a setter (or you put a speculative check to that effect), then you know that this effect does not interfere with "v = o.g" (provided you c
8. 1748.▲
   by pizlonator 11y ago

   LLVM's use of a very rich (and hence not as memory efficient) IR is deeply rooted. Phases assume that given any value, you can trace your way to its uses, users, and owners. The LLVM code I've played with assumes this all over the
9. 1749.▲
   by pizlonator 11y ago

   I'm not a big fan of self-hosting. I like that you can build JavaScriptCore without using JavaScriptCore.
10. 1750.▲
    by pizlonator 11y ago

    LOL! It is expressive though. It's got really powerful first-class functions. It's got classes. It's got prototypes. It's got generators. It's got other things that I don't even remember (but will probabl
11. 1751.▲
    by pizlonator 11y ago

    I always thought that Ada was easy to compile in the backend (i.e. the moral equivalent of what B3 does) but challenging on the frontend because of how large the language is. Could be wrong though. The frontend is usually the hard part IMO
12. 1752.▲
    by pizlonator 11y ago

    I know about it. I'm not concerned with future hypotheticals, but current actual measurements. That's the currency I deal in.
13. 1753.▲
    by pizlonator 11y ago

    Swift is not a dynamic language. It's statically typed.
14. 1754.▲
    by pizlonator 11y ago

    Thanks! :-) Looking forward to more write-ups about TurboFan!
15. 1755.▲
    by pizlonator 11y ago

    Note that usually being "as fast as" a production JSVM means also proving that you can start up as fast as JSVMs do. Have you done this?
16. 1756.▲
    by pizlonator 11y ago

    I think that's mostly accurate, in the sense that we wouldn't have done this if it was only motivated by specializing for JavaScript semantics. We had gotten pretty good at having our high-level compiler (DFG) burn away the Jav
17. 1757.▲
    by pizlonator 11y ago

    ajross is right. People choose the languages they like regardless of performance. JS perf is important to users though. Faster execution means fewer watts spent rendering and interacting with your favorite web page. (Fun fact: B3's bac
18. 1758.▲
    by pizlonator 11y ago

    3 months. Two people working on it (me and @awfulben).
19. 1759.▲
    by pizlonator 11y ago

    Relevant, contains a lot of details: https://news.ycombinator.com/item?id=11103765
20. 1760.▲
    by pizlonator 12y ago

    It's a good question. I think I know why. WebKit's preexisting JITs were tuned for fast code load. Even the DFG JIT, the third-tier optimizing JIT, is deliberately tuned to generate code quickly even if it means not optimizing
21. 1761.▲
    by pizlonator 12y ago

    That's a half-truth. Callee-save registers are a beautiful thing. When LLVM emits code for a function call, with high probability all of the important state will not be spilled - it'll be left in callee-save registers and it w
22. 1762.▲
    by pizlonator 12y ago

    The most common incarnation of Bartlett is a semispace mostly-copying collector with bump pointer allocation. You never leak a whole space. The only requirement is that the spaces are a discontiguous bag of pages. Note that in proper GC t