I just got served a big chunk of JSON, not even pretty-printed, with the text in there... somewhere. Difficulty level: quite high, even in reader mode.
Right, but if you're referring to Return as Enter, then there's no reason to refer to Enter as Return. The reason for the change is that people don't distinguish the two. If we're going to eliminate this distinction, we should do it properly!
(I've had blank looks from a few colleagues after suggesting they press the Return key (that being the term I used to refer to the Return key) - which makes me wonder what percentage of people even know that Return is the name of a key. Perhaps we should retire the term entirely.)
How would that work for all the software that distinguishes between them? The standard (see e.g. Mathematica) is for `return` to create a new line in a multi-line text field, and `enter` (`fn+return` on a keyboard without a dedicated key) to execute/evaluate/commit the field.
But Return and Enter are still functionally different keys on macOS. Return inserts a new line, Enter (and cmd-Return) submits forms (which works for Reddit comments, but not here for some reason).
Except in many apps Return submits forms and Shift+Return inserts a new line, and in many other places Return and Enter do the same thing, showing to me that those labels are already pretty meaningless. It feels like a transition a good design team could figure out, keeping the distinction for those who want it, but simplifying for the rest. I believe Windows calls these Enter and Numpad Enter, or something like that? That feels better to me.
AFAIK those are not different keys, it's the literal keyboard combination Cmd+Return that is interpreted as submission in those contexts. Ctrl often works just as well on Windows for that purpose as well.
Numpad Enter is definitely a distinct key though, but I've never seen it treated differently than Return (except for randomly not working in some contexts that accept Return)
For parallelisable stuff that can occupy all cores for an extended period, the 2990WX typically takes about ~1.2x as long to do the same work/does ~0.83x the work per unit time, assuming code compiled with clang or gcc. Which isn't really coming across in the numbers here.
I haven't spent much time timing single core stuff, except - regarding clang, which looks like it contributes to the Geekbench 7 score, I did some measurements a few months ago suggesting that clang compiles for x64 more slowly than for ARM, all else being as equal as I could be bothered to try to make it: https://news.ycombinator.com/item?id=46938682 - and the single threaded test runs I did of my code suggest that the Geekbench 7 single core might be about right?
(Whether the clang timing discrepancy is actually relevant to Geekbench, I've no idea, but I thought it interesting anyway.)
If you need a benchmark that makes the PC look massively faster than the Mac, I'm sure those are available too.
Geekbench multi-core has been a single-task benchmark since version 6. The multi-core / single-core score ratio is supposed to tell how much you will benefit on the average when you use all available CPU cores. Some tasks parallelize better, while others have bottlenecks that prevent effective parallelization. For every CPU, the ratio is well below the nominal speedup you can get under ideal circumstances.
Note that Geekbench 7 no longer runs the same subtests in multi-core mode as in single-core mode, so any ratio calculated from the overall scores instead of from the individual subtests is misleading. There are a lot of subtests that it only runs in single-core mode and omits from the multi-core tests, seemingly to placate the critics that didn't like the inclusion of poorly-scaling tests in the multi-core mode. It's not as dumb as the Geekbench 5 strategy of just running N independent copies of the test, but it does seem like a dumb change to me.
Yeah, all of that would be great. Good ideas all round, and thank you for gathering all these sensible requests into one centralized list.
Slight problem, and it's not clear whether you've realised this: everybody else in the world knows that we can't have everything! Still, it's good to have goals, even if they can't be met, and it'd be monstrous to mock the ambition on display - which I do declare we should in fact salute. Good on you sir/madam, for not being a cynical jaded asshole like the rest of us.
So much Claude text. I'm sure this is great (I did a bunch of stuff with/to aardappel's lobster, years ago, and it was pretty tidy, and quite easy to work with), but: Claude's writing makes my brain melt.
Yeah it's very clear at the bottom that it's created by AI. I think this is an interesting case where someone with some great ideas they never got to can actually implement them. I personally hate the Claude style, but just looking at the samples was enough to get a feel for the language.
Lest it seem like I'm patting myself on the back for my ability to detect Claude's writing style, as if this instance would be evidence of any particular skill in that department: I did skim the README enough to note that bit.
right? man, I'm starting to really hate this kind of writing. Sure, use the llm to do the first draft, but at least, do a second pass and remove the stupid llm-isms
ARMv8-A has atomic CAS, unless this is some silly definition thing where it's "a system that has the behavior of atomic CAS but is named something else."
Maybe that's the trap I'm falling into? From memory it doesn't have any actually atomic operations, only an ll/sc sort of mechanism - which I've never really thought of as an atomic operation?
Though it's true you can end up with the same end result, in that you can just keep trying the operation until you accidentally do a read-modify-write that's ended up - well, "atomic" is a valid way to describe it.
So maybe it is good enough to count, though personally I'm still not quite convinced.
Yeah. I would call ll/sc atomic. Wikipedia's current verbiage:
> Load-link returns the current value of a memory location, while a subsequent store-conditional to the same memory location will store a new value only if no updates have occurred to that location since the load-link. Together, this implements a lock-free, atomic, read–modify–write operation.
reply