I posted this in a comment already, but the results here line up with the original BOLT paper.
“For the GCC and Clang compilers, our evaluation shows that BOLT speeds up their binaries by up to 20.4% on top of FDO and LTO, and up to 52.1% if the binaries are built without FDO and LTO.”
"Up to" is one of those "technically correct", it's probably more genuine and ethical to give a range in the same circumstances. If 95% of binaries get at least 18%. but the remaining 5% get much less than that, and that's important, then say that, maybe.
When i see stuff like this, i usually infer that 95% gets a median of 0% speedup, and a couple of cases get 20.4% or whatever. But giving a chart of speedups for each sort of thing that it speeds up (or doesn't) doesn't make for good copy, i think.
There’s a section of the article at the end about how Postgres doesn’t have LTO enabled by default. I’m assuming they’re not doing PGO/FDO either?
From the Bolt paper: “For the GCC and Clang compilers, our evaluation shows that BOLT speeds up their binaries by up to 20.4% on top of FDO and LTO, and up to 52.1% if the binaries are built without FDO and LTO.”
I've always wondered how people actually get the profiles for Profile-Guided-Optimization. Unit tests probably won't actuate high-performance paths. You'd need a set of performance-stress tests. Is there a write-up on how everyone does it in the wild ?
You might be surprised how much speedup you can get from (say) just running a test suite as PGO samples. If I had to guess this is probably because compilers spend a lot of time optimising cold paths which they otherwise would have no information about
That's not how it works. BOLT is mainly about figuring out the most likely instructions that will run after branches and putting them close together in the binary. Unlikely instructions like error and exception paths can be put at the end of the binary. Putting the most used instructions close together leverages prefetching and cache so that unused instructions aren't what is being prefetched and cached.
In short it is better memory access patterns for instructions.
Yeah, getting the profile is obviously a very important step. Because if it wasn't, why collect the profile at all? We could just do "regular" LTO.
I'm not sure there's one correct way to collect the profile, though. ISTM we could either (a) collect one very "general" profile, to optimize for arbitrary workload, or (b) profile a single isolated workload, and optimize for it. In the blog I tried to do (b) first, and then merged the various profiles to do (a). But it's far from perfect, I think.
But even with the very "rough" profile from "make installcheck" (which is the basic set of regression tests), is still helps a lot. Which is nice. I agree it's probably because even that basic profile is sufficient for identifying the hot/cold paths.
I think you have to be a bit careful here, since if the profiles are too different from what you'll actually see in production, you can end up regressing performance instead of improving it. E.g., imagine you use one kind of compression in test and another in production, and the FDO decides that your production compression code doesn't need optimization at all.
If you set up continuous profiling though (which you can use to get flamegraphs for production) you can use that same dataset for FDO.
Yeah, I was worried using the "wrong" profile might result in regressions. But I haven't really seen that in my tests, even when using profiles from quite different workloads (like OLTP vs. analytics, different TPC-H queries, etc.). So I guess most optimizations are fairly generic, etc.
I was working some years ago on 'happy path fuzzing', trying to find heuristics to guide through code avoiding all error handling, runtime checks. Never got better results than afl-go or other targeted fuzzing, but you have to know what's your happy path.
Also tried to use previous-version or previous-previous-version coverage ('precise' through gcov, or intel processor trace, or sampled perf traces, down until poor-man's-profiler samples) coupled with program repair tools, and... never managed to jump from fun small toy examples to actual 100+kloc applications. Maybe one day.
What exactly do you think PGO data looks like? The main utility is knowing that (say) your error handling code is cold and your loops are hot, which compilers currently (and so on).
This is indeed unknowable in general but clearly pretty guessable in practice.
If I remember correctly, at Google we would run a sampling profiler on some processes in prod to create these profiles, with some mechanism for additional manual overrides
Well, a LOT of crypto investor are limited means and the least likely to be able to afford to lose it. Sure they shouldn’t have risked their life savings, but they aren’t getting ahead in normal ways so they hooked onto this rocket, and FTX was considered safe and above board for a long time.
There are real mental and physical impact to loss of majority of your wealth, which can lead to homelessness, exhaustion from working more to cover shortfalls, marital strife, abuse, suicide.
Considering this wasn’t just insiders like high net worth investors angel investing, but everyday people, yeah it hurts a lot of people in real ways. Probably a lot more than the Madoff crowd for example.
My view is that folks lost their life savings on crypto on FTX is only a more extreme version of those who lost their live savings on crypto on some other exchange. The fraud is terrible, but only exasperates the problems of those gambling with limited resources to absorb loses.
It's more that, if you take a meaningful amount of money from N people, the likelihood of financial hardship putting someone in mortal danger (eg, by causing them to lose access to housing or medication, or causing them to be suicidally despondent because they've lost their ability to retire) approaches 1 as N increases. When N is high enough that there are multiple people in mortal danger - it becomes pretty likely that some of them succumb.
This is even discussed in the film version of The Big Short.
I do not. My comment was in response to the parent comment saying that financial crime “absolutely causes people to die” and “create far more misery than your average mugger”.
A large number of people, less than the “hundred million” that you mention (Wikipedia says FTX had “over one million” customers [0]) lost their highly speculative investment. Yes it’s a crime, and yes it’s serious. All I’m asking for is some nuance.
What’s the nuance, that if someone makes a “speculative investment” they deserve to have the money stolen more than if they walk down a “risky alley” or something?
I’ve used their tarballed installer, which is straightforward. The app itself then checks for updates, and displays a reminder when there’s a new version.
Not as nice as having an updated version in apt, but it’s a trivial amount of work for something I personally get so much value out of.
> In America, it's wall-to-wall "police say"-like IDF clips and Bill Maher condemnation, dehumanization, and equivocating Palestine supporters with Hamas terrorists. The talking heads cheerfully greet Netanyahu.
As someone who also consumes US news, this does not describe what I’ve seen.
Written, a combination of New York Times, Washington Post, and what Google News aggregates (frequently includes Fox and a mix of websites of local news websites)
I find it hard to believe there’s correlation between the beginnings of Russia-Ukraine and Israel-Hamas and who the US president is.
If anything, Russia and Hamas are each less likely to spark each conflict (in the specific sense of invading Ukraine and 7 October, not the preconditions) knowing that the US is more likely to provide arms to Ukraine and Israel.
Considering Hamas' plan all along was to martyrize the Gaza population by feeding it to the lions, subsequently sabotaging Israel's relations with its neighbors and the global community, it does make sense they decided to provoke a war during Biden's term, a very outspoken zionist.
But Israel is far more likely to want conflict to occur. Evidence of such desire would take the form of ignoring intel from international community stating that an attack was planned, and allowing human-sized slow moving targets to pass through the air defense systems unassailed.
I can’t say I’m a fan of the pricing model, but the linked tweet makes specific choices regarding the number of installs, which in turn determines the pricing.
The tweet has 10M installs, where each one makes a $1. 5M installs where each one produces $2 in revenue results in a smaller cut by Apple. 20M installs at $0.50 results in a larger cut.
I use a Pixel 4a as a second phone and consider Google’s approach to be rubbish…
3 years worth of updates is pretty shit… my son’s iPhone 5c got updates for over 5 years (and I think there were some security issues they patched after that even)
At the moment I’ve got a perfectly usable Pixel 4a that I’m going to have to replace as it’s not secure enough for work related stuff anymore
Is there a concrete explanation of what Masimo’s actual innovation was in their patents?
They were posted in a previous thread, and the way they were written made it unclear what was actually covered. Is Apple allegedly infringing on the idea of putting a blood oxygen sensor in a watch, a technical innovation in how to do so effectively, or something else entirely?
US-10192502-B2 Seems to cover using a lookup table to control the amount of light a liquid crystal on silicon device emits per pixel.
US-10945648-B2 seems to cover the heart of the issue. It specifically calls out
> four photodiodes configured to receive light emitted by the LEDs, the four photodiodes being arranged to capture light at different quadrants of tissue of a user;
Which is what I believe Apple was going to change via software disabling one.
Honestly it seems stretching to say the first one is patentable imho and the second one is easily changed for future hardware versions, which is why I presume Apple isn’t in licensing talks.
Would it be far fetched to hope that Apple could introduce a jailbreak mechanism in the Apple Watch for the purpose of providing users the option to enable and use all photodiodes for the pulse oximeter ?
It might be simpler than that. Like many other watch and phone features, it might just depend on the user's region. Hopefully only in software, but there's also precedent for regional hardware differences.
It’s regarding the arrangement of LED’s and sensors in the watch, along with the signal processing needed to get reasonable data out of them.
My impression of the whole debacle is that Masimo hired up a bunch of smart people, they invented this tech while being paid next-to-nothing by Masimo (as Masimo didn’t have the product development chops to actually bring anything to market), Apple saw that the tech was good and just neeeed a product/marketing team, Apple tried to acquire Masimo, their CEO tried to play hard to get, so Apple ”stole” (offered compensation commensurate to their technical prowess) all the engineers who actually made the thing and just built it in house from “scratch”.
It’s a tricky case to be sure. But I’m all for the outcome where consumers get cool tech and the people who actually made it (notably not the Masimo CEO) get fair compensation for their work.
The aspect a lot of people here gloss over is that the patent that Masimo owns wasn’t actually developed by anyone currently at Masimo. Apple “owns” all the people, but Masimo “owns” their accomplishments. It’s weird.
> My impression of the whole debacle is that Masimo hired up a bunch of smart people, they invented this tech while being paid next-to-nothing by Masimo (as Masimo didn’t have the product development chops to actually bring anything to market)
Your impression that Masimo "doesn't have product development chops to bring anything to market" is ... odd, considering Masimo is a nearly 40 year old company which has devices in most of the hospitals I see as a paramedic bringing patients in, and $2B a year in revenue.
> Apple tried to acquire Masimo, their CEO tried to play hard to get
Masimo stated in court - and Apple never challenged it - that their discussions were around partnership and licensing and tech. I have no idea where your claim that Masimo is just hurt/offended that they weren't "acquired by Apple". I can't even imagine why Masimo would be an acquisition target for Apple - there's an entire world of difference between personal healthcare and the world of ICUs, ORs and ERs that Masimo mostly plays in.
Honestly that’s even worse. So there’s a successful company that has no problem selling its products for tens of thousands of dollars as part of a perpetuation of the insurance-industrial complex whereby folks without access to “good insurance” can’t receive simple, potentially life saving analysis, but they refuse to pay their engineers fair compensation. So then the engineers try to go to a place where they will recice fair compensation and far more people will have access to the life saving equipment they developed, but the CEO of their old company throws a hissy fit over the technology being accessible to folks besides the ultra wealthy and sues them. Disgusting.
This makes little to no sense unless you take an absolutely literal view of the the "any price the market offers is in essence a fair market price" for the value of the engineers. You can't argue that without acknowledging that for the same reasons, until Apple offered those engineers more salary (and I don't think it was disclosed how different they were, just that someone made a comment of saying "$x is low"), then they were being paid the then-fair market value (I also think there's a very cogent argument to be had that SF engineering compensation is inflated). But leaving that aside:
Masimo makes as you note, industrial devices. The Root devices that I mention are not ever going to be used at home, even by the ultra wealthy.
I mean you are talking about devices that do CO-oximetry (effectively "arterial blood gas"), brain function monitoring, connect to ventilators (ISA capnography for intubated patients) and anesthesia machines and pushing aggregated data into EPIC. Like I said, these are devices being used in intensive care units, not simple finger pulse oximetry, reflected or otherwise.
They are not "gatekeeping" this technology for the ultra wealthy so poor Apple Watch owners (of which I am on my third) can't get access to it. They're entirely different models with different purposes, in an entirely differing market segment.
Also if you're referring to "potentially life saving analysis" with respect to pulse oximetry on the Apple Watch, which does it only on demand, and is not an FDA regulated medical device, regardless of patents, there's an exaggeration happening. Patients with chronic hypoxic and similar issues are not relying on Apple Watches to "potentially save their lives".
Do you have an idea of what “market value” is besides the value the market has assigned to a thing? I have no idea why you act like that is a bizarre take.
And why do you think engineers are making too much money while CEO’s are waking away with record profits off their backs?
All in all your argument is just anti-commoner pro-elite system gamers, and if that’s how you see things so be it. But I think people should be able to have their pulses measured even if the FDA doesn’t approve and they don’t have chronic hypoxia and they don’t want to integrate with Epic and they only need it on demand. I’ve had family members that were told they must go through complicated insurance processes to get fancy tens of thousands of dollar pulse measures, but then got by just fine with the watch. Masimo wants to put an end to that to secure their own profits, and this entire site loves them for it.
To add some anecdata to your story, I looked up a job on Masimo's site when this story first came out. $190k for a senior algo/signal processing programmer - PhD preferred - in CA. Masimo had no hope when big-tech turned their focus towards these types of programmers.
Right, and the only way laws change is by moneyed individuals testing them. We should be cheering this opportunity for an actually decent precedent to be set by Apple’s patent law army.
Though in all likelihood it will be settled out of court.
The engineers didn't invent the tech in their garage on their own, though. And I don't know if your narrative reflects the reality, but if it is, "creating" the same product for a different company even when you know that the product is patent-protected is ethically questionable. My position would be different if they launched a start-up based on the tech.
> My position would be different if they launched a start-up based on the tech.
Right, that’s my whole point really. People just look at this as “bad guy Apple” when really it’s a bunch of individual engineers getting absolutely shafted while the HN community cheers.
>But I’m all for the outcome where consumers get cool tech and the people who actually made it (notably not the Masimo CEO) get fair compensation for their work.
So Apple and their shareholders should make nothing on this either in a completely fair outcome?
They tried, Masimo gave them sky-high licensing fees as a means of extortion. It’s an absolute nightmare scenario for Masimo that this (fairly simple) technology would be available to anyone besides insurance companies who pay them tens of thousands of dollars a pop.
Imo it’s appropriate for the government to step in and allow the general public to receive access to this life saving equipment without folks needing a “good insurance” plan whereby some bean counter with no medical training has looked over all your medical records and decided you are worth dropping bundles of money on to have a constant pulse taken.
“For the GCC and Clang compilers, our evaluation shows that BOLT speeds up their binaries by up to 20.4% on top of FDO and LTO, and up to 52.1% if the binaries are built without FDO and LTO.”
“Up to” though is always hard to evaluate.