7,529 karma · joined October 4, 2013
I'd put this into that bucket of "someone I trust told me they heard the story from someone they trust". It means the story may not be true and they don't have any hard evidence, but they found it believable enough to repeat.
That's not exactly what they said. They said normal orders get artificially delayed and priority deliver orders get sent right away. They were clear that the real issue is that priority only exists because they actively made normal orders worse (I'd guess they actually took a few months of slowly backing off normal order time to get customers accustomed to the extra wait).
v8 had PTC, but removed it because they insisted it MUST have a new tail call keyword. When they were shot down, they threw a childish fit and removed the PTC from their JIT.
If you use your truck as a truck, that’s simply not feasible. If you just use it as expensive transportation, you probably still try to convince yourself by thinking about how you might use it as a truck sometimes and won’t buy an electric truck either.
There’s not much of a market, so leaving makes sense.
Put another way, I'm fine with the TS syntax (and use TS because there aren't other choices), but the TS semantics aren't a good long-term solution.
50 years ago was 1975. It wasn’t the dark ages and the worst cases were already being moved to asylums for at least 150 years before that.
Suicide in particular is hard to hide any suicide rates are going up despite treatment. If mental illness rates are the same as 50 years ago and more people are getting effective treatment, we’d expect per capita rates to decrease.
Impoverished third world countries where people have nothing but problems almost universally have higher reported happiness and less suicide.
Severe mental health issues don’t just go away because you drink and if alcohol could suppress the problems, we’d never have made treatments to begin with.
In terms of “self medicating” with drugs, we’re hitting an all-time high (pun intended). Risky and self destructive behavior is also way up as evidence with our prison systems overflowing.
Nothing indicates to me that mental health is improving and everything seems to indicate it getting worse despite all the attempted interventions.
I'd also note that Chez Scheme was a commercial implementation bought and open-sourced by Cisco. It wasn't something they threw together. Because it is a complete scheme v6 implementation they are building on instead of rolling their own implementation in C. Coding against a stable Scheme API has to be easier and less buggy than what they had before (not to mention Chez being much faster at a lot of stuff).
Furthermore, if the latter were true, it would be an indication that depression was a symptom rather than a cause and the psychiatrist misdiagnosed and improperly treated the patient.
What are the long-term effects of suicide?
A 7-year-old kid doesn't understand what suicide really means. Putting them on something that encourages a behavior that they don't understand and has completely catastrophic results isn't a risk I would take with my children.
You said elsewhere that there were "no known long-term side effects". Aside from that not being universally true for any drug I've ever personally researched, no side effect is more long-term than suicide.
NONE of the current theories being experimented with on patients have a concrete, proven scientific basis with some such as the decades-long SSRI scam have actively harmed patients and created physical dependence/addiction and actively causing harm to patients and their families (eg, SSRI-induced suicides).
I trust science, but I don't trust scientists any more than I trust any other human with their money, career, and reputation on the line. I trust the FDA and pharmaceutical company ethics even less (eg, Bayer knowingly selling HIV-infested drugs to hemophiliacs, saying Oxycotin is non-addictive, or the revolving door that allows non-working SSRIs to be released and marketed as working despite all evidence to the contrary).
This hasn't been true for at least half of a decade.
The latest generation of phone chips run from 4.2GHz all the way up to 4.6GHz with even just a single core using 12-16 watts of power and multi-core hitting over 20w.
Those cores are designed for desktops and happen to work in phones, but the smaller, energy-efficient M-cores and E-cores still dominate in phones because they can't keep up with the P-cores.
ARM's Neoverse cores are mostly just their normal P-cores with more validation and certification. Nuvia (designers of Qualcomm's cores) was founded because the M-series designers wanted to make a server-specific chip and Apple wasn't interested. Apple themselves have made mind-blowingly huge chips for their Max/Ultra designs.
"x86 cores are worse because they are server-grade" just isn't a valid rebuttal. A phone is much more constrained than a watercooled server in a datacenter. ARM chips are faster and consume less power and use less die area.
> So at this point, I think it’s actually the ARM ecosystem that has the larger R&D budget.
Apple doesn't design ARM's chips and we know ARM's peak revenue and their R&D spending. ARM pumps out several times more cores per year along with every other thing you would need to make a chip (and they announced they are actually making their own server chips). ARM does this with an R&D budget that is a small fraction of AMD's budget to do the same thing.
What is AMD's excuse? Either everybody at AMD and Intel suck or all the extra work to make x86 fast (and validating all the weirdness around it) is a ball and chain slowing them down.
It seems to me that Apple is simply going to require native ARM versions of new software if you want it to be signed and verified by them (which seems pretty reasonably after 5+ years).
It's telling that ARM, Apple, and Qualcomm have all shipped designs that are physically smaller, faster, and consume way less power vs AMD and Intel. Even ARM's medium cores have had higher IPC than same-generation x86 big cores since at least A78. SiFive's latest RISC-V cores are looking to match or exceed x86 IPC too. x86 is quickly becoming dead last which should be possible if ISA doesn't matter at all given AMD and Intel's budgets (AMD for example spends more in R&D than ARM's entire gross revenue).
ISA matters.
x86 is quite constrained by its decoders with Intel's 6 and 8-wide cores being massive and sucking an unbelievable amount of power and AMD choosing a hyper-complex 2x4 decoder implementation with a performance bottleneck in serial throughput. Meanwhile, we see 6-wide
32-bit ARM is a lot more simple than x86, but ARM claimed a massive 75% reduction in decoder size switching to 64-bit-only in A715 while increasing throughput. Things like uop cache aren't free. They take die area and power. Even worse, somebody has to spend a bunch of time designing and verifying these workarounds which balloons costs and increases time to market.
Another way the ISA matters is memory models. ARM uses barriers/fences which are only added where needed. x86 uses much tighter memory model that implies a lot of things the developers and compiler didn't actually need/want and that impact performance. The solution (not sure if x86 actually does this) is doing deep analysis of which implicit barriers can be provably ignored and speculating on the rest. Once again though, wiring in all these various proofs into the CPU is complicated and error-prone which slows things down while bloating circuitry, using extra die area/power, and sucking up time/money that could be spent in more meaningful ways.
While the theoretical performance mountain is the same, taking the stairs with ARM or RISC-V is going to be much easier/faster than trying to climb up the cliff faces.
That said, these only get used in the rare cases where your number exceeds around 1 billion which is fairly rare.
JS engines use floats only when they cannot prove/speculate that a number can be an i32. They only use 31 of the 32 bits for the number itself with the last bit used for tagging. i32 takes fewer cycles to do calculations with (even with the need to deal with the tag bit) compared to f64. You fit twice as many i32 in a cache line (affects prefetching). i32 uses half the RAM (and using half the cache increases the hit rate). Finally, it takes way more energy to load two numbers into the ALU/FPU than it does to perform the calculation, so cutting the size in half also reduces power consumption. The max allowable size of a JS array is also 2^32.
JS also has BigInt available for arbitrary precision integers and these are probably what someone should be using if they expect to go over that 2^31-1 limit because hitting a number that big generally means you have something unbounded and might go over that 2^53-1 limit.
Either you lower US standard of living to match the countries it is currently outsourcing to or you establish protectionism and isolationist policies with a focus on total efficiency rather than short-term gains.
This leaves ads as the only form of revenue and because ads don't care about the content, this creates a race to the bottom on generating slop.
We have far from perfect information and very flawed models too.
Interestingly, there seems to be some success with AI models that almost completely skip the science and jump straight to pattern recognition. It's interesting to think of modern 10-day weather forecasting going back to its old almanac roots.
Personally, I don't count pornhub traffic the same way I count Youtube or Netflix traffic and I think the same applies here.
The extra issue here is that SIMD (the main optimization) simply sucks to use. Auto-vectorization has been mostly a pipe dream for decades now as the sufficiently-smart compiler simply hasn't materialized yet (and maybe for the same reason the EPIC/Itanium compiler failed -- deterministically deciding execution order at compile time isn't possible in the abstract and getting heuristics that aren't deceived by even tiny changes to the code is massively hard).
Doing SIMD means delving into x86 assembly and all it's nastiness/weirdness/complexity. It's no wonder that devs won't touch it unless absolutely necessary (which is why the speedups are coming from a small handful of super-optimized math libraries). ARM vector code is also rather Byzantine for a normal dev to learn and use.
We need a more simple assembly option that normal programmers can easily learn and use. Maybe it's way less efficient than the current options, but some slightly slower SIMD is still going to generally beat no SIMD at all.
AsI recall, Microsoft wanted devs using their proprietary silverlight and c# which required a complete rewrite from iOS or Android. Allowing existing apps to bundle their preferred Android runtime is a lot closer to something like containers or flatpak and is a proven way to reduce developer friction. Ironically, such an app running in wasm would be supported indefinitely while Android apps on Android eventually lose support.
A new web-centric OS could fix those issues by doing a few things to reduce friction.
First, use an Android-compatible kernel version so drivers are easy to port. This gets manufacturers on board.
Second, make your App Store a non-profit that charges enough for ongoing store development and distribution. This gets devs on board.
Third, make sure you have decent third party framework support. Flutter, react native, and maybe even an Android runtime that legacy apps can integrate into their wasm binary. This helps kickstart your ecosystem.
Fourth, add better integration of webgpu and 2d canvas (which probably needs some extending). In addition, they need to add a low-level API to access DOM nodes from wasm. For security and ease of implementation (without stepping on the toes of the normal standardization stuff), this would probably be a virtual DOM with only a provably secure subset of the actual nodes being sent back and forth.
UI is an easier problem. The best design to date is still webOS. Copy their general design (maybe rip off some of their never-shipped mochi stuff).
The biggest issue as you said is financing. All these things turn into lots of developers and time. The best bet here would be replacing something like Tizen where a corporation is already investing.
Firefox OS had serious issues.
* Web standards 2013-2017 weren't ready enough.
* 2013-2017 phones still weren't powerful enough for complex JS apps to feel fast.
* asm.js was de-facto proprietary (a new FFOS with wasm would be be another story)
* The UI wasn't so great.
* Their launch devices were slow, cheap, and sucked.
* Their launch devices weren't readily available to developers.
* Their OS provided no real advantages over iOS or Android
The OS is still around as KaiOS (with a couple hundred million devices shipped IIRC) and I believe it still powers Panasonic TVs.
Interestingly, I think a FirefoxOS of today with good React Native and Flutter integration and cutting-edge WASM support could have a shot at success if not completely mis-managed.