kahnjw

I can’t exactly tell what you mean but I think you’re confusing two levels of abstraction here. C++ (or rust) and python already work in harmony to make training efficient.

1. In tensorflow and similar frameworks the Python runtime is used to compose highly optimized operations to create a trainable graph. 2. C++ is used to implement those highly optimized ops. If you have some novel feature engineering and you need better throughput performance than a pure python op can give you, you’d implement the most general viable c++ (or rust) op and then use that wrapped op in python.

This is how large companies scale machine learning in general, though this applies to all ops not just feature engineering specific ones.

There is no way that Instagram is using a pure python image processing lib to prep images for their porn detection models. That would cost too much money and take way too much time. Instead they almost certainly wrap some c++ in some python and move on to more important things.

Latency in training literally does not matter. You care about throughput. In serving, where latency matters, most DL frameworks allow you to serve the model from a highly optimized C++ binary, no python needed.

The poster you are replying to is 100% correct.

This is just not true. The python runtime is not the bottleneck. DL frameworks are DSLs written on top of piles of highly optimized C++ code that is executed as independently from the python runtime as possible. Optimizing the python or swapping it out for some other language is not going to buy you anything except a ton of work. We can argue about using rust to implement the lower level ops instead of c++. That might be sensible though not from a perspective of performance.

In a "serving environment" where latency actually matters there are already a plethora of solutions for running models directly from a C++ binary, no python needed.

This is a solved problem and people trying to re-invent the wheel with "optimized" implementations are going to be disappointed when they realize their solution doesn't improve anything.

Add to that investor pessimism driving bond yields down or inverting them, a trade war, bad global growth numbers, and investors sucking every last penny out of the stock market while there is still time. That's all you need for a downturn.

That said I'm not predicting a huge downturn. As long as there is some political correction back towards the center or left, which there usually is after a downturn, they'll be driving the Dow to 35k+ in no time. History repeats itself.

I was thinking the exact same thing. Technical debt accrued at a large engineering organization is very similar to bloated infrastructure costs in the US. That also doesn't explain the _why_.

My very rough take is that physical (and virtual) infrastructure require more labor specialization as the complexity of the existing system increases. In order to get that subway built you need specialists come in to make sure the roads can withstand extra stress from tunneling etc etc. Those specialists are expensive and miss-communicate with other specialists etc etc.

>Neural nets are infamously incapable of generalising beyond their training dataset

In what sense? DNNs can certainly generalize to examples outside the training set. I agree that you get no guarantees on performance for samples drawn from a distribution that is different than the training/test set. Not having guaranteed expected performance isn't the same as "incapable" of generalizing to a new distribution.

Of course. I didn't start out my career thinking I'd solve all the problems a given company has. I think that hero mentality is the reason a lot of startups fail, at least in a technical sense. I always viewed engineering in general as a process of abstracting complexity into easily understood components. Why do the hard work of making good abstractions if you don't put them to use by specializing your employees?

>I'd say also, I currently perceive Google/Facebook as a place to "slow down". They're big enough and have enough resources to do anything they want, so it seems like there's gonna be a lot of people just hanging out and going the slow route.

Having worked in a startup and midsize environment and now at Google my experience has been the opposite. Getting to focus intensely on one or two projects at a time allowed me to push the needle on velocity. I don't push as many LOC, sure, but that isn't how I measure impact or progress. At Google I can make measurable, verifiable impact using a development cycle the loops over a few days. It's very hard to do that even at midsize companies.

This is what I meant, I should have been more clear.

The fields of neuroscience and psychology are far more advanced compared with the infantile field of deep learning.

Humans also learn independently from one another which means outlier events aren’t as much of a problem. You have the ability to observe the world around you, say you see an accident due to some rare weather event, and learn some abstract lesson extremely quickly. A CNN has to learn this over millions of samples out of band.

EDIT: clarification in last sentence.

>> I'll respond clearly: We're multiple computer vision leaps forward away from what Elon needs for success. They're easily half a decade behind Lidar based systems. And people die as a consequence of putting those systems on the road.

>Custom ASICs for ML that Tesla is building is fairly well-understood tech at this point. High-end smartphones have used similar tech for years now

joshuamorton is right and you didn't really address the point made. It isn't about understanding the hardware, it's about understanding the software. You point me to any individual who can tell you concretely how a specific convolutional neural network (CNN) arrives at a given solution and I'll take this all back.

