NohatCoder

That is a comedy for sure. The particular ruling seems to run straight against the Californian libel tourism law of 2010, at the very least in spirit.

They can't do a load before actually reaching the load instruction, and they can't fill the instruction buffer all that fast, maybe 5 instructions per clock, depending on loads of factors. They don't know what instructions are on the critical path, so it is perfectly possible to pick wrong ones in this regard. Having a big instruction buffer does not necessarily mean that the CPU can always pick a perfect selection of instruction from it, that is already a very hard issue that only becomes harder when you give it over a hundred to pick from.

In short, the out of order instruction buffer can do some amazing stuff for code that would otherwise run much slower, that doesn't mean you can't gain or lose performance by reordering instructions. For non-trivial code the best composition is almost certainly different between CPUs.

Never say never, but the DOM and JavaScript environment relies pretty heavily on garbage collection. WASM is inherently not garbage collected, and that makes it really hard to share data between the environments, so I'd say that it is unlikely.

Yes, if you go freemium, you better have the mium part figured out. But this insult clearly also extend to anyone who simply sell their games.

Reimer and Aboudi are both "non-employers", they make up the bulk of citations. Sanfield say basically nothing. And then there is anonymous person to represent independent contractors, because apparently it was really hard to get someone from that class to say what the author of the article wanted to write.

It is funny how the main source of this story is the guy who runs a business that profits off "independent contractors". It is almost as if the people who are mad about this are not actually a significant portion of the independent contractors.

Arbitrarily prefer on bird over another, and believe that you can do something about it with passive-aggressive architecture. That is neither dog stupidity, zebra stupidity nor jellyfish stupidity. That is human stupidity in action.

> We don't accept that in other situations, so why do we when it comes to the web?

Because it is the only thing we have sufficiently sandboxed so that we can actually run it untrusted.

I totally get what you want, but we already have a bunch of X-to-JavaScript compilers that pretty much all deliver the experience of: "It works, but it is a bit gnarly, so why would you use this when you can just write JavaScript". And I don't think WebAssembly is going to change that experience much, mainly because it is a pretty poor VM, seemingly designed around the misconception that a lack of features makes it a good compilation target.

I honestly think we could give compiled languages a much better time on the web with a new intermediate language, but someone has to design it for that purpose rather than cargo cult Assembly similarity.

Because of learning and/or evolution. The paper doesn't offer any reason why they shouldn't adapt, as adaptation goes this one should be pretty easy as it is basically just a mindset, probably perfectly doable within the boundaries of learning. So if they become widespread, they will stop being effective, most likely within a few years. Just like the cartoon scarecrow with a bunch of crows resting on it, it wasn't dangerous, so the crows stopped caring.

So you want to avoid the horrors of the web by inserting some language-warping piece of glue code that is guaranteed to only ever get in your way. The irony.

In any case, the DOM and CSS is like 90% of the reason to hate the basic web stack. The other 90% of the reason that people hate JavaScript for is the myriad of frameworks that some people opt to use. You don't have to, and if you come from C you will probably feel right at home not doing so.

As far as this actually does anything, the birds will surely learn to ignore it / navigate around it. That is why house sparrows are so widespread in the first place, they have adapted to all the stupid things we humans do.

They are also usually really bad at lying. When questioned by actual experts they certainly make for more reliable witnesses than their parents.

All the offered "quantum computers" are suspiciously easily simulated on a normal PC.

All current programmable quantum processors are made from unicorn hairs and fairy dust.

The current state of the art is trying to prove that the thing did something quantum. Programmability is at best swapping some wires around to change that something.

The article mention that NSA have objected to quantum key distribution, then go on to state: However, if you’re a commercial company these systems may be worth exploring. The problem that NSA and many others have pointed out is that it doesn't solve any actual problems. It creates a bunch of hassles but can't replace asymmetric cryptography.

That is even more expensive, with less payload capacity, trading every other quality for a gamble that the enemy does not posses decent radar systems.

Or maybe the lesson to learn is that modern military aircraft are simply not particularly useful weapons. Fighters are way too expensive relative to the cost of ground-based AA systems, while a combination of missile and shell-based artillery can do most bombing jobs way cheaper.

In general modern military seems to be focused on delivering as much power as possible in a single unit, never bothering to ask if multiple lesser units could do a better job combined. And so we get destroyers and cruisers that look mighty, but can nevertheless be rendered inoperable, if not outright sunk, by a single torpedo.

Which is why a lot of Russians don't use .ru domains. But Namecheap throws them out anyway.

It is a tradeoff. Making an airtight sandbox is not that hard. Making it run programs near hardware speed is a lot harder. Making it run legacy machine code is a nightmare.

JavaScript is not machine code, but still a good deal harder to make fast than a language designed for fast sandboxing. Of course there have been bugs, but mostly I think the JS VMs have done a pretty good job of protecting browsers.

That is why you need a well designed permission system. Android and iOs had a chance of doing this in a time when the requirements could reasonably be understood, but I don't think either came close.

It is a better choice than C++ for sure.

Nothing wrong with Rust, but I still think making operating systems with airtight sandboxing and proper permission enforcement is the only thing that can truly solve these issues.

Okay that was a bad guess. I see in the previous chapter that the processor is only clocked at 2 GHz, the results still feel a bit low, but certainly way more reasonable in that light. I still wonder exactly where the extra clock cycles go.

The observed throughput for the scalar code is a lot less than memory speed. A Zen 2/3 has a theoretical memory bandwidth of 51.2 GB/s, so should still be fast enough for the theoretical case I make. The observed memory slowdown is for the vector code, it does multiple iterations, that is why.

The switching between read and write part doesn't make much sense, there is no such switch in cache, and the memory controller takes care of chunking memory access reasonably. Reading and writing is double the operations of just reading of course, but we have covered that already.

What I'm suggesting that the code might do is: At every cycle, read data on location i and location i-1, add them together, store the result on location i. This is problematic because not only do we get an extra read, it also happens on a cache location that was just written to. There is a guard for preventing this unnecessary read, but it might have failed due to not being accessed as the same pointer with the same offset. We still keep it in cache, so a cost of 2 extra cycles per iteration seems reasonable.

There is usually a bunch of weird specifics when it comes to calculating performance, but this one happens to be quite simple as we bottleneck on 1 write per clock, and the add instruction latency of 1, so none of the hairy stuff should come into play.

Not knowing what cpu compiler and settings are used I can't do much to replicate the test.

We are not even close to the performance of ram. The cache can do a read and a write per clock, so should be good for 1 iteration per clock. I think what may have happened is that the compiler did exactly what it was instructed to do, read the value that it just wrote to memory. Figuring that it is safe to just keep the intermediate value in a register is one of those simple things that can be surprisingly difficult to a compiler.

All modern high-performance processors do multiple instructions per clock.

It takes 1 read port for 1 clock. Any AVX2-capable processor has at least 1 read and 1 separate write port, therefore we should get 1 processing cycle per clock, the reported number is only around a third of that.

I don't get why the baseline is so slow, a read, a write and an add per clock should all be within the capabilities of a modern processor.

Included in the box when you buy an AES are several different cipher modes, many of them are most useful for injecting slugs of metal into you own feet.

The one you should use, AES-GCM, wasn't even in the original box, but was MacGyvered later.