HN user

volta83

1,480 karma
Posts2
Comments428
View on HN

This might be an error on both sides.

They want to study how websites handle GDPR and CCPA, and that's probably what they submitted.

The IRB reasoned that "websites are not people", which is true, but failed to reason that "websites are operated by people", and therefore certain measures should be taken.

The IRB bears some responsibility for this.

A simple way to do this is to:

MyNestedMaxHeap(T, Ord) = MaxHeap(MaxHeap(T, Ord), Ord)

such that when using MyNestedMaxHeap only one Ord type can be passed.

You need some way to enforce that the orderings are the _same_

Just require that the Ord type is the same for all heaps ?

MaxHeap(MaxHeap(T, MyOrd), MyOrd) uses the same ordering, but MaxHeap(MaxHeap(T, Ord0), Ord1) does not.

If you didn't have canonical implementations, you would have to give up being able to write safe & efficient data-structures like this.

No? Just make the type generic on the ordering.

Instead of MaxHeap(T), make it MaxHeap(T, Ord:(T,T)->bool) or something like that.

I agree with you, which is why I don't really understand what the point of improving FP64 perf by 4x is, if that is not the bottleneck for many apps.

Per node, a 4x MI250X node has more or less the same BW as a DGX-A100 (8x A100). It has 2x more FP64 compute, but for most science and engineering apps, which are memory bound, 2x more FP64 compute does not make these apps any faster.

I wonder how they manage to keep the FP64 units busy. Seems this is an HPC product, but many HPC apps are memory bound. So to improve FP64 perf by 4 one might need to improve DRAM bandwidth by 8-16x. Otherwise the units would only be stalled waiting for memory.

But it seems they did not improve bandwidth by much?

Ideally it would be a constitutional ammendent, stating that privacy is a right of every citizen, and a human right.

Legislation to the right to encryption would then just follow from it, but having it in the constitution would make it harder for future governments to pass certain kinds of legislation, or if they pass them, the supreme court would declare them inconstitutional.

Its not completely unrelated.

Excess mortality is the only fact that we know for sure given that every country counts "COVID deaths" differently.

Given that there is a statistical difference, the only thing we can probably know for sure is that an individual chances were slightly better in the EU.

The difference is small, like others have mentioned, so it doesn't seem like EU policies did a lot for the whole EU.

This makes sense, since for example Germany had pretty harsh policies, but due some of its neighboring countries having pretty lax policies (e.g. Austria), some parts of Germany were extremely affected (e.g. Bavaria).

This hints that it doesn't really matter if single states have harsher policies as long as neighboring states do not, at least for states of the size of Germany.

If we look at China, which had a very cohesive policy in all its provinces, the story differs.

This hints that if cohesive policies would have been taken at EU and USA scale, the outcome might have been different.

That didn't happen, so we will never know for sure.

This doesn't answer the OP question, but if someone claims to have an answer, they are probably lying, because we don't really have facts to back that answer up.

Right, but all architectures can handle many combinations of instructions in 1 cycle, so this is not really a great proxy for that.

Same for code size. If the instructions are half the size, having 1.5x more instructions still means smaller binaries.

8x 2 byte instructions (16 bytes) lead to smaller code than 4x 8 byte instructions (32 bytes).

Counting number of instructions isn't really a good metric for that either.

I just showed the data, and summarized that according to the data, people in the EU had better chances.

I never claimed that this data is the result of COVID policies.

This is something you made up, and then proceeded to debunk, which is essentially the definition of a strawman.

Please stop building strawmans and putting words in people's mouth. It's unpolite.

RISC-V is faster..

I find it funny that you make the same pitfall than the author did.

Faster on which CPU?

The author doesn't measure on any CPU, so here there are dozens of people hypothesizing whether fusion happens or not, and what the impact is.

The CPU executes the two (or more) dependent instructions "as if" they were one, e.g., in 1 cycle.

