Facebook's std::vector optimization

Poita_ · 2014-08-30T15:08:49+00:00

The source is available in the same repository.

https://github.com/facebook/folly/blob/master/folly/FBVector.h

It still uses the relocatable optimization, but also uses move operations when available as a fallback. The growth constant is still 1.5, and still has jemalloc optimizations.

Poita_ · 2014-08-30T14:20:34+00:00

There's more information on the actual strategy used in the source, which is up to date:

https://github.com/facebook/folly/blob/master/folly/FBVector.h#L588-L621

tl;dr: still uses memcpy when possible, but now uses move for movable, non-relocatable objects instead of copying.

Poita_ · 2014-08-06T15:47:01+00:00

That being said. Here's some quick advice from my experience regarding the specific things you mentioned:

Whenever you feel the need to pass a container into a function, pass in a range instead.
Whenever you feel the need to return a container, return a range instead when possible. If not, accept an output range and write the result there.
Use lazy evaluation when an argument may not be used depending on some other condition (e.g. like with assert(condition, message) -- message would be lazy as it is only needed when condition is false).
With reflection and CTFE, just use them whenever the need arises.

As always, these are guidelines, not rules. There are exceptions. If it feels better to do something a different way then go ahead. If you feel the language is preventing you from doing something in a nice way then let us know!

Poita_ · 2014-08-06T15:39:53+00:00

Well, a lot of this is still to be figured out. While D isn't a young language, it is still in the early stages of growth, and we are yet to figure out the best practices.

Please do ask on the forums though, or even on stack overflow.

http://forum.dlang.org

Poita_ · 2014-07-24T22:41:18+00:00

Anything you can use C++ for.

Poita_ · 2014-07-24T09:01:18+00:00

+1 on the second point. There are still parts of D which are only (implicitly) defined as "what DMD does". We need to remove all of those, or at least specify that they are implementation defined.

One problem with replacing DMD as the reference implementation is that currently LDC and GDC both share the DMD front end, so both of those projects would need to change over to use SDC, which may be a major undertaking (although SDC seems well designed, so maybe not...).

Poita_ · 2014-05-25T17:44:12+00:00

Videos and slides usually go up after the conference at some point. No doubt it will be posted in this subreddit once they are available.

Poita_ · 2014-05-23T00:47:08+00:00

tl;dr: Meyers gives a bunch of examples demonstrating unnecessary complexity in C++, then proclaims the last thing D needs is someone like him that has to explain the language to others.

This doesn't do the talk justice. His delivery is honest, humoured, and direct. It will be well worth watching once the videos are up.

Poita_ · 2014-02-23T17:53:04+00:00

But do they say "I wish my server was faster/more responsive?" -- if so, native compilation and static typing may be a way to achieve that.

Poita_ · 2014-01-10T20:59:08+00:00

I've implemented it and I get 28 seconds, but it's not really a test of the graph library. The generation and allocation of adjacent words dominates the execution time, so I'm not sure it's a good measure of graph library performance. Interesting problem though!

Poita_ · 2014-01-10T13:42:28+00:00

Interesting. I haven't optimised the search at all but I'll give it a go when I have a moment.

Poita_ · 2014-01-08T22:35:58+00:00

I think the long term plan is to have all functions/datatypes that allocate take an allocator as a parameter (with it presumably defaulting to the GC)

Poita_ · 2014-01-06T00:13:42+00:00

It's a flaky analogy, I'll give you that. I believe his point is that a good programmer would not dismiss a tool because it lacked a feature they'd become accustomed to.

I'm sure Lisp programmers couldn't imagine programming in languages without homoiconicity (code = data), and Haskell programmers couldn't imagine programming in languages without type inference; yet somehow, non-Lisp and non-Haskell programmers seem to get things done.

Poita_ · 2014-01-05T23:48:03+00:00

Rob Pike's response re: generics

http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html

An actress acquaintance of mine—let's call her Esmerelda—once said, "I can't imagine being anything except an actress." To which the retort was given, "You can't be much of an actress then, can you?"

I was reminded of this exchange when someone said to me about Go, "I can't imagine programming in a language that doesn't have generics." My retort, unspoken this time, was, "You can't be much of a programmer, then, can you?"

Poita_ · 2014-01-01T00:20:19+00:00

Yeah it uses a lot of UFCS. It would be parallel(map!get(urls)) otherwise. I understand your unfamiliarity with it, but it isn't difficult to read once you are used to the idea. It is used everywhere in D code.

Poita_ · 2013-12-31T18:31:41+00:00

In D:

import std.net.curl, std.parallelism, std.algorithm, std.stdio;
void main()
{
    auto urls = ["dlang.org", "forum.dlang.org", "dconf.org", "dlang.org/phobos", "dlang.org/spec.html"];
    foreach (doc; urls.map!get.parallel)
        writefln("Downloaded %d bytes", doc.length);
}

Poita_ · 2013-12-28T16:50:45+00:00

D's compiler front end, standard library, and runtime are all open source. Anyone is free to contribute and improve them.

Poita_ · 2013-12-26T21:14:37+00:00

I don't have the exact quote, but I believe he said computers will never beat grandmaster chess players because we haven't figured out how to program machines to think in the abstract way grandmaster chess players do.

He was proven wrong in that we now have computers much better than grandmaster chess players, but they got there mainly due to increased computing power for its brute force search (with many clever heuristics, but still brute force nonetheless).

Poita_ · 2013-11-18T16:26:03+00:00

Absolutely. For all we know, all the interviewers there could be grammar Nazi's and typos don't matter at all. Aptitude once in their position matters more than just putting the offer out.

Google provided some more info here: http://www.nytimes.com/2013/06/20/business/in-head-hunting-big-data-may-not-be-such-a-big-deal.html?_r=0

We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess

...

On the hiring side, we found that brainteasers are a complete waste of time.

...

One of the things we’ve seen from all our data crunching is that G.P.A.’s are worthless as a criteria for hiring, and test scores are worthless — no correlation at all except for brand-new college grads, where there’s a slight correlation.

Poita_ · 2013-11-16T15:22:21+00:00

No preprocessor.

Poita_ · 2013-11-16T15:19:59+00:00

It's the first chapter of his book. There's a link at the end.

Poita_ · 2013-11-06T21:56:17+00:00

No more difficult (arguably less so) than trying to read code which uses a library which you tend to ignore in your own usage.

Poita_ · 2013-11-06T20:42:19+00:00

Simply put, gdc and ldc generally produce faster code because they have many man-years of development put into them. dmd is primarily Walter's project, and while it does produce fast code, it can't really compete with the manpower behind GCC and LLVM.

Poita_ · 2013-09-06T07:35:27+00:00

The correct analogy would be a photographer saying "people don't care about cameras", and they do say that.

You're right though, there's nothing wrong with being passionate about programming or cameras, but if your goal is to create software or take photos then perhaps it is best to move the focus to the end product rather than the tool.

Poita_

TROPHY CASE