
Folly - The Faceboook open source library - sidcool
https://www.facebook.com/notes/facebook-engineering/folly-the-facebook-open-source-library/10150864656793920
======
tptacek
This is all pretty great stuff. Make sure you read through the docs; I'm
unlikely to use Fb's C++ code, but I'm sure as hell going to look at making my
C vector code do some of what FBVector does:

[https://github.com/facebook/folly/blob/master/folly/docs/FBV...](https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md)

~~~
joe_the_user
Hmm,

I recently created a private memory allocator so the discussion on the page is
somewhat interesting...

 _Only a tiny minority of objects are genuinely non-relocatable:_

Hmm, I'm not exactly what is meant here. Moving a block of memory from here to
there in the most general case will leave your pointers dangling and crash you
in no short order. Things that pointed to the data you moved just don't any
more. If you are disciplined and don't have raw pointers in the block moved,
you're good. But as far as I know, that situation requires a very complete
understanding of the data in the block you are moving. You can do that. It's
just not easy or something that makes sense to stuff "anything" into.

~~~
dreiss
If your object is in a vector, it's already possible for the vector to move
the object without updating any pointers to it. The only question is whether
it is safe for the vector to move the object with memmove instead of invoking
a copy/move constructor, essentially skipping the step of telling the object
that it is being moved. This will only fail if the object contains pointers to
its own sub-objects (or the move constructor updates external pointers). This
is fairly rare, especially for objects that you would store directly in a
vector.

std::string is a key exception to this, but fbstring is not.

~~~
chasingtheflow
Could you elaborate at all on what it means to put an object in a vector/why
you would want to do that?

------
luser001
I'm going to be taking a serious look at this for my own projects.

I like Format:
[https://github.com/facebook/folly/blob/master/folly/docs/For...](https://github.com/facebook/folly/blob/master/folly/docs/Format.md)

Histogram is going to come in handy. :)

fbstring seems to be exactly what the doctor ordered.

I like the emphasis on cooperating with the memory allocator in fbstring and
fbvector. If the entire library does that, that's going to a big win for long-
running programs: memory fragmentation can slowly increase program footprint,
requiring the use of fancy arena allocators etc.

I had fun reading their vector doc:
[https://github.com/facebook/folly/blob/master/folly/docs/FBV...](https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md)

I like dynamic:
[https://github.com/facebook/folly/blob/master/folly/docs/Dyn...](https://github.com/facebook/folly/blob/master/folly/docs/Dynamic.md)

~~~
vl
Modern heaps typically have some low-fragmentation technique built-in, for
example, Windows ships with Low Fragmentation Heap, which is turned on by
default since Vista.

~~~
orijing
What is "low-fragmentation heap"? Why would anyone want "high-fragmentation
heap"? (since you imply that it's an option)

~~~
vl
Low-fragmentation heap puts object of similar size together, so once object is
freed, this memory can be reused for other object of similar size without
fragmentation. Because of this is has more "slack" - unused memory at the end
of the objects that are smaller than their buckets. On other hand, application
in steady state is not going slowly increase it's memory use over time.

Also it puts consequently allocated objects (of different size) far away (and
thus reduces cache locality), which, in turn may reduce performance for some
"allocate a lot of stuff at the beginning and then serve it", etc scenarios,
but this is pretty esoteric problem.

Benefits outweigh the concerns, so most apps benefit from the low-
fragmentation heaps.

------
tudorb
I'm Tudor, one of the main folly authors. I wrote format, Arena /
ThreadCachedArena, DiscriminatedPtr, GroupVarint, TimeoutQueue, and various
other pieces (parts of String.h, ThreadLocal, etc), and I'm pretty well-versed
with the entire library so I can reasonably answer questions (or poke the
appropriate people to make a HN account and answer). Ask away.

~~~
chrisaycock
Not necessarily specific to Folly, but I've wondered why _vector_ classes
don't have a "short vector optimization" like _string_ classes do. That is,
why don't they store 24 bytes or so in place? Is it because the required
iterators would take-up too much space anyway?

~~~
tudorb
folly::small_vector does just that (and it lets you use one bit for a mutex,
too! -- we have a lot of memory-constrained apps so we had to design data
structures for them).

We might unify that with fbvector eventually.

------
zem
i just attended alexandrescu's talk on some of the optimisations that went
into this [rami sayar liveblogged it here: <http://ramisayar.com/fb-cpp-
conf/>]. very interesting and inspiring remarks on instruction-level
parallelism [<http://en.wikipedia.org/wiki/Instruction_level_parallelism>] and
ways to help your code achieve it.

------
cpeterso
I'm surprised they used mixed-case file names when their class names are
lowercase. You have to remember both capitalizations. Mixed-case file names
can also be problematic when porting to case-insensitive file systems like
Windows' or Mac OS X'.

------
eliben
++ for being nicely documented

------
saraid216
I suppose I'll have to be the first to express shock that they decided to name
it Folly. I feel like Poe's Law is expressing itself.

~~~
andralex
"Folly" started as an internal codename loosely based on "F"acebook "O"pen
source "LL"ibrar"Y". When the time to choose an official name arrived, we
found "folly" too funny to not use.

------
tudorb
Now with discussion group: <https://groups.google.com/d/forum/facebook-folly>

------
pjmlp
Very nice addition to my C++ toolset.

------
bearwithclaws
Is the 3 "o" intentional?

------
bwei
Very nice.

------
alainbryden
This is a conspiracy theory, but what if there are bugs in it that they can't
find and so they're open sourcing it in the hope that someone else will fix
it.

~~~
oconnore
That isn't a conspiracy, it's one of the major reasons that anyone open
sources anything ever.

