adql

The chip has quasi-compiler that compiles stream of assembler instructions into uops and dispatches it onto various parts to run, often in parallel.

That part is driven via microcode (kind of like firmware) and fixes in that can fix some CPU bugs.

Which also means that one core can essentially run multiple assembler instructions in parallel (say fetch memory at same time floating point operation is running, at the same time some other integer operation is running etc.) and it just makes it look like it was done serially.

The difference that at same level of let's say "UB bugs in code", C++ code will compile, Rust will not. So person learning C++ will start producing code quicker even if their level of competence will produce more buggier code.

> You can discriminate against white people because they are white, but that's different than racism.

That's racism. I think you're just trying to excuse your own racism here.

Sometimes, when you read a sentence to the end, the meaning changes.

You should try that sometimes

You seem to conflate "good" with "cheap"; particle board is "just" cheap, it's not good.

Plywood will be stronger, lighter, and deal better with humidity, it is "better" as material on pretty much every measure.

Yup, difference to the engineer is minuscule.

It's getting traction coz chip companies don't want to pay ARM for licensing, not because it is particularly better at something.

I was like that, now it kinda only works for something I'm really passionate about

I find it depends heavily onto the task. Some let's say "organizational" work (moving stuff around, adding new machines to cluster etcetera) that just requires to be done but not "hard"? Can do for hours, will get a bit slower just coz of boredom. So the first 4 hours are still more effective than next 4 hours but not as much so, especially when I take break in the middle (bless WFH)

Programming or designing something complex to program ? Way shorter. So I usually mix and match

I remember few times when I just got into driving I was so proud of myself when backing in into a tight spot... then figuring out it was for nothing coz I can't get out of the car

US stupidity it seems. From what I managed to google two reasons I saw was "coz they might hit shrubbery" and "some states dont require plates on front of the car"(WTF) "and if you back in police can't see them and check"

I just assume one of 2 reasons:

* there is a wall and they need to pack/unpack something from the boot.

* they are incompetent at parking.

I don't buy "I wanted to save a bit of time now", backing up doesn't take all that much longer if you're competent at it and stress of having to back out with no vision is not worth it.

> And you've got all that while backing into the spot,

Not really

> plus you have to not hit 2 more close obstables that are behind you, in your blind spots.

If you didn't hit it in your mirrors, you won't hit it going in unless you did something horribly wrong.

And frankly if you have problems backing in into a spot you shouldn't have driving license as you clearly don't have enough control of the vehicle you're driving to be a safe driver.

Yeah angled spaces help but head-in is pretty much just "well, there is wall in front and I need to load groceries" case for me

I just blink the blinkers in direction of parking spot. So far 100% of the drivers get it

Right but alternative is making people pay for stupidity of some randoms. I don't have problems with socialized healthcare, it's mostly not person's fault they happened to have worse health than others, but this is just compounded effect of multiple stupid decisions in a row

> The rule is very simple IMO, I already described it: if other execution can run while you wait for the value, it's blocking. (Edit: to be specific, other observable execution, so in your thread with write access to state you can see)

is gmtime() blocking ? Technically it needs to ask kernel to get the time so it has same potential to block as any other call

> As you already mentioned, the code that computes a trillion digits of Pi is async if its interruptible, and not async if it isn't.

Very bad definition as either

* every single code is because kernel can always reschedule thread to do something else * none of the compute code is if language runtime can't interrupt it (old versions of Go had that behaviour for tight loops IIRC) * every of compute code is if language can arbitrarily interrupt it.

> From here on you seem to not be aware of the fantastic recent developments in WebWorkers, it is now quite easy to spin up worker threads in JS, which communicate with the main thread via message passing.

That's entirely worse approach as sharing any data structures is impossible and where mutex would be enough you're now shoveling tons of data around. It's workaround at best

It's like saying "my language is multithreaded because we started many processess and communicate via redis"...

The point is that having to think about color of the function is disadvantage and needless complexity

> If I write a block of JS in an async context, I can be 100% guaranteed that the only times when any other task may interfere with my functions execution are explicitly marked with `await`. I love this!

You only need to think about it because runtime isn't parallel. If you want ordering in execution you should be using synchronization primitives anyway.

In Go doing "async" via channels could possibly start running the code the instant you instantiate it, on however cores there are available. Go have problem of that requiring a bunch of boilerplate (as there is no macros), but with generics now it is manageable and I can just say "here is function, run it on all elements of the slice in parallel" very easily and it all be pretty reasonabe, like

    out = ParallelMapSlice(mapFunc,8,in)

All done async without thinking about async.

The point is that having to think about color of the function is disadvantage and needless complexity

> If I write a block of JS in an async context, I can be 100% guaranteed that the only times when any other task may interfere with my functions execution are explicitly marked with `await`. I love this!

