HNHacker News
TopNewBestAskShowJobs

kmavm

3,077 karma · joined November 27, 2008

Computer person in VC. Partner at Pebblebed. Ex-{Slack,Facebook,VMware}. One of the engineer founders of FAIR.
submissionscomments
kmavm··on A Revolutionary Technique That Changed Machine Vision
Hi, I am a research engineer in Yann LeCun's group at Facebook. I hate to seem to be picking a fight, but you're a prominent poster here, and this comment seems likely to garner a fair amount of attention. Unfortunately almost every sentence you've written betrays a subtle misunderstanding of the space, and the totality is quite misleading.

> The naive approach (start at a "random" weight setting, use gradient descent) that works on a convex error surface fails catastrophically on deep, complex neural nets. (Shallow neural net training is a non-convex problem as well, but seems to be "less non-convex" in practice.)

Starting at a random (no scare quotes needed) point in weight space and SGD'ing is exactly what Alex Krizhevsky, and all of the derivative convnets over the last two years, did and do. It works just fine; I sit at work doing it all day long. You need to have enough data to train on, big enough models, and enough flops to train the big models on the big data before your interns' grandchildren die. We have all of the above now. Aside: even single-layer neural networks do not have convex error surfaces; convexity, and funky error surface geometry, is not a relevant distinction between shallow and deep nets. There have been no magical optimization breakthroughs, it's still SGD with the same herbs and spices that were used in the 90's (momentum, e.g.).

