605 karma · joined July 23, 2021
I have a 2008 C2Q Q9400/8G/SSD machine which is still used often, running Linux with Q45 IGPU. CPU load is low and it still has enough grunt to perform reasonably. I used it as a daily driver for many years and have never had an issue with web sites and basic office/dev work.
This is one of the major reasons why I have switched to Linux and never looked back. Obviously this mindset is not for everyone, but for a technical user willing to put effort into it you can end up with a great experience. Even knowing that an issue you reported has been acknowledged or is also experienced by others (and being able to track its progress) is quite reassuring.
While it's true that developers are often frustrated with people asking stupid questions if you actually put the effort into writing a proper bug report and trying patches out they are often happy to help you out. The Linux community is a technical community and users are expected to pull some weight in most cases.
Unfortunately for ARC they pretty much marketed it solely for gaming applications, where the chip and drivers don't really excel in. Linux support, AV1 encoding, and so on are its strong points, not raw performance. You can argue that those things don't make as much money as the gaming market, but if Intel's beaten by the competition on the performance side they'll need to find another route to sell this.
Such a model can backfire though as it would appear to be legal for a third-party contributor to create a set of scripts that would compile and prepare the application (load all the dependencies in a container and so forth) and release those scripts. Those scripts could even become accepted by a Linux distro's package manager, similar to how package managers package freeware prop software by using a script to legally grab the binary from the developer's site and installing it.
I'm talking about the concept of instructions, registers, addressable memory, etc. - with block diagrams, not with full circuits unless he's into that kind of stuff.
Then when he moves onto one of the high level languages that the other commenters are talking about the concepts will naturally stick. E.g. a variable is stored in memory, when we add two variables in the HLL we are copying those values to registers and using an ADD instruction, then we are writing the result back to memory. When there is an IF statement the computer will jump to either block of code depending on the conditional operation. Pointers become intuitive. And so on.
I've explained this to laymen and people who are interested in computers and have gotten a pretty positive reaction from them - so it's worth a shot. For a programmer who generally focuses on HLL it also allows them to get some idea of how their code is executed in the real world under all that abstraction.
It worked well for the course and the results were very consistent between runs, but that kind of setup doesn't scale well.
There may be a (slow) option though, and that would be benchmarking the code using an simulated processor. The runtime would be measured relative to the simulated processor as opposed to the computer hosting the simulator.