News for hackers. Stuff that matters.
Re:Folly - The Faceboook open source library by tptacek on Saturday June 02, 2012 @08:13PM (#4059632)
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...

Re:Folly - The Faceboook open source library by chrisaycock on Saturday June 02, 2012 @10:43PM (#4059870)
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 by stianan on Saturday June 02, 2012 @08:45PM (#4059682)
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 by tptacek on Sunday June 03, 2012 @01:21AM (#4060140)
C++.
Re:Folly - The Faceboook open source library by tomjen3 on Sunday June 03, 2012 @06:06AM (#4060460)
I realise this is a dangerous subject, but I am genuinly curious: given the business you run and the work you do for the Freebsd team, why would you object to using c++, but not c?

I could understand why you would object to both, but why only the lower level language.

Re:Folly - The Faceboook open source library by seiji on Sunday June 03, 2012 @08:11AM (#4060595)
Personally, I can't keep all of how C++ works in my brain at once. Most people end up limiting themselves to a "sane subset" of C++ to compensate for spec sprawl. But, everybody picks a different subset, so you can quickly stumble on things you think you know but don't work quite right when working on non-self-originated code.
Re:Folly - The Faceboook open source library by cperciva on Sunday June 03, 2012 @02:33PM (#4061451)
given the business you run and the work you do for the Freebsd team

Are you getting confused between tptacek and me?

Re:Folly - The Faceboook open source library by tptacek on Sunday June 03, 2012 @02:39PM (#4061468)
Hey, why don't you use C++? :)
Re:Folly - The Faceboook open source library by cperciva on Sunday June 03, 2012 @05:13PM (#4061771)
I think Tavis put it best: C is easier to audit because it's transparent. With C++ you can have innocuous-looking source code and have the compiler doing all sorts of crazy things behind your back.
Re:Folly - The Faceboook open source library by tptacek on Sunday June 03, 2012 @12:05PM (#4061083)
I don't work for the FreeBSD team.
Re:Folly - The Faceboook open source library by joe_the_user on Sunday June 03, 2012 @12:42AM (#4060071)
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.

Re:Folly - The Faceboook open source library by dreiss on Sunday June 03, 2012 @11:56AM (#4061070)
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.

Re:Folly - The Faceboook open source library by chasingtheflow on Sunday June 03, 2012 @10:40PM (#4062438)
Could you elaborate at all on what it means to put an object in a vector/why you would want to do that?
Re:Folly - The Faceboook open source library by sureshv on Sunday June 03, 2012 @01:49AM (#4060178)
Edit: I think the assumption is that an object itself is relocatable inside a container like vector if it marks itself as such. The document itself doesn't actually explain the inner workings.
Re:Folly - The Faceboook open source library by joe_the_user on Sunday June 03, 2012 @03:27PM (#4061558)
Yes, I think the point is that they are indeed glossing over important stuff.
Re:Folly - The Faceboook open source library by shin_lao on Sunday June 03, 2012 @05:19AM (#4060409)
That's all good and well, but I'm not sure I understand what it brings compared to std::vector with a good allocator.

In addition, it does not support concurrent growth.

Re:Folly - The Faceboook open source library by dreiss on Sunday June 03, 2012 @12:00PM (#4061076)
- It adjusts its growth strategy to work well with the properties of the allocator.

- It requires that its members be relocatable and uses memmove to speed up move operations.

Re:Folly - The Faceboook open source library by shin_lao on Monday June 04, 2012 @03:02AM (#4062966)
1 - Can be done from the allocator; 2 - I don't think it's useful with rvalues references. It also sounds like you want to use std::list...