akireu

I live in a Russian city of 100k people and there are at least 3 medical MRI machines nearby that I visited, of a total 8 offers that maybe share the machines (though likely not), all of them of 1T field strength or above. I can get a brain MRI this week for some $70, or a full-body MRI (the most expensive as per the price list) for $400. If anything, these services got some 30%-50% cheaper in the past decade. Barring some African hellhole, the argument to scarcity or expense of these machines is complete and utter bullshit. It's just that HN is America-centric, and American healthcare is a cesspit of waste and corruption.

This isn't really relevant to wasm, though. You can't expect it to support platform-specific hacks just for SIMD, so you'll have to make do with the lowest common denominator anyway.

Won't this require years of busywork? The various intrinsics, function attributes, C compiler args compatibility, ABI profiles for various platforms/systems (including the Windows GCC/VC ABI idiocy?)

upd: Also, I'm not sure that implementing -funsigned-char in 2022 will be all that great for morale!

Why not? Fixed-size SIMD architectures use mostly the same operations, so if you target SSE2 initially, the code should run just fine on NEON. A runtime that ships a JIT compiler also has the unique opportunity to further optimize SIMD code by using more lanes or limiting the working set to the host platform's L1 cache size. Even the AOT compilers like GCC or clang emulate platform-specific intrinsics using generic vector ones. This should count for something, no?

Did a similar test in plain C: https://godbolt.org/z/ffYcWhxz3 It's not quite the same: I've used an increment instead of zeroing, otherwise the entire benchmark gets optimized away. Still got just about the same result (3.7x speedup for 100 iterations), so wasm did good there. Actually, now that I think of it, SIMD code performance probably depends on good register allocation more than on any optimization.

It looks promising! But fixed-width lanes don't seem too cross-platform? I don't just mean the v256 and v512 types that may become ubiquitous in a few years, but also things like optimizing for different L1 cache sizes, doing some operation macro-fusion on the SIMD unit, or directly supporting leading/trailing elements to reduce code size?

Ads aren't the problem, the surveillance is. That you can't have the former without the latter is a myth FB and Google peddle to justify their existence. They don't even need your data all that much - the duopoly the myth perpetuates is what matters. There's no conclusive proof that personalized ads are more efficient than old banner networks, much less that FB's or Google's services are worth the huge share of profits they take as intermediaries.

Please clarify what do you mean by incorporating a C compiler. Does this mean you're abandoning the "custom C frontend inside the D compiler" effort in favor of something like clang? To me, the other possibility - having *yet another* C compiler to look out for - is just terrifying.

Of course AWS is the mainframe in this analogy! It's a huge throughput- and reliability-optimized overhyped crazy expensive server that you hire someone else to run for you. It's designed the same way, with dedicated storage, compute and backplane servers. Even the discourse is the same to the 80s: "why we have to rent a $$$ monster when a $ commodity server outperforms it". How is this not obvious is beyond me.

I apologize for my mistake, then. My understanding was based on reading the Prometheus docs on making exporters alone - something I needed urgently for a job.

I wasn't speaking of a 4k TV, but still, this doesn't check out. A single 2160p framebuffer is 8MPix, or 32MiB. Not counting the original FB size, the extra 1.5GiB are enough for 48 whole framebuffers. You don't need that much image data all at once, the number is ridiculous. No, I believe it's just that the code became that much less efficient.

I'm talking about the way I'm expected to provide metrics for my apps. Rather than exporting free-form JSON and then scripting Prometheus to understand it, I'm expected to use a custom client library to export the metrics. As for Kubernetes, you can only use it with Prometheus because of not insignificant amount of work on both sides. Basically, the latter is designed for vendor lock-in.

They're just poster children for the particular brand of disdain $100k+/year "tech workers" bear for their users: they make enough for the shiniest of toys, so they're too far above spending their valuable time to make their software run smooth on our $100 crap phones. Nevermind that each Fb client update likely produces hundreds of tons of toxic trash called gadgets. Sure, sometimes they do optimizations. Generally, though, both Fb and Google keep exploring the physical limits to code bloat. Remember that one time that Fb hit the JVM class count limit?

What you're kind of missing is that the S5 was a flagship phone. Generally, one has to save for more than a month to afford a purchase like that. The idea of working an extra month so that some FAANG prick meets their KPI by cutting corners on optimization doesn't even look like feudalism. It looks like idiocracy. Paying the lip service of fat shaming code bloat is the cost-effective option by comparison :)

It's 2022 and we're about to rediscover something we know for 40 years already: mainframes are freaking expensive.

On a side note, Prometheus seems to be built for bloat. AFAIK, it isn't even designed to consume metrics other than from apps linked to its client library. It's like a microservice, but with the footprint of an operating system.

It's all fun and games until you're stuck for a hour downloading 600MB of updated packages over a metered LTE. The same is with RAM usage: 512MB was enough for a phone back in 2014, now a smart TV with 2GB is barely capable of multitasking. Sure, binary sizes don't matter in most contexts. But when they do, it's a PITA.

Inventing arbitrary formulae to calculate your wage is merely a dishonest negotiation tactic. Govt companies do it all the time, don't read too much into it. Also, it's perfectly fine to renegotiate your wage once you're off your probation period, as once you're in, you have a better idea of your worth to the company. Just don't do it too often.

A decade ago, an article [1] was published in the Russian "Hacker" magazine where the author alleged that a Russian OEM manufacturer's motherboard sourced from China had a BMC chip (which should've been disabled as per the mobo spec) inject a hypervisor into the host machine.

It was, again, allegedly, discovered because the author was developing some kind of distributed computing software that required a hypervisor of its own, and this exact mobo was crashing in a way that was consistent with a hypervisor being already present. The author goes further to describe how he devised a way to consistently detect hypervisors by measuring platform register access timings, and tried to report the findings to the FSB (Russian CIA/FBI) to no avail.

I personally don't put much stock in the story, as the magazine was a rag and I could come up with something like that at the time, but there it is.

[1] https://xakep.ru/2011/12/26/58104/

MIR isn't really a language of its own: it's a human-readable serialization of Rust compiler's lower-level AST, an artifact of the language's complexity. It's native to the compiler, so it doesn't need to be parsed, validated and compiled. So it isn't really relevant in this context.

Rust aside, I'm fine with using C as a target language, as it's well known and has all sorts of tooling, but inventing a whole new language with a custom syntax just to use a codegen is overkill, especially when there are more than a dozen projects that use SSA-based IR to great effect (from LLVM and golang to game console emulators).

Recently I've read a 1985 interview with a Soviet IC factory worker where phosphine, arsenic, antimony and hydrofluoric acid were named. Workers explicitly shut down their managers' plans to use pure phosphine. A death caused by arsine poisoning was mentioned.

Ah, I remember that one. Not a fond memory, either. The C-like language is a red herring: what you actually want is the codegen backend, and having any intermediaries between your AST and the codegen's IR will just add inefficiency and uncertainty. Ironically, there are parts of LLVM-like IR poking out of it: at page 43 of the spec pdf there's a table of instructions that have their counterparts in more or less any modern codegen.