> The problem is that convergence, for single-layer nets, can be very slow (especially given that you're often doing stochastic gradient descent when working large data sets).

"Stochastic" gradient descent just means doing lots of weight updates per epoch. Ceteris paribus, training on large, redundant data sets, stochastic converges faster than batch because it gets to consider more points in the weight space than batch per pass over the data. The problem with single-layer neural nets is not that they converge slowly; the problem is that the layer size needs to grow exponentially with the task size. Single-layer neural nets' universal approximation power is thus not of great practical consequence. The power of deep nets is the power of composition: f(g(h(x))) is a strictly more powerful model than f(x) holding the number of parameters constant.

> Even now, making deep neural nets not sensitive to initial starting conditions is an unsolved problem, but there's been a lot of progress.

You just initialize with a Gaussian ball around zero and explore whatever valley in the error surface you happen to be in. Works 100% dandy.

> I would hazard the guess that the convolutional technique is a lot more useful in deep neural networks than it is in single-hidden-layer neural nets.

It doesn't really make sense to talk about a "single layer convolutional net", because if you only have a single layer, and all you can do is convolve with it, then the output of your net will necessarily be a big pile of filtered versions of the input image. Unless your task is specifically to learn a target set of filters, it would make no sense to have a single layer convnet.

kmavm··on Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
Cliff Click, a smart man in whom I see many admirable qualities, than whom there are few more complete experts on the JVM, gave a tech talk at Facebook about how Java is faster than C++ just a few months ago. Tons of perfectly smart engineers sat and took it seriously. Much of the content was a rehash of this older discussion: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-p...

There are plenty of serious, technically deep people trying to convince their colleagues that Java is as fast as C.

kmavm··on HHVM 3.0.0
Yeah, almost everyone in the real world is using it via FastCGI. People have a huge investment in the configuration and operation of their existing http server (nginx or apache).
kmavm··on Godot Engine open sourced
Torch seems to be a concrete example of a numerically oriented luajit embedding that provides high performance linear algebra primitives. http://torch.ch/
kmavm··on HipHop VM: now at 98.5% PHP framework parity, 16% faster
No worries, sorry for the confusion.
kmavm··on HipHop VM: now at 98.5% PHP framework parity, 16% faster
No. This blog post is about HHVM. The PHP to C++ translator was removed from the HHVM source tree back in February. (I'm an HHVM team alum.)
kmavm··on FasterCGI with HHVM
(HHVM alum here). Sorry you had a tough time. What's changed is that time has passed, and the HHVM team has put a lot of effort into closing the compatibility gap. If you are aware of a bug with namespaces or traits, let us know at https://github.com/facebook/hhvm/issues

http://www.hhvm.com/blog/875/wow-hhvm-is-fast-too-bad-it-doe...

kmavm··on Taking PHP Seriously [pdf]
Video of the talk is not up yet, and it's a little cryptic with just the slides. But one of the points I was trying to make is that PHP actually makes you more likely to be successful than a lot of its competition. The lolsy stuff on "The Case Against PHP" slides is all you ever hear because ... well, because they fit on slides. They're immediately, obviously weird. But these problems are shallow. There are deeper properties of the language and its interaction with the environment that overcome those problems, and then some.

Also, it's a little obscure for languages like PHP where we're unused to making architecture/implementation distinctions, but if HHVM is good then PHP is good. It runs the same core language as php.net. To the extent we don't, it's likely to be a bug these days. I think HHVM is a better implementation of that language than php.net, but I am biased, and that isn't the point of the talk. We're also chipping away at running other popular programs, extensions and all: http://www.hhvm.com/blog/?p=875

Edit: transposed sentence

kmavm··on HHVM is fast – too bad it doesn’t run my code
Hey, HHVM alum here.

The outright language gaps to 5.4 are few and fairly obscure these days, in my opinion. Most practical problems are due to missing or slightly misbehaving extension functions, rather than the core language. You can write programs that produce different output from php.net if, e.g., they depend on the order that destructors are called when killing lots of objects at once, but you can also write programs that differ across minor revisions of php.net. In the absence of a standard, much like pre-standardization C, "PHP" is anything that runs useful PHP programs. We think HHVM qualifies.

HHVM lets you do eval(), and we try to do a decent job of running it fast. We do actually jit eval'ed code, though if you're running in whole-program optimization mode the presence of eval() will prevent lots of compile-time class hierarchy analysis based optimizations from working. Yes, yes, we should be optimistic and deoptimize when we're wrong, it's just easier said than done :).

Facebook disallows eval() in production code for reasons you can probably imagine.

kmavm··on How Three Guys Rebuilt the Foundation of Facebook
Hey, I'm Keith and am one of the subjects of the story.

HHVM is a much, much smaller undertaking than rebuilding Facebook from scratch. Wired did another article from the same source interviews about just how big Facebook is these days: http://www.wired.com/wiredenterprise/2013/04/facebook-window...

Building HHVM was a fraction of the effort, and did not require that we sit on our hands while the competition beat us up during a rewrite.

kmavm··on Facebook Home destroys any notion of privacy
I've worked at Facebook for four years. No, no we don't, no matter what the "guy you know" says. Harrison already provided you with our very strongly worded, official claims to that effect.

Since you're the one claiming otherwise, how about an actual, verifiable example? "Company X paid Facebook $Y for user data Z" doesn't sound like an unreasonably specific request.

kmavm··on Killed by Homeopathy
It was 1864. There were not even a germ theory that had any power to explain his illness, let alone antibiotics with which to treat him.
kmavm··on Killed by Homeopathy
I enjoy a good homeopathy-bash as much as the next guy, but Boole died of an infectious disease. The rain storm he walked through, and the wet blankets he was wrapped in, had nothing to do with the bacterium that killed him. The "cold sensations cause pneumonia" folklore this article relies on is as much magical thinking as the homeopathy it invites us to smugly chortle at.
kmavm··on Speeding up PHP with the HipHop VM
Check out our HHIR work. It's an SSA-based IR, that gets us most of the advantages of a register representation. But it is at a much lower level than the bytecode.
kmavm··on Speeding up PHP with the HipHop VM
Our approach is different from other dynamic language JITs that I'm aware of. While there is lots of diversity out there, most other dynamic language JITs can be roughly categorized as either having a method-at-a-time strategy, or a tracing strategy. Our system is neither tracing jit nor method-at-a-time, but basic-block-at-a-time.

The systems that it has the most in common with are actually binary translators; e.g., VMware's software x86 hypervisor, or the Dynamo system. Those systems run basic block at a time to solve a number of problems; e.g., disambiguation of code and data. We're basic-block-at-a-time for a different reason: closure under type inference.

kmavm··on Speeding up PHP with the HipHop VM
It isn't tracing. Don't be fooled by the name "tracelet".

Unlike trace trees, tracelets contain no control flow. It is just a type-specialized basic block. This means that the jit output does not combinatorially explode when we encounter polymorphism. In many ways, our approach is the opposite of tracing; we jit the first time we hit any code at all. And we look terrible on loopy microbench code, but run FB's multi million LOC application very well.

kmavm··on Speeding up PHP with the HipHop VM
We work for Facebook, and make a lot of announcements on the engineering blog. We also have a group blog on WordPress-in-HHVM running here: http://www.hiphop-php.com/wp/
kmavm··on Speeding up PHP with the HipHop VM
It is closer to 5.3, though we've adopted some 5.4 features: traits, our closures' treatment of $this, and f()[$x] syntax.

Edit: notably not short array syntax, at least yet.

kmavm··on Speeding up PHP with the HipHop VM
HHVM was pretty far along when we started talking to the PyPy folks; it was already able to run the site, and hosting internal development at Facebook. Our interest in PyPy wasn't an immediate, drop-everything-and-change-to-PyPy kind of interest. It was a research project, which had a positive outcome. Making a production-ready, PyPy-based system for PHP would still be an enormously big undertaking, though.

PyPy is taking a radically different approach from what HHVM is doing (and really from what almost all other dynamic language systems are doing), and it's a fascinating system. Part of what's exciting about it is that it seems like it should be applicable to other languages with less effort than most other JITs, and we wanted to understand its potential for a language like PHP. We asked Maciej Fijalkowski (hi, Maciej, if you're reading!) to help us do a research prototype to see what the first few roadblocks would look like, and Maciej did a great job. Just because we didn't scrap our current project and shift all our resources to PyPy should not be seen as a negative reflection on PyPy at all.

kmavm··on Speeding up PHP with the HipHop VM
Hey, I'm an HHVM engineer.

We just normalized HPHPc performance to make the graph easier to read. HPHPc actually got considerably faster over the same period as well; since both systems share a runtime, many changes helped both.

HPHPc probably got about 20% faster over 2012, even though nobody was actively working on it, mostly through happy side effects of work that was directed at HHVM.

kmavm··on Ask HN: Job at Facebook or Google, which would you take?
Yep, the demographics on this thread have changed since I posted. A lot of us read HackerNews, and maybe we contribute out of proportion to our numbers when we see FB getting slammed unilaterally, as was the case before I wrote my response.

We don't use mailing lists much at Facebook, preferring to use Facebook where possible. Like anybody else, Facebook employees who see something of interest on HN often use Facebook to share the link with those friends. There is nothing conspiratorial about this process; it's the same way all other links on Facebook spread through peer groups.

kmavm··on Ask HN: Job at Facebook or Google, which would you take?
I work at Facebook.

First, let's not lose track of the high order bits here: the Venn diagram between these two companies is more overlap than not. Both are large-scale, consumer-facing Internet services. They both build heavily customized datacenters; contribute a lot to open source; write a lot of back-end code in C++; have intricate big-data pipelines that make their products go; solve basic problems in information retrieval; care about ad targeting; contribute research results, and PC members, to CS conferences in various disciplines; will hire every good ML person in the world if they can; and so forth.

There is consequently a lot of overlap between their employee populations. Many people have gone on from work they're proud of at Google to do work they're proud of at Facebook. Some have gone the other way, and as FB gets closer to Google's size there will be more of them in the future. Our kids go to the same schools; this is not the Bloods and the Crips. Choosing between the two is one of those "nice problems to have."

While there are lots of "little" differences, I think most are driven by two primary differences.

First: Facebook is about 10% the size of Google, in both headcount and revenue. (An interesting consequence of this, by the way, is that only about 10% as many Facebook engineers as Google engineers are reading and responding on a "smackdown" thread like this one; you should bear this in mind when skimming them.) I think my friends at Google would agree that engineers at Facebook have considerably more autonomy and responsibility, and less process obstructing the exercise of that autonomy.

Second: Google is famously pursuing many "if-you-build-it-they-will-come" tech-for-tech's-sake projects. Each project represents a small portion of Google's much larger headcount, and yields a lot in PR, recruiting, and hopefully someday in creating revolutionary consumer products. Facebook is focused on those technologies that allow humans to communicate with other humans. That problem space is plenty big, encompassing work in programming languages, databases, networking, data science, information retrieval, machine learning, etc. We leave other technical problems to organizations with other missions; they have smart people, too, who understand their problem space better than we will. This is a classic trade-off between breadth and depth; while neither company is 100% dedicated to one or the other, they have clearly chosen different spots on this continuum.

Finally, if anybody is actually wrestling with this dilemma, and would like to reach out in private, feel free to do so at Keith Michael Adams' initials @fb.com.

kmavm··on Leaving Microsoft
Hey, I'm an engineer on the HipHop team, and a minor-league Haskell enthusiast. A couple clarifications:

1. HipHop is itself written in C++. While this did not logically need to be the case, it is the case.

2. These days our JIT compiler, the HipHop VM (hhvm) is out-performing the PHP-to-C++ ahead-of-time compiler. HHVM is under the HipHop umbrella, and so is also written in C++. If you're vaguely aware that Facebook has some sort of high-performance PHP execution engine, but have avoided investigation because compiling PHP sounds like a drag, check hhvm out; it is fast, and you use it the same way you use a PHP interpreter.

3. HipHop is not our entire PHP stack, however, and functional languages have a significant beachhead in static analysis. pfff (https://github.com/facebook/pfff) is a sophisticated multi-language analysis and transformation framework written in OCaml. We use it for many, many purposes; e.g., at code review submission time, pfff symbolically executes the changed code to look for various dangerous idioms and highlight them as areas for the reviewer to focus attention.

4. There are other projects written in Haskell that, alas, we're not ready to talk intelligently about publicly. Watch this space, however.

Overall, FP has a sizable presence at Facebook. Haskell's presence is a bit smaller than OCaml, though that might be changing. Facebook is definitely "using Haskell more these days," especially since Bryan O'Sullivan (author of "Real World Haskell") came aboard. I expect Simon Marlow will continue to influence things in that direction. From 100k feet, Facebook's adoption of Thrift, and Thrift's tradition of supporting polyglot languages, means that a lot of "niche" languages can flourish within the larger production ecosystem.

kmavm··on Are you on Facebook? Check out MyPermissions
What does this do for me that https://www.facebook.com/settings/?tab=applications does not? Other than ironically nag me to share on social media and sign up for their newsletter for every app I drop?
kmavm··on Jack Dorsey: Let's Reconsider Our "Users"
Naivete and cynicism are not mutually exclusive. "If you're not paying, you're not the customer, you're the product," is a wonderful example of naive cynicism. It imagines that the only participants in a business transaction with full human agency are buyers and sellers; and that if you are neither buyer nor seller, well, the seller and buyer must view you as the not-quite-human product! This meme explains nothing, and reflects a completely broken view of Facebook's business goals. Its cynicism makes it no less naive.

Suppose, for the sake of discussion, that Facebook were a perfectly mercenary, ruthless organization, straight out of HN's collective imagination: it cares nothing about the people using its software, and eats, sleeps, and breathes nothing but monetization. (This view is itself another instance of naive cynicism, but let's grant it to get on with things.) Facebook is still critically reliant on non-paying users continuing to use it; without them, no possible road to monetization exists. Those users are a party to the transaction; they come willingly, and Facebook has no army to compel them to come again tomorrow. Viewing users as inanimate "product" that can be manufactured and sold would be stupid; the "product" is not something that Facebook produced, bought, manufactured, or otherwise has any proprietary claim over.

This relationship is actually pretty close to the relationship that print media have to their readers; your subscription pays for approximately 0% of their revenue; advertisers make newspapers and magazines work. It's also close to broadcast television, where you literally contribute no money to the revenue of the businesses producing programming. It doesn't follow that television studios should view you as inanimate "product"; indeed, television studios work very hard to produce something that real people enjoy, because without those people freely choosing to watch they are out of business.

A much more sensible aphorism would be: "If you're not paying, you're not the customer, you're the audience." This has greater explanatory power, for the behavior of free web service, advertisers, and the audience, which is a willing party to this entire transaction, as the "product" soundbite obscures.

kmavm··on Jack Dorsey: Let's Reconsider Our "Users"
I worked on the enterprise side of the fence (SGI, NetApp, VMware) from 1998 to 2009. We always called them "users" there, too, even though they paid us gobs of money. We do this for the same reason manufacturers of hammers call their customers "customers" when they're buying and selling hammers, but call them "users" when they're using the tool, however they came to possess it. Software is a tool; the people using it are users.

"Customer" emphasizes the transactional side of the relationship. If your check bounces, or you pirated your copy, etc., you're no longer a "customer".

kmavm··on How Eduardo Saverin Sold Facebook Ads in 2004
A common misconception. It was Peter Wolf, lead singer of the J. Geils Band.

http://www.quora.com/Who-was-the-Facebook-Guy-in-the-origina...

kmavm··on A Fee-Based Twitter Is No More Ideologically Pure Than An Ad-Supported Twitter
When people say that Facebook "sells your data," they're (charitably) engaging in hyperbole to strengthen their rhetorical point, or (less charitably) lying. Facebook shows ads to the users they're targeted to, without sharing the users' details or identities with advertisers.
kmavm··on Coding Horror: The PHP Singularity
The entire point of my post was that we preserve the semantics of this (and many other) PHP-isms. We have to, because you never can tell which glitches useful code has come to depend on.
kmavm··on Coding Horror: The PHP Singularity
Nobody's asking you to like PHP. I'm explaining why it's effective; if you'd like to build something better, there are affirmative lessons to learn from PHP's undeniable successes. While your point about Erlang is correct for pure PHP, one of the nice things about the "curl as concurrency model" world is that the thing on the other end of the curl doesn't have to be PHP, or stateless.

Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.

Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.

← PreviousPage 2 of 9Next →