simonmar

6 ms·

1.
by simonmar 5y ago
Sorry about that, the package was still set to private. Try again now?
2.
by simonmar 5y ago
We want to open-source the C++ and Python indexers but they're not ready yet - we have to separate them from internal build-system-specific bits.
3.
by simonmar 5y ago
Kythe has one schema, whereas with Glean each language has its own schema with arbitrary amounts of language-specific detail. You can get a language-agnostic view by defining an abstraction layer as a schema. Our current (work in progress)
4.
by simonmar 5y ago
I should point out that Glean has evolved quite a bit since that talk!
5.
by simonmar 5y ago
There will be more indexers: we have Python, C++/Objective C, Rust, Java and Haskell. It's just a case of getting them ready to open source. You can see the schemas for most of these already in the repo: https://github.
6.
by simonmar 11y ago
The graph is sorted by performance, with the worst performing (not necessarily the most common) on the left. We've also done more profiling and optimisation since we took those measurements. FXL employed some tricks that were sometime
7.
by simonmar 11y ago
The memo table (map) is a bit of state that is maintained throughout the request's lifetime. When we compute a memoized value, it is inserted into the map, and if we need the value again we can just grab it from the map instead of rec
8.
by simonmar 11y ago
For example, let's say that one of the things you want to compute is the number of friends of the current user. This value is used all over the codebase, but it only makes sense in the context of the current request (because every req
9.
by simonmar 12y ago
Here's our paper about the ideas behind Haxl: http://community.haskell.org/~simonmar/papers/haxl-icfp14.pd...
10.
by simonmar 12y ago
He is still committing, but not quite so often :)
11.
by simonmar 12y ago
Haxl is the only major project at FB using Haskell right now, but who knows where this will lead?
12.
by simonmar 13y ago
Segmented stacks are better even if you have a relocatable stack. GHC switched from monolithic copy-the-whole-thing-to-grow-it to segmented stacks a while ago, and it was a big win. Not just because we waste less space, but because the GC
13.
by simonmar 16y ago
Oh yes, immutability is crucial. Generational GC already makes you pay for mutation with a write barrier, and in our parallel GC we omit the locking when copying immutable objects, accepting that a few might get copied twice. In the new GC
14.
by simonmar 16y ago
We still have lots of tuning to do, I'll be looking in detail at what is going on during those pauses. This program is slightly atypical in doing quite a lot of old-generation collections though (you can see two in the graph), it has a low
15.
by simonmar 16y ago
Yes, the GHC design has certainly been influenced by Manticore (that was one of the "other designs" I referred to). Though in GHC we do have some different problems to solve, the worst of which is that we have to support a bunch of program
16.
by simonmar 17y ago
Yes, a fair point. Concurrent and parallel do not describe disjoint sets of programs, of course. However, they really are different concepts. I think wikipedia's page on concurrency could use some work to make this clearer, maybe I'll tr