Hacker Newsnew | past | comments | ask | show | jobs | submit | more sxzygz's commentslogin

I assure you, if you have the patience, reading this post by Timothy Gowers is worth it, assuming your mind is open.

The rapidity of your response to my submission suggests you have not given the post the attention I feel it deserves.

Please try.


I am sorry for clicking away once I read "Why I do not want to talk (much) about genocide." in the table of contents. I have no interest in reading a re-hash of the Israeli media's censored accounting of things, I'm firmly in the international camp of demanding secular accountability.

My question stands; why can one side violate humanitarian law, but the other cannot? Neither you nor the author can justify it.


mallowdram, in a flagged dead post, noted:

> Logic is inapplicable here. Politics is arbitrary, and labels/categories are worse than arbitrary, they are random.

Broadly speaking, at some level, I agree with them.

There is no machine that will flash an indicator when pointed at a “fascist”. Yet certain intelligent people are always willing to use pure reason to confront a world that does not admit such scientific classification. The retort is always, “You know one when you see one.”

The is a definite humility that is lacking in such debate, as if everyone shares a logically necessary psychological reality.

None of these thinking persons, of any stripe, are prepared to do the work of articulating, with nuance, where the logical consequences of another contradict their own, and more tellingly, where interpretations of words/labels/categories are themselves foundational in arguments.

People, myself certainly included, are not free with their energies teasing these details out, and are instead more than ready to indicate, in laborious, technical detail, why they are right.

This is a very sick time in shared discourse. I want people to pause and ask if this intellectual turmoil is indeed useful in the present moment or is irrational behaviour forced by economic, social, and environmental anxieties of our time.


Hello again!

I try to tease some details here (please note that the biological allusions are not meant to be "rational")

https://news.ycombinator.com/item?id=45545841

>There is no machine that will flash an indicator when pointed at a “fascist”.

Perhaps a reference to a certain Soviet farce?

https://en.wikipedia.org/wiki/Kin-dza-dza!#Animated_remake

(2013)

Online, the best we can do is try to be right about the kind of questions to ask.. (& pay heed to emotivism, like you say)


Bravo. Awesome work.


I don’t think you’re remotely correct, but I also don’t know how to dispute your ignorance in any useful way.

To @esafak I suggest following @westurner’s post.

I like the concept of Stable Manifolds. Classifying types of them is interesting. Group symmetries on the phase space are interesting. Explaining this and more is not work I’m prepared to do here. Use Wikipedia, ask ChatGPT, enrol in a course on Chaos and Fractal Dynamics, etc.


I am quite familiar with this space and I will reassert that its by far most significant application is making pretty pictures.

The Wikipedia list you're indirectly referencing is basically a fantasy wishlist of the areas where we expected the chaos theory to revolutionize things, with little to show for it. "Chaos theory cryptography", come on.


Thanks for your input. I didn’t know what to make of the article.


Having taken a second look, this article does in fact have a point, but it is actually nothing at all to do with conditional moves in the RISC-V instruction set Zicond extension -- or amd64 or arm64 style conditional moves either, if they were added at some point.

It is not even about RISC-V but about instruction fusion in general in any ISA with a memory model at least as strong as RVWMO -- which includes x86. I'm not as familiar with the Aarch64 memory model, but I think this probably also applies to it.

The point here is that if an aggressive implementation wants to implement instruction fusion that removes conditional branches (or indirect branches) to make a branch-free µop -- for example, to turn a conditional branch over a move into something similar to the `czero` instruction -- then in order to maintain memory ordering AS SEEN BY A DIFFERENT CORE the fused µop has to also have `fence r,w` properties.

That is all.

It is irrelevant to this whether the actual RISC-V instruction set has a conditional move instruction, or the properties it has if it exists.

It is irrelevant to the situation where a human programmer or a compiler might choose to transform branchy code into branch-free code. They have a more global view of the program and can make sure things make sense. A CPU core implementing fusion has only a local view.

Finally, I'll note that instruction fusion is at present hypothetical in RISC-V processors that you can buy today while it has been used in both x86 and Arm chips for a long time.

