4,014 karma · joined May 14, 2008
As said GP, yes this is exactly what I meant and "happy-path" was an unclear choice of words. They optimize for the unhappy path on the good days, and make the bad days much worse.
1. People add retries w/o backoff. Now we have a retry storm.
2. People don't add jitter so we get huge waves of highly correlated retries that cause self-perpetuating overload cycles and failure.
3. People add retries (even w/ backoff) at more than one layer (e.g. one in process, one in envoy), so now we have a deeply confusing multi-level of retries with super weird n^2 patterns.
4. People find ways to fetch from multiple data sources to make a composite object but don't cache/reuse data they fetched, so one data source being down causes DOS on _other_ data sources because of retries.
5. People add failover mechanisms where all failures happily pick the same failover target because, ya know, it has the most free capacity.
6. People underestimate connection setup cost so "failover" causes huge increase in overall load due to connection setup (often tls setup) causing huge influx of "new" cpu work in a loaded system. CPU spike causes unhealthy destinations, causing more failovers, causing metastable failure.
7. People realize purely local decisions aren't optimal so add a layer of global health metrics (e.g. global retry budgets) but these systems add a time delay to the metric (ie its the view of the world 5ms ago). This delay makes their naive control algorithm go into oscillations or divergence spraying stuff everywhere.
All of these things have a similar pattern that when things are almost all good, they will make the system more robust. You'll get an extra 9 of reliability on good days. But they make everything far worse when things are bad.
Other indexes do not have these multipliers, and are much larger. The exposure for e.g. VTI is far, far less.
VTSAX (and VTI) follow the CRSP index. This is float-adjusted but they likely will be fast tracked (these are two separate rules in how this index chooses to weight things and participate in new stocks). At ~5% float, these companies will be in the 50-100B range. So under all those assumptions, they'll be bought quickly but represent less than 1% of VTSAX (until they float more shares on the public market).
Some index funds have a very long horizon before they include them (e.g. a year). Others are "fast-tracked" (e.g. notably VTI). Most of those, however, are float-adjusted, so only the stock available for trade is considered part of the marketcap. So e.g. VTI / VTSAX will buy spacex relatively quickly after the IPO but at the float-adjusted weight of ~$75B because that's the % of stock available.
If you care alot about this, now is the time to understand how your index fund treats IPOs wrt to delays + float adjustment.
While I have almost zero belief that LLMs are conscious, I just don't think this is so trivially asserted.
The easy half of this is thinking that LLMs aren't conscious given what we know about how they work. The hard part (and very, very famously so) is explaining how _you_ are conscious given what we know about how you work. You can't ignore the second half of this problem when making statements like this... because many of the obvious ways to argue that clearly LLMs aren't conscious would also apply to you.
While I see what you are getting at, and I think its super important we come up with philosophical frameworks to push back on the central idea in question (ie, the moral hazard of "its gonna happen anyway so why not pour a little more into the river").... I think your writing/responses miss the central point.
As I see it, the fundamental issue with this essay, and your responses, is you keep conflating impossible with probability zero. People are saying "this is inevitable" to mean this has probability 1 of occurring, with basic game theory reasoning (its a giant iterative prisoners dilemna), and your response "but it's possible". Yes, with measure zero.
Telling us that such a path surely exists isn't useful. If you want to push back on "inevitability" you need to find a credible path with probability > 0 (which is not the same as impossible).
Even though all the criticism were, in a sense, valid, in the end none of it amounted to a serious challenge to getting good at the task at hand.
The premise that an AI needs to do Y "as we do" to be good at X because humans use Y to be good at X needs closer examination. This presumption seems to be omnipresent in these conversations and I find it so strange. Alpha Zero doesn't model chess "the way we do".
Though this was not the post I was expecting to show up today, it was super awesome for me to get to have played my tiny part in this big journey. Thanks for everything @je (and qi + david -- and all the contributors before and after my time!).
The top reply to the top comment has some useful quotes for the purposes of this discussion...
> This is not going to be one of the best tech acquisitions of the next decade.
> Instagram is a photo service in a sea of other photo services.
> Bookmark this comment. See you in 2022.
Heh.
Well... "a few" is probably more accurate.
https://twitter.com/tjaltimore/status/1763571057703723344?s=...
I have seen so, so, so many examples of systems where latencies, including and especially tail latencies, end up mattering substantially and where java becomes a major liability.
In my experience, actually, carefully controlling things like p99 latency is actually the most important reason C++ is preferred rather than the more vaguely specified "performance".
I fear there's going to be alot of homerolled "vector search" infra that accidentally wanders into an ocean of database problems.
It’s embarrassing, shortsighted, and destructive.
Having 1000 dependencies with versions pinned means you are living alone and will run into fewer issues, but when they do come, they will be absolute nightmares that no one else is dealing with and no one can help with. And one day you'll have to do the game of begging someone else to upgrade their version of a downstream thing to fix the issue, and they won't, so you'll try to get the other group to backport the fix in their thing to the version you can't upgrade off. And they won't. etc. etc.
Full versioning is the worst of all approaches, IMO, for large complex interconnected codebases (especially ones that are many-to-many from libraries to output binaries) but it absolutely is sometimes the only viable one (for example, the entire open-source-ecosystem is a giant(er) version of this problem, and in that space, versioning is the only thing that I can imagine working).
Carroll and others have a compatibilist notion of free will which is a more subtle concept that I'm not sure I'm qualified to actually explain.
This paper is doing the opposite. It's arguing that other papers/ideas advocating dualism are going the wrong way and purely physicalist explanations are the best path forward.
1. The laws of physics at the time scales, space scales, and energies of the human brain are "known" and we have deep reasons to believe that more will not be discovered. He spends a great deal of space explaining and arguing that the credence that physics is "complete" in this regime should be very, very high.
2. Given the current laws of physics, there is no place or room for non-physicalist explanations of consciousness (or, I suppose, for other dualist ideas like a soul) because there is no mechanism for them to effect change in the physical world.
3. Anyone who wants a non-physicalist approach to consciousness must either claim they can violate the laws of physics in our brains, or cannot affect the physical world.
Go watch the Lockpicking Lawyer on youtube pick locks and trivially crack/open every lock ever made. This is, roughly, the best physical analog to what happens with computer programs and safety. The creators are trying but they have to be correct everywhere, from every angle, and the attacker only needs to find one weakness to break it.
However, you missed a _super_ important caveat of this which is very subtle and very awful. And that is all of the code being executing here between the start of the function and the copy of the shared_ptr is doing it without the protection of the reference count on the shared pointer. It's entirely conceivable that, for example, the `has_widget` function, while executing, invalidates the original shared_ptr passed in and thus makes your eventual use of that shared_ptr invalid.
One important update is that the primary rationale for us, at the time, to change std::string's implementation to `fbstring` was to get SSO. We got huge perf wins for having SSO on std::string. (small string optimization for those unfamiliar with the initialism).
This, at the time, was a violation of the standard. By wording, SSO was not standard compliant.
Once the standard was changed (as of C++11) so that std::strings could have SSO, we removed our patches on the standard library and now use "vanilla" std::string (from libstdc++). We still have `folly::fbstring` for people who want that implementation (which is smaller, and has more in-situ capacity, because of various cleverness detailed in that talk), but it's no longer our `std::string`.
For reference: https://github.com/facebook/folly/blob/master/folly/FBString...