The CPU has a frontend, which has a decoder, which is the part that "reads" the program instructions. When it "sees" certain pattern, like "instruction x to register r followed by instruction y consuming r", it can treat this "as if" it was a single instruction if the CPU has hardware for executing that single instruction (even if the ISA doesn't have a name for that instruction).

This allows the people that build the CPU to choose whether this is something they want to add hardware for. If they don't, this runs in e.g. 2 cycles, but if they do then it runs in 1. A server CPU might want to pay the cost of running it in 1 cycle, but a micro controller CPU might not.

Good question.

Excess mortality in the USA and the EU in 2020 were ~470k and ~580k deaths.

The population of the USA and the EU in Jan 2020 was ~329 and ~447 million.

The excess mortality in the USA and the EU in 2020 was ~143 vs ~129 excess deaths per 100.000 inhabitants. The USA had ~10% more excess deaths per capita than the EU.

People living in the EU during 2020 had statistically a significantly better chance of not dying of COVID than people living in the USA, even though COVID hit the EU first, which gave the USA longer time to prepare.

This doesn't really answer your question, because the answer is very personal. Some people were really scared and preferred to trade some freedom for more safety. And well we have many examples of vocal famous people that traded off safety for freedom, and died of COVID. These people would have probably been better off had they lived in the EU, even if they would have been breaking the law and paying fines.

You start with BLAS being a factor 2 off, and then go to PETSc, and are another couples of factors off, and then the actual app the scientist wrote, which many use all of the above and the kitchen sink, where every piece and the pieces they use are all a couple of factors off, and then your scientist app is at 0.01% of peak.

If you have used Sierra since the beginning, we have seen significant performance increases over the years, because the people using it have actually been discovering and then either getting IBM to fix, or fixing themselves, most of the software.

Compared with Power 10, I'd say that Power 9 is "mainstream" (many clusters available), and from the Power 9 CPUs in existence, IBM's are the most mainstream of them all.

Take the Power 10 ISA, build your own CPU that significantly differs from IBM's, and good luck with optimizing all the software above. It can be done, and dumping it on a couple of HPC sites where then scientists and staff won't have any change but to use it for 4-6 years is a good way to get that done.

But for a private company that just wants to deliver value, ARM is just a much better deal, cause it saves them from having to do any of this.

I think that right now, there is sufficient motivation to implement enough of this to be able to try it out, and then see how it actually behaves in practice.

But Rust works on a really wide range of kinds of processors - CPUs, GPUs, FPGAs - and hardware architectures (dozen CPU architectures, dozen GPU architectures, etc.), and nobody has shown that this is a net win for all of them.

Figuring out for which, if any, this is a net win, is something that will have to be demonstrated.

Works is step 0.

Works efficiently is step 10000.

x86 is at step 10000, ARM at step 5000, power is at step 0.

Firefox "worked" before this post on power. Now somebody put enough effort to actually make it usable.

The fact that you don't see people complaining about Firefox PowerPC performance on Linux is not because performance was good - it was unusably slow - but because nobody uses Firefox on Power.

Think about what that means. Think about how many bugs in Firefox are reported _every day_ for x86 and ARM, and how many are reported for PowerPC. Is that also because the PowerPC version has no bugs? (no, it is because nobody uses it, nobody reports them, and nobody fixes them).

- Have you ever, e.g., computed the sinus of a floating point number in C (sinf) ?

- Have you ever multiplied a matrix with a vector, or a matrix with a matrix (GEMM) using BLAS?

- Have you ever done an FFT ?

- Have you used C++ barriers? Or pthreads? Or mutexes?

An optimized implementation achieves ~100% of theoretical peak performance of a CPU on all of those, and these are all tailored to each CPU model.

There is software on any running system doing those things all the time. Running at 0% of the peak just means increased power consumption, latency, time to finish, etc.

Generic versions perform at < 100%, often at ~0% (0.1%, 0.001%, etc.) of theoretical peak.

Somebody has to write software for doing this things for the actual hardware, so that you can then call them from python.

IBM has dozens of "open source" bounties open for PowerPC, and they pay real $$$, but nobody implements them.

---

Porting software to PowerPC is only as simple as doing make if the libraries your software uses (the C standard library, the libm library, BLAS, etc. ) all have optimized implementations, which isn't the case.

So when considering PowerPC, you have to divide the paper numbers by 100 if you want to get the actual numbers normal code recompiled with make gets in practice. And then you have to invest extra $$$ into improving that software, cause nobody will do it for you.

An ISA is like a platform.

It is valuable only if it has many users, e.g., application code, optimized for the ISA.

HW's job is to then run that code with good perf/cost.

OpenPOWER has little software. ARM has a lot of software.

So from that POV, ARM is already many orders of magnitude more valuable than OpenPOWER.

But it doesn't end there. Do you need some software to be extremely optimized for ARM? ARM can do this for you at resonable price, no need to hire.

Also, for OpenPOWER, you need to hire 50-100 Facebook engineers, at 400k$/year, and it'll take them >3 years to produce a chip design, which then needs to be verified, etc. and then needs to be built, so you'll need a fab, specialized on OpenPOWER, or not. A fab churns 40k chips/month, so how many chips / month do these companies need ?

With ARM, you pick one of the many ARM farms, and there is little for you to do. And you get 5 engineers, and they just customize an ARM design to your needs. And they ship in 1 year instead of 3. And next year ARM gives you a way to update your chip to the next generation. And if next year you need some other feature, ARM gives it to you. And if you need software, like C library, profilers, math, all that is supplied by Arm.

And they take royalties on chips you built, and.... and....

So ARM is many orders of magnitude cheaper in perf / $ than OpenPower. Not only is the hardware better, but it is better, cheaper, has more software, and tools, and teams of experts ready to help your team, etc.