Folly - The Faceboook open source library
facebook.com
Folly - The Faceboook open source library
1–10 of 44 posts
Re: Folly - The Faceboook open source library
#2I'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...
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...
I like dynamic: https://github.com/facebook/folly/blob/master/folly/docs/Dyn...
Re: Folly - The Faceboook open source library
#3This 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...
Re: Folly - The Faceboook open source library
#4This 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...
Out of curiosity, are you unlikely to use the code because it's C++ or because it comes from Facebook?
Re: Folly - The Faceboook open source library
#5I'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... 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…
Aren't most of these already within boost or recent C++ standard ? I just took a look at the format and dynamic cases.
Re: Folly - The Faceboook open source library
#6I 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.
Re: Folly - The Faceboook open source library
#7This 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.
Re: Folly - The Faceboook open source library
#8This 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.
That isn't a conspiracy, it's one of the major reasons that anyone open sources anything ever.
Re: Folly - The Faceboook open source library
#9This 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...
I poured through the FBVector code because of your comment. It has some really interesting tricks. In a normal array allocation, it always goes for the next-largest-size in the jemalloc memory hierarchy. That is, it goes for multiples of 64 bytes, 256 bytes, 4 KB, or 4 MB. This makes the array cache-efficient.
The push_back() semantics features the standard array doubling technique, but only up to 4 KB; jemalloc can't grow in-place anything smaller than this, so a copy is required. Beyond that cut-off, push_back() will instead grow by 1.5 times the capacity to prevent too much "slack" memory from accumulating.
Re: Folly - The Faceboook open source library
#10This 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...
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.