2,917 karma · joined April 21, 2019
First of all, adding this hardware encoder to the Apple Silicon chips definetly has a cost, and you pay it when you buy their products.
Second, there are Intel CPUs available with hardware encoders (google Intel QuickSync). The only difference is that you can choose to not pay for it if you don't need it.
- crappy webcam,
- no built-in SD card reader (a 1TB SD card is ~200$, and my music does not need to be stored on an expensive SSD)
- magsafe.. if this was the only downgrade, I'd upgrade, but TBH I love magsafe on my mac and I would miss it if I upgrade.
Some people here value "open source" drivers over "working drivers". I value "working drivers" over "open source" drivers over "proprietary" drivers.
An open source driver that does not work, is worth zero to me.
If it were true that "open source" means somebody can go and fix the driver, then somebody could have added ROCm support for the 5700 XT a long time ago. The fact that this has not happen, to me at least, means that open source is not as valuable as people seem to try to make it be here.
Sure it is better than closed source, but if your driver doesn't work, and AMD doesn't want to fix it, it definitely does not mean that anybody will fix it within the lifetime of the card. This card will be surpassed by the 6000 series next week, no chance I'm going to buy one of those.
I feel like Hip, OneAPI, ISPC, etc. haven't improved anything over CUDA.
With CUDA we had one proprietary API. Now we have 3-4.
FYI Aaron Turon did their PhD on Concurrency+Scala, and ended up leading the Rust core team for more than enough years.
With such an instruction, you could exponentially increase the precision in 2 cycles by just using the same instruction twice.
You can't do that on Intel's hardware. As you mention, you'd need to roll your own multi-SIMD-instruction rsqrt newton iteration complex loop, and use it after the first SIMD call.
That's really sad. There is hardware to perform Newton iterations on Intel CPUs, that's how that instruction is implemented, but the ISA only exposes this hardware via the "do a 14-bit rsqrt operation", which means that you can't really use it to increase precision if that does not suffice for your app.
That way you can quickly get the precision that you want ;)
In my experience, and this is just a data point: because it is much simpler to write correct Rust code and to refactor large Rust code bases correctly than doing the same for Javascript, Ruby, Python, C++, C, Java, etc.
That Rust has great perf and uses little resources is just a bonus, but not something that most apps will care much about.
The downsides you mention about the ecosystem, libraries, frameworks, are real.
I disagree with your claim that there is no "talent pool" for Rust. The "talent pool" for javascript or C++ is _only_ "all javascript experts" or "all C++ experts" because if you are not very good at Javascript or C++, you can't really be trusted. A Javascript programmer can start being productive in Rust without issues quickly, but the same wouldn't be true if they had to program in C++ instead.
The "talent pool" for Rust is "all programmers with domain knowledge". If they are not experts in Rust, that doesn't matter. Smart people you want to hire all pick up Rust very quickly, and the amount of dangerous mistakes anyone can make by not being a Rust expert is very small.
Offer/demand wise, the demand for Rust jobs is much higher than the Rust jobs that are currently available. If you post a Rust job on reddit you'll get 100 CVs in a day...
---
IMO, your main point still holds: right now Rust web frameworks are not as feature full as Django, Rails, etc. and if Rust frameworks are missing features you need, picking it up for a professional project probably doesn't make sense. Unless... you are willing to implement those features yourself...
Rocket's current released version is 0.4.5, and that version builds with a stable Rust toolchain.
Why would I get a Radeon VII when used nvidia cards for machine learning are extremely cheap, and then I don't have to worry about experimental stuff breaking one day before deadline lol
I use ketosis strips (Ketostix). You pee on them, and they tell you. Totally worth the 5$ they cost.
I'm happy in full ketosis, or no ketosis at all, but the "half-way" ketosis state is just pure torture.
The strips let me know how good I'm doing, so if things deviate a bit, e.g. because one day I ate ""too many carbs"", I notice quickly, and auto-correct.
> One of the key differences between zig and rust is that when writing a generic function, rust will prove that the function is type-safe for every possible value of the generic parameters. Zig will prove that the function is type-safe only for each parameter that you actually call the function with. On the one hand, this allows zig to make use of arbitrary compile-time logic [...]
This is fundamentally identical to how C++ templates, constexpr and concepts work. Its a really flexible system (you can implement how you want to type check things using constexpr), but has three cons that Rust system does not have:
- can't typecheck library APIs, so library authors aren't sure if their "constraints" are correct. Testing this requires writing lots and lots of compile-time tests.
- errors deep inside a library implementation when user code passes incorrect arguments to generic APIs.
- rust traits can be used for static dispatch, or boxed and used for dynamic dispatch, C++ at least can't really do this well.
It would be cool if someone could explain how Zig fixes or improves upon these problems that this system has in C++. C++ tried to fix this with concepts, but failed.
This was a nice read that has motivated me to learn Zig. I want to know how Zig improves on these C++ issues.
Independently of how perfect your architecture is, the moment you add a Mutex to your app, you are opening the door for that to happen.
IMO not worth it.
lol, really? No, like, not at all.
Parking lot has 1 killer feature, and 1 killer feature only, and this feature makes using the standard synchronization primitives _almost always_ the wrong choice for almost all applications:
DEADLOCK DETECTION
parking_lot::Mutex panics if your program deadlocks, printing out the backtrace of each thread involved in the deadlock. This makes discovering, understanding, and fixing dead-locks a 5 minute issue, that's easily and quickly discovered during development in the minutes after introducing a deadlock bug.
I mean, you are completely right that, on top of that, parking_lot synchronization primitives are much much faster than those in the standard library. But that's only the cherry on top.
---
FWIW, nice post, I agree with all your judgements there. If you are looking for an async runtime that's smaller than tokio, check out the `smol` crate. For a thread-pool, i either just use rayon's (you can just push tasks onto its thread pool), or the futures's simple thread pool from the futures crate.
I agree, but as an emacs user that has tried it multiple times, I really don't "get it".
The main thing that excited me about Xi wasn't Xi itself, but rather that its technology stack could be user to "build your own editor" using a solid foundation. That includes a more modern emacs, vi, vs code, or whatever you like.
It is also worth pointing out that these "analyzers" are just tools that simulate particular CPU architectures. Their models are just approximations and aren't perfect, so don't take them as a source of truth.
You were one click away of using LLVM's Machine Code Analyzer (MCA) within godbolt to see why one of the two isvowel one-liners is objectively better than the other: https://godbolt.org/z/fGEv3c
This version:
bool isvowel(char c){ return (0x104111>>c-'a')&1; }
puts way more pressure on Port 2 on skylake, reducing the number of IPC that can be scheduled. The first version is therefore a bit better.
;)
The bug report claims
> The domain for (llvm.maximum undef, %x) depends on %x,
But this claim is not true. Here is why, when the LLVM docs state:
> [llvm.maximum returns] the maximum of the two argument, propagating NAN [...]
they are referring to IEEE's 754 maximum semantics, which state that if one floating-point argument to the function is a NAN, the function returns a NAN.
However, IEEE assumes that floating point values are composed of bits, which can be 0 or 1.
That assumption does not hold in LLVM, where a bit can take any of three values: 0, 1, or undef (well there is also poison, but lets leave that aside).
According to IEEE, llvm.maximum(%x, NAN) must return NAN _if_ x is not undef. But if x is undef, then IEEE does not hold.
The LLVM docs do not say what this function should return in that case, so the behavior is IMO currently undefined, and any optimization for this is correct, so we might as well pick the one that enables most optimizations, and that's returning undef (e.g. these cases only legitimally happen in dead code, e.g., expanded from macros, and you want the compiler to better remove this dead code).
There is also the issue of consistency. If we were to replace llvm.maximum(%x, NAN) with llvm.select(%x >= NAN, %x, NAN) then you would think that any number compared with NAN compares to false, and this always returns NAN, but that does not hold for undef, where you get llvm.select(undef, undef, NAN) returning undef or just being plain UB.
So IMO the assumption motivating this fix is wrong. It assumes that undef is a floating-point value, but it isn't. It is something else, and the floating-point rules of NAN comparisons with undef do not apply to it. This fix will only remove optimizations, and delay broken code from standing out, because if your program tries to execute `llvm.maximum(undef, %x)`, your program is broken.
[0]: https://llvm.org/docs/LangRef.html#llvm-maximum-intrinsic
What about bigger than big? > 2^29 or so ? Are these sizes for double precision ?
No, it does not. Holding u briefly overlays a keyboard of "compositions" for u, and you can just press whatever key you want afterwards to pick one, see: https://osxdaily.com/2017/03/22/type-accents-mac-easy/
> Why is macosx system is better? Compose keys are mnemonic
Because macosx system is not mnemonic. If I need to type a particular accent, which I do very often, and there are O(50) variations of them, I don't have to remember anything. Instead, the computer shows me all the options as a type, and I just pick the one I want.
---
If I need to type "u" 42 times for whatever reason, holding u and waiting sucks anyways. Every editor I use has a better more precise way of doing this (on my emacs its just meta+42+u), and worst case I can always just do cmd+space and execute "repeat 42 u" or similar.
I've been "holding the letter" for 5 years at least.