We know so little about how CNNs work, and plane old neural networks (NNs) for that matter, it's embarrassing. They're prone to adversarial attacks, not only that, you can successfully mount the same attack against _any_ NN that was trained on a common dataset. We don't know how to effectively defend against these yet in a white box setting.

We have no idea what the solution space looks like. We barely understand why one of the most simple optimization algorithms outperforms almost all others on at these tasks. We barely understand why randomizing data visitation results in solutions that perform completely differently.

The counter argument goes something like "we tested it on a big eval set and it aced it" Well I'm here to tell you that things change. Assumptions made in creating that eval set might not generalize to all real-world cases. And in this case bad assumptions result in death.

As someone who has spent a good portion of my life working on this stuff I've learned that sometimes (most of the time) the best choice is the obvious, known, simple one. The fact that a good portion of cars may be controlled via something we know so little about should worry you.

On a different note, I think you're also missing why Tesla have opted to invest in a percept suite that doesn't use LIDAR. That reason is cost. Tesla needs to sell cars now. They and their customers cannot afford to put LIDAR on their current platform. At the same time they need to move the metal and they know their customers want AEVs. I think their strategy is sound from a purely business cost/benefit analysis. It's a risk but from a financial perspective a good one, because if it works they hit pay dirt.

No it's just borderline unusable on anything other than a desktop and full of scams.

You could run a smallish linear model on 2kb easily. Definitely not a deep net though.

>EDIT: Ah, I see that Thiel said elsewhere that China already carried out espionage inside Google and hasn't backed this up. That claim is absent from this op-ed but it may be CYA for those comments on his part.

I'm sure editors at the Times struck that as well. Still it makes you wonder, why publish him at all?

Context: Thiel originally made this claim in a speech where he claimed Google is committing "treason." [1] Given his "evidence" that's obviously insane. A large fractions of large multinationals have offices in China. I assume the editors at the Times told him that was a non-starter so he toned it down a bit.

Nowhere in the article does he disclose that he, at one point, owned 10% of facebook, a top competitor of Google's.

Most ironically, Facebook announced they'd open an office in china over a year ago [2].

He makes unsubstantiated claims that technology coming from this lab will be useful in the military before all else etc. He neglects to mention Google's public intent for the office, which has nothing to do with the military [3].

[1] https://www.axios.com/peter-thiel-says-fbi-cia-should-probe-... [2] https://www.theverge.com/2018/7/24/17607992/facebook-allowed... [3] https://ai.google/research/join-us/beijing/

Pretty unbelievable the times published this opinion piece by Thiel. Without any real evidence to back his claim and given Thiel's past, its hard for me to imagine this isn't him pushing a false narrative for some emotionally charged ulterior motive.

The only sane way I can map the problem in question onto your analogy is by subletting rent controlled units, thereby increasing their value and decreasing the value of the uncontrolled unit. I don’t think it’s a good analogy because people have all sorts of subjective bias based on experience. Also real estate is inherently sparse and illiquid. The drug market isn’t sparse and has more liquidity.

I think explaining the economic dynamics directly leads to a self evident conclusion: internationally drug prices would increase as US consumers add to demand on foreign markets. Domestic prices would fall for the same reason

>we would like other countries to pay a bit more too and help shoulder the cost of R&D for new drugs and treatments.

Allowing reimportation would do exactly that by increasing (from zero) US demand for drugs from foreign markets.

EDIT: for explaining why.

There is ample research supporting the notion that rent control increases prices and gentrifies neighborhoods [1][2][3]...

The reason I believe this is economics 101. People want simple solutions to difficult problems. If prices are too high, we create laws that keep them low (so simple!). Problem is that supply is finite, even with new units being constructed cities have been unable to keep up with the influx of new residents. In many cases this is due to other similar suffocating regulations around building height, density, inability to pay out current residents for new construction etc. When supply is sparse and prices are often 50% less than market rate for long term renters, you increase their incentive to stay. That further restricts supply and prices go up for anyone not under contract. If you have an alternative theory of how this would work, I'm curious about it. What are the dynamics, beyond "prices are cheaper"? How does rent control reduce or solve a housing crisis?

>And if it does not increase supply of new construction then it is zero sum gain.