You only need to think about it because runtime isn't parallel. If you want ordering in execution you should be using synchronization primitives anyway.

In Go doing "async" via channels could possibly start running the code the instant you instantiate it, on however cores there are available. Go have problem of that requiring a bunch of boilerplate (as there is no macros), but with generics now it is manageable and I can just say "here is function, run it on all elements of the slice in parallel" very easily and it all be pretty reasonabe, like "out = ParallelMapSlice(mapFunc,8,in)".

All done async without thinking about async.

I really feel that's this is just inherent to async/await model, you can only put so much lipstick on a pig.

Light threads + messaging (whether proper like Erlang or bastardized like Go) feels like far superior model for concurrency in near-all cases and also easier to write and reason about (series of "functions" sending messages looks very similar to serial code) but I'd imagine it would be very hard to make convenient in GC-less language

Then you user wonders why they see 40GB of files but 70GB of used space

> Yet other databases operate on the stream of changes and the current state of data is merely the application of all changes until a certain time, allowing multiple transactions to use different snapshots without blocking each other (you can parse a file while somebody else edits it and you won’t be interrupted).

Databases have features in-place to merge those parallel strings of changes and at worst, abort transaction. Apps using that handle that.

Now try to explain to user why their data evaporated coz they had it open in 2 apps...

Personally I think keeping it low level but predictable would be far saner approach. App knows what it want to do with data, filesystem can't. Just trimming all of the inconsitencies (especially the "fun" around sync and cached access..) and it's already much better. Of course probably very hard to do without fucking up existing apps ;/

> Operating systems could support START TRANSACTION on filesystem operations, allowing multiple operations to be performed atomically and with isolation. No more having to reason carefully about which posix file operations are atomic, no more having to worry about temp file TOCTOU etc.

And your performance goes absolutely to trash once you start trying to make filesystem act as transactional database. Especially if you then try to use the filesystem for a database.

> fopen(..., 'r') could, by default, operate on a COW snapshot of a file rather than on the raw file on the filesystems. No more having to worry about races with other processes.

Another "performance goes to trash" option. Sure, now more palatable with NVMes getting everywhere, but still a massive footgun

> Temp files, like database temp tables, could by default only be visible to the current process (and optionally its children) or even the current thread. No more having to worry about temp file races and related issues.

Already an option O_TMPFILE

> O_TMPFILE (since Linux 3.11) > Create an unnamed temporary regular file. The pathname argument specifies a directory; an unnamed inode will be created >in that directory's filesystem. Anything written to the resulting > file will be lost when the last file descriptor is closed, unless the file is given a name. ... > Specifying O_EXCL in conjunction with O_TMPFILE prevents a temporary file from being linked into the filesystem in the >above manner. (Note that the meaning of O_EXCL in this case is differ- > ent from the meaning of O_EXCL otherwise.)

That does seem like interesting avenue. Just present blog as single user site then allow federated comments, with maybe some banlist if you get some unsavory commenters.

Tho that gets to the same problem as we had already - nothing stopping spammer from just creating new domain for each comment

I mean that's just "write the blog/activitypub in something that's not RoR or other just as slow stack". "Just" that.

With SQLite and maybe a tiny bit of caching you can also get "no external DB deps" easily

Markdown really seems like more sensible target for the "microblogging" than text or HTML. All the formatting you need for even a proper blogpost, readable plaintext, with extensions can even be pretty useful for programming stuff

Both. It lived off an assumption that the magic compiler generating perfect assembly ideally fitting architecture will come out, and so CPU can skip the whole "crap" related to assigning incoming instruction stream to CPU's execution units. Which just didn't worked in practice.

Current approach of CPU being basically an optimizing compiler that takes assembly in and generates uops to drive whatever execution units the CPU has might be wasteful silicon wise but... caches are much more transistors than this anyway and it allows CPU design to be separated from incoming assembly and so any improvements there are instantly visible to most existing code.

All it takes for Apple to be open is for consumers to put the money where their mouth is and be loud about it. Which didn't happen, so it isn't.

Give it a year of lower than usual profits and some twitter complaints and they will backpedal at mach 10

> I think what Apple’s afraid of is an app like Facebook tricking/forcing users to sideload in order to bypass privacy protections and get full access to user data. I don’t think they’re at all worried about hobbyists sideloading open source apps.

Nah, they're worried someone might sideload a software with payment method that doesn't give them cut

How they have "gone out of their way" ?

Well, tech-competent people mostly survived that without scratch so they want same experience of actually owning machine today as they had 10 years ago.

The push for containerization and sandboxing is in right direction if user have control over it.

By all means run the new app I downloaded in nice little box and ask me when it wants to access any file from outside of it, but if I want to I should have option to give it permission to whatever I want.

But it's worse than appliance. Appliance doesn't actively block you from using it for something not listed in instruction manual