Although so far I'm mostly happy with Apple products. Happier than with any Windows laptops.
(But damn if I encounter a bug or an issue. Just reporting those have made hordes of Apple fans attack me, in response to a standard technical bug report.)
Youngsters have to understand that Apple's quality was so bad, not only did they fail to deliver in a few products with industry partners, the teams weren't even capable of writing a new operating system.
Windows is also equally away from "3x Developers!" cry days.
It is an unusual spelling and there is some trivia about it, it turns out — it's an anglicisation of "Kaplan", either by his father or by an official at Ellis Island:
And If you google just "Copland", you instead get references to the Stallone/De Niro/Liotta/Sciorra/Keitel/Patrick/Rapaport/Berg/Garofalo/essentially everyone good in cinema movie Cop Land.
(Which I rarely miss an opportunity to recommend, and I guess this is one)
Not the best for any of the actors or the director.. it was that good? Maybe I watched it with the wrong prior info. It /was/ during a cop-movie excess period.
It’s an outstanding movie, IMO. (But then I think it’s better to try magnificently and fail than to turn out most of the shit that passes for current movies.)
It really exists as an antidote to New York cop antihero movies, or maybe sort of a contentious, jaded superposition of them all. It’s an ensemble piece, full of great acting, complex dynamics, undercurrent of tragedy, abasement etc.; Stallone is brilliant.
The way the tables suddenly turn for Superboy (Rapaport) is a great turning point for the movie.
I have to be careful with hyperboles, seems like my comment got flagged. I meant "the things I cannot find with Google I can find with Yandex". I actually have no idea about overall censorship, so "zero censorship" is a bit insane of me to proclaim in retrospect.
Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive. From 386SX-16 to Pentium 66 MHz, that's over 20x difference in performance.
> Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive.
Absolutely
"How much of the sword emerged from the water" in Second Reality was a good measurement of CPU speed and video card performance, for example.
I remember seeing stuff in demos on my friend's Pentium Pro machine that I never saw on my 486SX-25 because routines ran faster and you could see more of the effect (since some demos were sync'd to the music and would move on irrespective of the progress of the effects). Heck-- just replacing my video card made a huge difference with some demos.
> Cycle accurate emulation helps little with this era PC demos
It works, and has done for some time, surely. What more is there to add here above accurate playback?
> From 386SX-16 to Pentium 66 MHz, that's 10-20x difference in performance.
Yep, and some demos had specific requirements for not only minimal CPU but maximal because the assumptions inherent in small-code timing tricks would break beyond a certain speed or because of significant differences in relative instruction execution times (and sometimes the unpredictability of those execution times as the P5 architecture and some of its frankenstein-486-like competitors added branch prediction). Larger demos were more flexible as you didn't need the small-code tricks to squeeze into 4Kb or sometimes less, so 64K demos and larger could be more flexible wrt target CPU.
But cycle-accurate emulation has this sorted to: you just need the instruction cycle time accuracy to be matching a particular CPU running to the pace of a particular clock. And given the description of how this is being done (“The demo is run on an x86 emulator that records…”) I assume this is actually using cycle-accurate emulation!
I'm guessing the benefit here is that the overhead of playing back the demo on each client machine is lower when playing this recorded version, compared to each viewer's browser running the initial emulation live in the browser. That and doing something a new way was fun or otherwise intellectually stimulating for the dev(s) involved.
Even with a cycle accurate CPU you'd still have a lot of variation caused by the motherboard chipsets, DRAM speeds, cache chips and graphics cards.
Tseng ET4000 was on a completely different level than something like Cirrus Logic CL-GD510 or heaven forbid, Oak Technologies card.
If the era appropriate PCs had huge variations, what extra does cycle accuracy really bring at this point? The same PC demo could perform very differently on two 486DX2 66 MHz PCs.
Wrt CPU: The cycles per instruction measures were entirely predictable with 386 and 486 chips, and more-or-less so with early Pentiums, you just need a delay loop so the faster ones didn't speed ahead of the lowest you were targetting. While there was a significant range to deal with, it was predictable. A 4K demo is going to fix in a 486's on-board cache (which I don't think was ever less than 8Kb aside from some relatively rare clone models), so DRAM speed, L2 cache and other motherboard variances, are not significant in those cases either.
Wrt GFX: Most demos, certainly when thinking about the 4K challenges, would be using nothing more than some variant of a basic VGA display mode (usually but not always Mode 13h or some variant like “Mode X”) without detecting and taking advantage of acceleration features - the difference between graphics cards at this point was not nearly as significant as what the demos were doing in the CPU, even the nastiest ISA card of the era is going to keep up at a reasonable framerate, IIRC from my doom playing days.
The first thing a 4k demo is going to do is to decompress executable. The second thing is to procedurally generate assets. Perhaps also do some code generation. So the cache footprint is going to be larger.
At this point you can be talking about 600 kB on a DOS machine. Sky is the limit on modern systems.
That said, typical inner loops of that era demos were pretty small, usually 20-200 byte range, IIRC.
Pre-cache era demos often had huge unrolled self-modifying speedcode inner loops, but that's another matter.
> The first thing a 4k demo is going to do is to decompress executable. The second thing is to procedurally generate assets. Perhaps also do some code generation. So the cache footprint is going to be larger.
Speaking as a 4k demo coder in the 2000s era, I think you're over generalizing. Decompression sure, but after that all bets are off.
Benchmarking like that is often broken because of continuous CPU core clock speed adjustments, system interrupts, SMIs, etc.
I tried to fix it by switching hyperthreading off, playing with the scaling governor, boost, setting a CPU frequency to no avail. The jitter was too much and the results were not reproducible, so I just gave up.
Of course your mileage may vary; this was on an AMD Zen 3 CPU.
Intel published some guidance on doing precise benchmarks. Basically run your code inside the kernel, turn off interrupts, use the cpuid instruction to prevent out-of-order execution, use rdtscp instruction instead of rdtsc, etc.
You just want to prevent the CPU from capturing the end time before it has finished the benchmarking code. Or prevent it from running benchmark code before it has captured the start time.
The way you work around this (apart from doing what you can to make the system as predictable as possible) is to accept that the data is noisy, and then working around it by doing multiple trials and following up with a statistical analysis on the results.
You can use the desired confidence to inform the warm-up, number of trials, benchmark duration, and so on.
If you end up with a multimodal distribution it can be worth tracking percentiles.
I did warm-up rounds, to prime caches and so on. I fiddled with statistics: IIRC simple average seemed to give the best results overall. I thought keeping the lowest n results would be the best, but that turned out to be wrong.
The results were indeed multimodal.
All I wanted was to have a reproducible benchmark to see how the code changes affected performance over time.
I've been doing some benchmarking recently and I've observed that on certain workloads, my CPU cores are not equivalent. (And this is an Intel CPU from 5 years ago, all cores are the same on paper.) In a particular very bad case I have a reproducible 50% performance difference between (physical) core 0 and core 5.
You might want to taskset to particular cores too, especially if you are looking at computational code with many almost-but-not-quite-random memory accesses.
Used to do this sort of thing for computations that needed to run in the 10 microsecond range (HFT stuff), circa 2008. Had very predictable results because:
a) language was not garbage collected (C++)
b) we avoided heap lock contentions in critical paths by pre-allocating object pools at startup
c) I/O operations were offloaded to separate threads, connected by mutex locked linked lists
d) processing thread was bound to its own CPU core
reply