It seems off because the jobs just a byproduct of the investment, not the end goal.
i.e. Say I invest $10M to make a precision machine shop and I employing 5 machinists, as a crude example. Here my goal was to make a machine shop capable of producing precision parts, not to spend $2M/job.
Memory on the m1 doesn't behave like it does on x86. My 16 GB intel macbook feels like a boat and sounds like a airplane taking off at load. My 8GB mini feels fast and is silent.
What do you mean for "behave", there are a lot of usecases that require more than 8GB memory (expecially for developers) and there is no CPU magic that will help you with that.
How does Google link the real life person who bought Voltaren at a store to the online account or fingerprint that browses the Internet?
Often, through the payment.
People use the same payment methods in the same stores over and over. This data is accumulated by the stores, and sold. if you signed up for a "points card" or some other gimmick to get 2¢ off something, the personal information you used when you signed up is added to the profile.
What you bought in the store is added to your profile (within legal limits in certain jurisdictions).
Some stores have devices that listen to your mobile phone's identifiers (wifi, Bluetooth, etc) and add that to your profile. Now the data profilers know what other stores you shop in. Some stores are experimenting with facial recognition (Walgreens). That gets added to your profile.
If you go to several in a single day, your route between the stores can be guessed. If you go to one or more places (stores, parking garages, streets that pass parking lots) that have sensors that read the NFC chips in your car's tires, then that can be added to your profile.
Now they know everywhere you go, everywhere you shop, everything you buy, how much you buy, how much you spend, your race, your gender, how you dress, what brands are displayed on your clothing, and any visible hair, moles, or tattoos.
That's just off the top of my head.
And people wonder, "Wow. I am a little scruffy. How did Facebook know to show me an ad for a razor?"
That doesn't help if you use a loyalty card, which a lot of people do for the promos.
And even if you pay via card/phone ( which is literally multiple times faster and less hassle), the payment processor and card issuer don't know the individual items.
I don’t think Google linked the account directly to the purchase. My guess would be that Google linked the account to the medication based on patterns from one of its many ways it gathers data.
* visits to websites about that medication
* visits to websites talking about symptoms for which the medication helps
* searches for the above
* I would not be surprised if Google picks up interests from other accounts using the same WiFi (or even other devices on close proximity)
* there are some scary stories about Google/FB/Amazon listening to conversations
I do most searches in an incognito window so it can't be browser history.
In some cases, it's even something like my wife joking about selling the car to a friend on WhatsApp, and suddenly Facebook show ads where you can sell the car. One time I told my wife to buy something at the grocery store (verbally, no text) and FB shows me the ad for that exact item.
> I do most searches in an incognito window so it can't be browser history.
Incognito mode is mostly a convenience for you to do browsing without saving local history or cookies. It doesn't stop tracking.
I assume the fingerprint is different in incognito versus a regular window. But unless you are using VPN/adblockers/pihole/etc your browser is still executing third party JS and potentially sending tracking data to google using a plain https connection coming from your residential IP.
I can imagine it's not that hard for Google to link different requests from the same IP with slightly different fingerprint data to be coming from the same user.
edit: and for searches it is even easier, because you are communicating directly with google by performing the search, no tracker or JS necessary.
We had a similar thing happening to us: Wife and I have no kids and have no plans to have them. Kid related stuff is just not part of our everyday interactions. One day we visit some friend who are a couple with kids and in that visit we TALK about babies and rising kids and whatnot. Next day my wife (who has the FB app Installed), starts getting kid's diapers ads. I dont have FB app and I dont get those ads.
My comment was an expansion on GPs second bullet point. It’s not Google that knows about the purchase, but Google that “somehow” picked up contextual info from OPs environment linking OPs online identity to Voltaren as a product.
Edit: the purchase could have been involved somewhere in the chain but it’s not necessary.
> Your purchase landed some key about you in a bucket that was mixed and repackaged with many other keys that the advertiser knows as "keys recently interested in Voltaren."
There's not really that much ambiguity in this sentence from the second bullet point.
Unless my mental model of online advertising is wrong, your physical in-store purchase should not be landing you in some Google advertising bucket.
I completely agree that they should not show up. It looks like I went lightly over that sentence and focussed more on the one after:
> Some of those keys are related to people who bought it, or who searched for it, or more indirectly who lingered while reading a page with an ad for it...and in most cases are very short lived.
I think it's the last option. His phone probably heard him ordering Voltaren. It's also the simplest possibility (Ockham's razor).
I know because after discussing extremely rare chemicals at an officemate's desk, he began seeing ads for them. Neither of us had ever Googled or emailed anything related. It was a brand new idea for a brand new project which we had started working on that morning.
This is not the simplest possibility. Based on how often Google Home misunderstands the simplest queries, the tech is nowhere close to getting purchase intents out of random conversations. Besides that - do folks on hn really believe the „our phones are listening 24/7“ conspiracy theories?
We don't want to believe but here we are. [ha, ha] Our robotic overlords don't even need to be sure, sounds-like is good enough, apply some exotic filters and odds to sell things go though the roof.
My funniest was talking with someone at work (who works for a different company) then when I got home facebook suggested adding them. That I didn't have a phone at the time made it extra comical. Plenty of other people work there, it never suggested those and there are no common contacts. How the CONSPIRACY works exactly I have no idea, the candidate theories are all to hard to imagine. (Like, I'm easy to track because I have no phone?)
My android phone often asks how did I like this or that shop. Sometimes I was just passing by those shops but on average the phone is quite correct which shops I have visited.
Google knows when you are in the pharmacy and might use a different routine interpreting ambient sounds when you are there. Voltarol (ibuprofen gel) is a distinct sound that even very lossy algorithm with low level of processing power can distinguish with a sufficient level of accuracy.
Can you prove neither of you Googled anything related? Surely either you or your office mate could have done further research later on, which would involve searching those chemicals online and browsing Web pages related to them?
Alternatively if someone near you overheard your conversation, and Googled it, then Google could link all of your locations together and conclude that you are all interested in the same thing. This is how Facebook has its creepy ability to indirectly predict what items you are interested in - usually someone near you searches for what you're talking about later on in the day, and it guesses that it's important to both of you.
There's a lot of online marketing companies that do a lot of work in this area. It's pretty easy to do if you have any kind of ID or token to link the data. It can be done with credit card numbers, a phone's location services, membership programs, coupons, etc. Here's some of the stuff Facebook does, which just scratches the surface of what is possible:
You can't control the data being transmitted. The analogous process in the macro-world is:
I take a red ball and a green ball and put them into identical looking boxes. I hand one to you and send you to Mars. Then I open my box and see a red ball. I instantly know that you have a green ball in your box, even though it would take 20 minutes for light to travel between Mars and Earth.
The difference is that in the quantum world, each ball is in a superposition of red and green. Once I open my box and collapse the superposition to red, your ball is green, and I know information about your ball that we didn't know when we were together (since at the time we were together, the balls were in superposition).
I also wondered if there is some catch like A knows that B knows new information faster than light, but both essentially just observed the same random phenomenon and there was no input from A reaching B.
Then why is it that IO-heavy benchmarks such as the Techempower web benchmark are dominated by async frameworks? The fastest results there are all from async frameworks [1].
And among Rust frameworks the same pattern holds. The fastest Rust frameworks are async while a synchronous frmework such as Rocket is about 20x slower.
Those benchmarks measure one very specific scenario: serving lots of small requests concurrently. Async handles that well because that's exactly the scenario where a single epoll_wait() call will return lots of events.
Presumably the difference would be smaller or for some frameworks even negative if each request did some actual and not entirely predictable amount of CPU work (e.g. executing some html templating scenario with varying levels of output and perhaps compression), and just in general much more work and using more memory (so the memory overhead is proportionally less relevant), and if the benchmark implementations were not permitted to tune exactly for the workload and system (i.e. so that generalized scheduler defaults are used on both kernel and userspace side). I.e., in a more real-world scenario with all the normal complexities and inefficiencies and development time constraints that are usual.
But yeah, it's be super interesting to actually see that demonstrated - that'd be quite a lot of work, however.
I doubt you'll find anything as comprehensive and well-presented as the TechEmpower benchmarks, because their particular scenario is one that a lot of frameworks care about competing on (partly because it's difficult enough to be interesting). But I'd expect any benchmark for batch-style processing of large volumes of data would show that.
If your request are huge. For example, imagine you need to read many huge files into memory.
Whether you read one file after the other sequentially, or try to read all of them concurrently, won't make a difference, because your Disk/RAM bandwidth is going to be bottlenecked anyways.
Trying to do this concurrently requires more work that won't pay off, so it might actually be slower.
Benchmarks are not everything, and the difference between asynch/synchronous operation is not the only thing the benchmark is testing (each of these different frameworks appear to have their own system for parsing and representing HTTP requests). You should know what usage patterns YOUR application sees, understand the relative cost of engineering time and CPU time for YOUR application, and do tests in YOUR environment.
I'd argue that it's because even though blocking IO is cheaper, it's very difficult to maximise performance in a multithreaded/concurrent context.
You could make faster code with it but I wouldn't want to maintain it and you'd have to throw an obscene amount of man hours at it to get that performance.
> A context switch takes around 0.2µs between async tasks, versus 1.7µs between kernel threads. But this advantage goes away if the context switch is due to I/O readiness: both converge to 1.7µs.
This is a big surprise.
If you look at the Techempower web benchmark [1], the performance of actix-web is about 20x higher than that of Rocket.
The common explanation is that actix-web is async and hence much faster than Rocket which relies on kernel context switching.
But if Rust async and kernel thread has the same switch time as shown by this benchmark, then why is actix-web so much faster than Rocket?
How does Rust async compare to Goroutine, Erlang threads, Javascript async, Java async in performance and memory usage? Is there any benchmarks for that?
There were benchmarks and a discussion on this on reddit recently comparing goroutines to tokio.
If I recall correctly tokio was slower than goroutines but if you set the right settings it could be almost as fast.
https://www.reddit.com/r/rust/comments/lg0a7b/benchmarking_t...
I'd think mostly similar. Goroutines are "stackful" coroutines, though, so their memory use will be higher. They have an interesting stack copying model, so I'm not sure if they require as many pages as POSIX threads do. (Having a "denser" memory space and no guard page requirement would mean you could use huge pages and thus have much less TLB pressure.)
I remember reading about this a few years ago here. If I remember correctly back then the main selling point was that it used succinct data structure and it was only the compression algo that was not open source - everything else was.
But now when I look at the new repo and the online doc there is no mention of succinct data struct anywhere.
Also, the benchmarks back then claimed 10x or more faster than RocksDB. Now the performance claim is much more modest.
Does that mean TerarkDB no longer uses succinct data struct? Or are you just open sourcing a lower-end version of the software without the secret sauce?
Can you talk about what makes TerarkDB faster than RocksDB?
Thanks for your attention, glad someone here still remember our history, TerarkDB is now FULLY open source with `succinct data structures`.
Here's the reasons:
1. Our `all-in-one` docs are still under writing, we will cover that part later.
2. For the performance part, we are now showing real-world cases, not a well-designed benchmark.(We selected the best result to show our work few years ago, don't want to do it anymore)
3. About why TerarkDB is faster than RocksDB will be explained in our `all-in-one docs` in one week, and most of the reasons are not magic, just engineering efforts
So it takes $22 million investment to add just 1 job?
Something seems off.