151–160 of 162 posts
Earlier quoted context omitted.
I agree. There were only 2 game changing upgrades for me. One was hard disk to SSD. The other was x86 laptop to M1.
You really didn't feel Pentium 4 to Core 2 Duo was a 'game changer'?
M1 allowed me to do things I thought was impossible which was fast, fanless, cool, and extremely long battery life.
The Megahertz Wars were an exciting time. Going from 75 MHz to 200 MHz meant that everything (CPU limited) ran 2x as fast (or better with architectural improvements). Nothing since has packed nearly the impact with the exception of going from spinning disks to SSDs.
In my experience, SSDs had a bigger impact. Thanks to Wirth's Law ( https://en.wikipedia.org/wiki/Wirth%27s_law ) the steady across-the-board increase in processing power didn't equate to programs running much faster, e.g. Discord running on a modern computer isn't any more responsive, if not less responsive than an ICQ client was running on a computer 25 years ago. SSDs provided a huge bump in performance to each in…
The i486DX 33MHz was introduced in May 1990. A 30x increase, or about five doublings, in clock speeds over ten years. That's of course not the whole truth; the Athlon could do much more in one cycle than the 486. In any case, in 2010 we clearly did not have 30GHz processors – by then, the era of exponentially rising clock speeds was very decidedly over. I bought an original quadcore i7 in 2009 and used it for the nex…
Clock speed increases definitely slowed down, but now that software can use parallelism better, we're seeing big wins again. Current desktop/laptop packages are doing 100 trillion operations per second. The article's processor could do one floating point op per cycle, or 1B ops. So, we've seen a 100,000x speedup in the last 25 years. That's a doubling every ~ 1.5 years since 2000. It's not quite apples-to-apples, of…
Parallelism was pretty much the only way to get an increase in performance in the last 20 years.
What a time to be a kid then. We had a hand-me-down DEC x86 desktop at home with a Pentium II running at 233 MHz until I want to say 2002? This was around the time I learned how to build a PC since doing that was cheaper than buying one and no-one in my family had the money for that! I saved whatever money I could to buy a 128MB stick of RAM from Staples (maybe it was 256MB?), a few other things from TigerDirect/Newe…
Earlier quoted context omitted.
That's my point, the software was getting bloated at least as fast as the CPUs were getting faster, so you had to upgrade to a new CPU every few years to run the latest software. With SSDs, there was a huge overlap in CPU speeds that may or may not have an SSD, so upgrading to one meant a huge performance boost, within the same set of runnable software. Also, going from Sim City to Sim City 2000 was pre-bloat. Over t…
I wouldn't call that bloat; certainly we've been complaining about software bloat as long as I've been into computers, but at that time, software was simply pushing the capabilities of the hardware, and often running into walls. These days, we value developer productivity over performance optimization, so we have stuff like Electron apps. The reason behind it is that CPUs (and RAM quantity, for the most part) are so…
The vast majority have this foisted upon them by a minority of managers/shareholders.
Earlier quoted context omitted.
You joke, but it really is more work. Iv'e developed software in languages from assembly language to JavaScript, and for any given functionality it's been easier to write it in RISC assembly language running directly than to get something working reliably in JavaScript running on a framework in an interpreter in a VM in a web browser, where it's impossible to reliably know what a call is going to do, because everythi…
Even with older lower level languages like C and COBOL '02 it's easier to do simple things like find a file, read the file, and draw the file on the screen as a raster image using a resizable canvas than it is to write the JavaScript to do the same thing. The mangling of JavaScript to fit through every hole seems to be the biggest mistake made in modern programming, and I'm not sure what even keeps it going aside fro…
Earlier quoted context omitted.
Very bad by Apple standards and almost twice as much as more (idle) efficient current x86 laptop CPUs. Not terrible overall.
They were quoting laptop numbers, not the CPU. For reference, a M2 16" macbook pro has a 99Wh battery, and Apple advertises 16-17 hours max battery life. That's 5.8-6.25W. So, their estimate of 6W for the AMD flagship AI laptop is exactly in line with the Apple flagships.
Earlier quoted context omitted.
I've never seen a Xeon without a heat sink, I don't believe they are designed to run without one.
Indeed, even the oldest, slowest Xeons shipped in SECC cartridges with integrated heatsinks. But that was several years after the book cited by the GP was published (1994, shortly after the release of the original Pentium).
Earlier quoted context omitted.
You joke, but it really is more work. Iv'e developed software in languages from assembly language to JavaScript, and for any given functionality it's been easier to write it in RISC assembly language running directly than to get something working reliably in JavaScript running on a framework in an interpreter in a VM in a web browser, where it's impossible to reliably know what a call is going to do, because everythi…
Even with older lower level languages like C and COBOL '02 it's easier to do simple things like find a file, read the file, and draw the file on the screen as a raster image using a resizable canvas than it is to write the JavaScript to do the same thing. The mangling of JavaScript to fit through every hole seems to be the biggest mistake made in modern programming, and I'm not sure what even keeps it going aside fro…
Anyway, C doesn't support any of those things you mentioned, or even functionality as basic as memory allocation, but what it does have is a user-base that so consistently uses the same library for most functionality that it has earned its moniker as the "C standard library" and it's usually conflated with the language itself.
JavaScript, on the other hand, has more frameworks than there are programming languages in common use.
Earlier quoted context omitted.
Even with older lower level languages like C and COBOL '02 it's easier to do simple things like find a file, read the file, and draw the file on the screen as a raster image using a resizable canvas than it is to write the JavaScript to do the same thing. The mangling of JavaScript to fit through every hole seems to be the biggest mistake made in modern programming, and I'm not sure what even keeps it going aside fro…
So if c is easier. Why are we using JavaScript???
It's not even ambiguous; JavaScript uses syntax inherited from C, so if you can program in JavaScript, you can program in C, where you get a performant, stable, and simple standard library, instead of the framework-of-the-month club in JavaScript.