That's a hard thing to prove but I'd wager that isn't the case. Playing forward the rent control dynamic, it's likely that landlords could extract more money per unit on average than they would have in a less supply restricted market. The housing market is far from perfectly competitive without rent control. Landlords have many tools at their disposal to jack up prices beyond what the fair market value is with and without rent control. If the turnover rate is lower, those tools become easier to use. There are fewer comps and almost zero competition. That leaves a wider lane for price gouging on everything from rent to parking to laundry.

[1] https://www.brookings.edu/research/what-does-economic-eviden... [2] http://freakonomics.com/podcast/rent-control/ [3] https://www.city-journal.org/html/does-rent-control-help-poo...

The point isn’t about the supply of new construction but rather about supply of open leases. Rent control incentivized renters to stay put thereby reducing supply for potential residents. Limiting supply increases prices which further incentivized renters to stay put. And on and on.

Removing rent control hurts current renters in the short term. It also removes restrictions on supply that improve the overall health of the market over a longer time horizon.

You're suggesting there is some causal relation here that I'm not sure exists. Desirable cities have housing crises. Those cities implement policies to attempt to abate these crises. Ironically, theory says that restrictions like this make the crises worse: what incentive does it give renters except to hold their leases, thereby further restricting supply?

That theory seems to hold up in a most cities, see SF, LA, London, NY etc. The introduction of rent control did nothing but to reduce housing availability and increase prices.

This argument can be extended to any market with barrier-to-entry level high fixed cost and low variable cost. That's basically every large tech platform (search, social, ecommerce, cloud).

I keep hearing people say some variation of this without understanding the irony of the statement. A perfectly competitive market means, among other things, that there is zero barrier to market entry. That means you can enter the market without large capital spending. Given the amount of capital plowed into these gigantic platforms, any statement starting with "if tech were truly competitive..." is purely hypothetical and probably always will be.

My guess is they felt they didn't have a choice. Having worked at a company with a very large AWS bill in the past, they actually listen to what their customers want. I also think it's clear that most cloud-going engineers and decision makers wanted a solution like k8s and "native" cloud support for it.

If they had chosen to use their own proprietary platform they risk Google and MSFT peeling customers away who want to work on a well designed open and portable orchestration platform. That might start slow but Amazon didn't get this big by allowing competition to take customers without throwing their own punches. They could have made their own _open source_ platform that would directly compete against k8s but by the time it was clear that demand was huge (I'm thinking early 2016) k8s already had to ton of momentum. Again they probably saw that and figured this was the best move with a high probability of success, even if it meant less lock-in.

They also have a whole slew of other products that serve almost exclusively as lock-in mechanisms. One truly portable product isn't going to be a huge deal.

EDIT: Distinguish proprietary and open source options in the second paragraph.

> The super perplexing thing is that cloud providers jumped on the kubernetes bandwagon so quickly and this is what made this commoditization possible. Pessimistically speaking, this means either they're either about to butcher the cross-cloud usability of kubernetes (i.e. drift between EKS,AKS,etc) or kubernetes was a wolf in sheep's clothing from the start.

Is it perplexing? Didn't Google do the same thing with Chrome and Android? Understandably those aren't enterprise systems, but they successfully entered a market by open sourcing something that became wildly popular. In the case of Android and k8s, user cost is also reduced. Once it was clear that k8s won over mesos and docker's solution, AWS and MSFT didn't have much of a choice but to adopt it.

But then engineer X can't claim the watchtime gains and get promoted.

How do you square that with a security cameras? Do you need to consent every time you enter a space secured by them?

Collaborative editing is very difficult to implement in a pre-existing codebase. Decisions made during the initial design will be prohibitive to just bolting on collaborative editing in the future.

To me, xi seems like an aspirational project, so this seems like the perfect place to take some time and design for these features up front.

Can Uber count on being the incumbent the way Amazon did? Amazon built up physical logistics infrastructure and a subscription service that serve as a barrier to entry for competitors. Uber's only real market foothold is a network of drivers, the turnover rate of which is high. To most users, ride shares are a commodity. Savvy user's already check available services prior to booking.

Question: for data keyed by user, did you find you'd actually be better off using an distributed in-process cache than a remote cache? I find that hard to believe but maybe I'm just not up to speed on how advanced these caching solutions are.