> writing SIMD is just about as easy as a for loop
and then the first example requires 12 lines to replace one line of scalar code.
Be honest and say SIMD is hard but the results are worth it!
(Another nitpick: if this article is for newbies, don't use SIMD-only words and concpts before explaining them. Step 5 is good: scalar tails are mentioned and described. Step 1 is bad: nobody is supposed to know what broadcast mean.)
> if you’re careless about one thing like that you’re probably careless about other things
I'm not convinced. This rule holds only if the two "things" are related. But one can have a passion for serving the best quality coffee, and be a total wreck in graphic arts.
Good idea but strange syntax. It would be more idiomatic if the command came first and the list of globs last.
Additionally the use of "--" is not what everybody expects: here it is used to introduce one argument, the command, while it's usually meant to introduce multiple arguments without worrying if they have a leading "-".
A possible revised syntax with command as the first argument followed by a list of globs optionally introduced by "--" would allow to enumerate all files with a leading "-", which the current syntax cannot:
enumerate 'whatever {}' -- '-*'
I'm assuming "-f" for simplicity, but the same reasoning holds for "-L" too.
Because your comment was addressing the author instead of the article itself. Tell-tale words are "you" and "people".
It would have been different if you said, for example, "I have developed a rule that if something is too cheap, it must be rubbish". See how this delivers your opinion without suggesting stupidity about the others who don't share it?
Thank you. I imagined that the 3 words were just a rendez-vous token that the receiving end must hand to the relay to retrieve the right data. I understand that it also includes a password to validate the key.
How can one be sure that the relay does not record all the data flowing through it? There's not a second independent channel where the key is exchanged between sender and receiver.
It's not so widely used and it's not explained in the first couple screenfuls of TFA (which by itself is weirdly structured, taking entire paragraphs to explain when it was introduced, when it was discovered, etc. before even explaining what it actually is).
Of course the title was chosen when the article was first published on a site dedicated to security, where probably everyone knows it. This suggests that insisting on unmodified titles when republishing in HN is a poor rule.
I don't get it. If the ring structure has 4 field (excluding the cold ones), and all 4 have alignment constraints, doesn't it define 4 zones in 4 cache lines, and not 2?
I expected head and cached_tail, for example, to share the same line, but since they are both 128-byte aligned, they end up in separate lines. Granted, both lines are dedicated to only one side of the producer-consumer pipe, but we're wasting cache lines for nothing.
> You do seem to get more | shaped pieces when you leave those spaces open on the board.
I don't think this is correct, nor that it can be evinced from the article. What it does say is that the sequences that led them to achieve their target show a higher incidence of I shapes. This is because all the ones that show less I shapes have been "pruned away" by the cost function, which favors I shapes.
This has some relationship with the anthropic principle: isn't it strange that, of all the possible universes, we ended up in the one that seems fine-tuned exactly for life as we know it?
I can't speak for others, but I downvote to recommend other readers that the post is not worth reading. Not because I disagree with it, but because it's off topic in a way or another.
If TFA is about a tool, I tend to downvote comments that don't talk about the merits of tool but rather about the hosting website, the language it's written in, whether or not it "smells AI", English mistakes in the readme, and so on.
On the other side, if I reply to a comment I always upvote it, even if my reply is to refute it. In fact if I felt the need to add anything to it, it was by definition worth dealing with it!
I just wouldn't start off with bold sentences as
> SIMD can be simple to understand
and
> writing SIMD is just about as easy as a for loop
and then the first example requires 12 lines to replace one line of scalar code.
Be honest and say SIMD is hard but the results are worth it!
(Another nitpick: if this article is for newbies, don't use SIMD-only words and concpts before explaining them. Step 5 is good: scalar tails are mentioned and described. Step 1 is bad: nobody is supposed to know what broadcast mean.)