HN user
Respectfully, it's not up to other people to disprove your toy theory. The question you're asking here can very easily be answered with a quick Google search.
The short answer is that they are _very_ different controls, that looks and operate in a completely different way, located in a different place, and it's completely unrealistic to think a pilot could have mistaken one for the other.
A hallmark of well-designed and well-written software is that it is easy to replace, where bug-ridden spaghetti-bowl monoliths stick around forever because nobody wants to touch them.
Just through pure Darwinism, bad software dominates the population :)
I just wanted to give a huge shout-out to the excellent zune-jpeg library: https://github.com/etemesi254/zune-image/tree/dev/crates/zun...
Most Python libraries like PIL rely on some flavor of the venerable libjpeg (e.g. libjpegturbo, mozjpeg) which makes it the de-facto standard for loading jpegs.
A notable downside is that it's written in C and there have been more than a few exploits found inside it over the years. While it's pretty damn mature by now and there has been a huge amount of fuzzing done to tease out remaining issues, fact remains that it's yet another attack vector that makes your resident security guy or gal raise a few eyebrows.
With zune-jpeg you get a fully memory-safe implementation that can act as a drop-in replacement, and when you turn on the (admittedly experimental) SIMD support for things like the IDCT and color-space conversion it's as fast, or in places even faster, than libjpegturbo/mozjpeg, even on very large (e.g. 4k by 4k) images.
As always, it depends a lot on what you're doing, and a lot of people are using Python for AI.
One of the drawbacks of multi-processing versus multi-threading is that you cannot share memory (easily, cheaply) between processes. During model training, and even during inference, this becomes a problem.
For example, imagine a high volume, low latency, synchronous computer vision inference service. If you're handling each request in a different process, then you're going to have to jump through a bunch of hoops to make this performant. For example, you'll need to use shared memory to move data around, because images are large, and sockets are slow. Another issue is that each process will need a different copy of the model in GPU memory, which is a problem in a world where GPU memory is at a premium. You could of course have a single process for the GPU processing part of your model, and then automatically batch inputs into this process, etc. etc. (and people do) but all this is just to work around the lack of proper threading support in Python.
By the way, if anyone is struggling with these challenges today, I recommend taking a peek at nvidia's Triton inference server (https://github.com/triton-inference-server/server), which handles a lot of these details for you. It supports things like zero-copy sharing of tensors between parts of your model running in different processes/threads and does auto-batching between requests as well. Especially auto-batching gave us big throughput increase with a minor latency penalty!
"This is actually good for Bitcoin"
That has been my experience, yes. You need one full-time manager, one full-time on-call/pager duty (usually a rotation), and then 4-6 people doing feature development, bug fixes, and operational stuff (e.g. applying security patches, tuning alarms, upgrading instance types, tuning auto-scaling groups, etc. etc.).
Maybe you can do it a bit cheaper, e.g. with 4-6 people, but my point is that there's an on-going cost of ownership that any custom-built solution tends to incur.
Amortizing that cost over many customers is essentially the entire business model of AWS :)
The cost doesn't suddenly drop to zero once development is done. Typically a system of this complexity and scale requires constant maintenance. You'll need someone to be on-call (pager duty) to respond to alarms, you'll need to fix bugs, improve efficiency, apply security patches, tune alarms and metrics, etc.
In my experience you probably need a small team (6-8 people) to maintain something like this. Maybe you can consolidate some things (e.g. if your system has low on-call pressure, you may be able to merge rotations with other teams, etc.) but it doesn't go down to zero.
you could get yourself 25 top-notch engineers without AI PhD
Not in the US though. According to levels.fyi, an SDE2 makes ~275k/year at Uber. Hire 25 of those and you're already at $6.875MM. In reality you're going to have a mix of SDE1, SDE2, SDE3, and staff so total salaries will be higher.
Then you gotta add taxes, office space, dental, medical, etc. You may as well double that number.
And that's just the cost of labor, you haven't spun up a single machine and or sent a single byte across a wire.
I'm guessing they know a lot about their costs, and you know very little.
I'm curious what makes you believe the OP doesn't know about cost? They might be director-level at a large tech company with 20+ years experience for all you know...
There's little value in insulting the team members like this.
I'd argue it's not insulting to question a claim (i.e. 'we saved $6MM') that is offered with little explanation.
I'd be curious as well to see a more complete cost-benefit analysis, and I'd be especially interested in labor cost.
We don't know how much time and head count Uber committed to this project, but I would be impressed if they were able to pull this off with fewer than 6-8 people. We can use that to get a very rough lower-bound cost estimate.
For example, AWS internally uses a rule of thumb where each developer should generate about $1MM ARR (annual recurring revenue). So, if you have 20 head count, your service should bring in about $20MM annually. If Uber pulled this off with a team of ~6 engineers, by AWS logic, they should about break even.
Another rule of thumb I sometimes see applied is 2x developer salary. So for example, let's assume a 7-person team of 2xSDE1, 3xSDE2, 1xSDE3, and 1xSTAFF, then according to levels.fyi that would be a total annual salary of $2.3MM. Double that, and you get $4.6MM/year to justify that team annual cost footprint, which is still less than $6MM.
Of course, this is assuming a small increase in headcount to operate this new, custom data store, and does not factor in a potentially significant development and migration cost.
So unless my math is completely off, it sounds to me like the cost of development, migration, and ownership is not that far off from the cost of the status quo (i.e. DynamoDb).
In 2012 we had Internet deployment of fully decentralised machine learning (SGD)
Peer-to-peer training of the next big LLM when? :)
Kayak lets you do it, although there's no guarantee the airline won't swap out the plane from under you after you've completed booking.
You may not have ever experienced this yourself, but it's a known cultural phenonemon. Here's a New York Times article: https://www.nytimes.com/2023/11/29/technology/personaltech/a...
Over time, the annoyance and frustration that built up between blue and green bubbles evolved into more than a tech problem. It created a deeper sociological divide between people who judged one another by their phones. The color of a bubble became a symbol that some believe reflects status and wealth, given a perception that only wealthy people buy iPhones.
...
On dating apps, green-bubble users are often rejected by the blues. Adults with iPhones have been known to privately snicker to one another when a green bubble taints a group chat. In schools, a green bubble is an invitation for mockery and exclusion by children with iPhones, according to Common Sense Media, a nonprofit that focuses on technology’s impact on families.
“This green-versus-blue issue is a form of cyberbullying,” said Jim Steyer, the chief executive of Common Sense, which works with thousands of schools that have shared stories about tensions among children using messaging apps.
As a European living in the US, it's been baffling to me. Everywhere else in the world people use WhatsApp, Telegram, Signal, etc. This iMessage green/blue bubble nonsense just isn't a thing outside the US.
AWS has its own line of AI accelerators called Inferentia that offers reduced cost versus Nvidia, but it's often a pain to make stuff work because everything is written for CUDA. Inferentia team spends a lot of time porting OS models to their hardware for customers to use (e.g. through SageMaker).
Decoding DCT to RGB is essentially an 8x8 stride 8 convolution -- it seems wasteful to perform this operation on CPU for data loading
Then why not do it on the GPU? Feels like exactly the sort of thing it was designed to do.
Or alternatively, use nvjpeg?
OceanGate had previously taken the Titan to this depth to visit the Titanic. So, it was "proven"
This reminds me of an old joke about an optimist who falls from a 40 story building. As he passes the 30th story he thinks to himself, 'so far so good!'
Damn those are some good names
Maybe also take a look at the Mister project if you haven't already. Same idea of using FPGA to reproduce old hardware but broad support for many home computers, game consoles, and arcade boards
If you're in NYC and want to grab lunch let me know
+1
I work at a bigcorp and have had great mentors, and now that I'm an old fart, I try my best to mentor others. It's a huge plus to have access to a large community of talented engineers
the JVM needs to be well tuned
You don't need to tune it to beat the pants out of a PHP-based solution.
Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?
India and China go in a different bucket, and it often takes 6+ years for the exact same process. Sucks hard :|
I'm assuming that based on your username, you are an EU citizen? If so, apply for a job with any large US based company in one of their European offices. For example, Google in Zurich or Dublin, Amazon in London, etc.
After one year, you qualify for what's called an L1B 'internal transfer' visa. You can then transfer to another team within the same company that's based in the US. In many cases the company will sponsor your visa application and even the cost of moving (e.g. plain ticket, cost of shipping your belongings, etc.)
Once in the US, you can start the application process for a green card. As long as you're not a citizen of either India or China, this should take 2-3 years.
I'm Dutch and this is the path I took.
I'm Dutch and moved to the US in early 2016 to work for a bigtech company. Compensation here is about 3x what I would make back home.
After working here for just six years I could move back home and buy a house outright with the money I've been able to save.
I don't need a big house or a big car, but making more money means I can coastfire in the next five years, so it's absolutely worth it to me.
You said:
Hell, there's still a lot of 5.x deployments out there that work just fine.
forgive my ignorance but I was under the impression 5.x isn't actively maintained anymore?
Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve.
Nobody is saying that. The golden rule of API design is do not break your customers.
The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
Because, suprisingly, Noone is forcing you to update immediately!
Excuse me, where do you work? Do you not have a company policy about not using software that isn't actively receiving security updates?
Even my preferred IDE, the Jetbrains suite which I love, are resource hogs
Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?
Well then, given how much of a memory hog Chrome is, I guess we can all shitcan C/C++ as well.
Look, in any reasonable apples-to-apples comparison the JVM blows anything PHP has out of the water, including haxe, hiphop, etc.
And even if you write a PHP-to-bytecode compiler (e.g. https://github.com/jphp-group/jphp) then there are certain limitations to how fast and efficient any dynamically typed language can be. Look at all the shit V8 has to go through to do field lookups: https://v8.dev/blog/fast-properties
And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.
And if you really hate Java as a language, you can always use something like Kotlin.