Intel's "Core" µarch had fusion of e.g. `cmp;bCC` sequences in 2006, while AMD added it with Bulldozer in 2011. Arm introduced a limited capability -- `CMP r0, #0; BEQ label` is given as an example -- in A53 in 2012 and A57, A72 etc expanded the generality.

Upcoming RISC-V cores from companies such as Ventana and Tenstorrent are believed to implement instruction fusion for some cases.

Just for completeness, I'll again repeat that SiFive's U74 optimises execution of a condition branch and a following simple ALU instruction that execute simultaneously in two pipelines, but this is NOT fusion into a single µop.


> but about instruction fusion in general in any ISA with a memory model at least as strong as RVWMO -- which includes x86

No... It's kind of an artefact of RISC-V's memory model being weak. x86 side-steps the issue because it insists that stores always occur in program order, allowing it to fuse away conditional branches without issue.

(Note: the actual hardware implementation of x86 cpus issues the stores anyway, and then rewinds if it later detects a memory ordering violation)

RISC-V ran into this corner case because it wanted the best of both worlds: A Weak memory model, but still have strong ordering across branches.

Looks like ARM avoided this issue because its memory model is weaker, branches don't force any ordering, which means the arm compiler might need to insert a few extra memory barrier instructions.

---------

TBH, I don't think this fusing instructions edge case is a big deal. For smaller RISC-V cores, you aren't reordering memory operations in the first place.

And for larger RISC-V cores, you already need a complex mechanism for dealing with store order violationss, so you just throw your fused come instruction at it. Your core already needs to deal with sync points that aren't proper branches, because non-taken branches also enforce ordering.


On AWS, if I run my software (some VM image), what guarantee is there that you are indeed running the image I provided to you? And, if is an approved image, what guarantee is there that image being run is the one publicly disclosed?


At some point it does come down to "we have to trust the provider isn't outright lying to us about what they're doing."

That was a hard bridge for me to cross for a long time; I got there via sustained in-depth conversations with folks there who simply wouldn't stand for something that breathtakingly opposed to everything AWS has strived to achieve from a trust perspective, that they'd sooner tear it all down than implement such a thing.

Some folks can't get there, and that's okay; if you don't have that level of trust, perhaps the cloud is not a fit for all of your workloads.


The point I am concerned about is that I am forced to trust a single party. AWS is not ever explicit in admitting this, at which point does it matter that your workload is on Nitro-this or attested-that? No university researcher, afaik, has physical access to audit these systems. I think the other major player(s) have a better story for this by harnessing features of certain cpu vendors.

To every cloud/server vendor: This is a big deal. I need a system I can audit, from silicon and firmware up, but I don’t want to water it, give it sunlight, or whisper sweet nothings to it, just to rent it out as needed.


If I understand correctly, it basically works the same as Trusted Boot on a local machine, with the host's CPU used as the root of trust. The difference is that the CPU creates multiple completely independent environments, with for example independent memory encryption keys.

Once you've got that, it's the usual TPM dance: each phase of the boot process verifies the next step and "ratchets" the TPM forward. The final OS uses the TPM's attestation to prove the TPM is genuine and not emulated, and the TPM's final state is used to prove it's running a genuine image booted through the proper process.

AMD had a whole bunch of SEV extensions for stuff like this. I reckon Intel isn't any different.


It's less about being able to prove to yourself and more about being able to prove to _other_ people.


I’m literally nonplussed by this revelation.


This is the most interesting thing Quanta has written about in some time now. Thanks for sharing. I can see new neural architectures being developed from this work.


You should know the sine and cosine for, say, 30 degrees. Say you’re rotating about the y-axis then you’ll rotate the xz-plane. Take the point (1,0,0). This is in the xz-plane (when y=0). Rotate it by 30 degrees about the y-axis. Where should it go? Draw the picture! Do the calculation with the matrix formula you are given, do they agree? Do this for different axes, different angle values, and different points. Eventually you will understand.

Hint: the standard way of drawing a normal graph has the x-axis positive to the right and the y-axis positive up. The right-handed coordinate system has the z-axis pointing out of the paper. This is where your fingers curl from x to y. In this coordinate system, looking down from the positive y-axis into the xz-plane, which direction does going from x to z curl around the y-axis? Is it right-handed or is it left-handed?

Good luck, keep at it!


Thank you for the information.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: