The OP is just saying that, because of a not-too-far-in-time religion shift among people of a certain part of that country, there are conflicts. The rest is just your imagination.
Just to add a few details, Cressida Dick is the person who ordered the execution of a brasilian electrician, down in the London Underground. It does not surprise me that aristocrats are in favour of a medical approach to crime: to help enforce the state monopoly on violence itself.
Sorry, I don't buy it.
Man kept overpromising (somebody would say "lying") even after release.
Now he's on a publicity stunt for the latest and greatest product, addon, whatever, and cheaply plays the always popular victim card.
Nobody says that maybe some angry commenters where "overpromising" too, with their enormous and unpractical threats.
The journalist is of course thrilled to expose weirdos -- the correct type of weirdos, so to speak -- to his small court of readers, for outrage and clicks.
A deal is made to reciprocal benefit.
It is not a counterpoint, just a way to show the limits of an overblown analogy. You should appreciate the moral difference between Parks' and Gandhi's deliberate approach and the entitled arrogance of those two gentlemen, whose actions would be of no relevance if not for their skin color. Strange times. But but! If I'm wrong and the guys were acting a protest against overpriced dairy product shady dealers -- then they will have all the support that my limited means offer and unlimited appreciation.
Hi, I've posted a few details and a sample program over here.
As you correctly notice, latency is a big issue on modern machines, way worse (in proportion) than it was in the late eighties.
But as soon as the wheels start turning, they spit out a lot of bytes, for sure!
Hi!
Memory is definitely an issue today, especially with big fat server processors...
Here is the small program I wrote, first allocates an array, then writes a random placed linked list that touches all the array cells (e.g. start->|4|6|2|5|3|end , so it goes to cell 1, then 4, then 5, then 3,2,6 and done.
Then it reads the same array from start to finish, just to sum contents. This is fast and goes to 6-8 GB/s, depending on unrelated memory pressure from video and os tasks. This is the advertised speed. So I don't think it's a swap issue (and my SSD is way faster :-) I've also tried with smaller and bigger arrays. Just ensure it stays in real memory.
Moving around in a big array is very hard on the memory controller:
- no prefetch possible;
- row and column changes at every access (almost), so commands have to be issued to burst terminate, close row, close bank, precharge maybe, open bank, activate row, fetch address, and who knows;
- no advantage from interleave;
- no advantage from a fat 64 or 128 bit bus;
It is the combined time needed for each and every memory read (due to randomization) that cause performance to drop.
This is the code I've been using. I've modified it to work on unices (OSX has an issue with timeval struct), but have not tested on them. It compiles, may need to be altered a bit. Launch it with ./a.out <array_size> <random seed>. You will note that, as soon as the array moves out of caches, hell breaks loose. Works with gcc or clang.
The article is very optimistic about memory availability per cycle, reality is way worse.
As an example, on my Macbook Air 2011 with ~10 GB/s of maximum ram bandwidth, random access to memory can take 100 time more than a sequential one.
This in C, with full optimizations and using a very low overhead read loop.
Using the same metrics of the author:
best case: ~ 3 bytes per cycle
(around 6 Gigabyte per second of available bandwidth)
worst case: ~ 0.024 bytes per cycle
(every scheduler, prefetch, already open column mostly defied)
Note that worst case uses 10 seconds (!) to read and sum in a random way all the cells of an array of 100.000.000 of 4 byte integers, exactly once. Main loop is light enough not to influence the test.
That's about 40 megabytes per second out of 6.000 available.
I feel the exact opposite... Go is a bold design, if not an elegant one, yet powerful.
Rust is a design-by-committee language, built from accretion and removal. Its origins as a managed language, pivoted and is now a second system C++ replacement -- the only one, to be fair.