abainbridge

Yeah, agreed. My comment should really have been, "I'm glad modern ISAs are high level because low level ones would be a massive burden". And, "It isn't C's fault that low level ISAs are a massive burden".

But we have/had architectures that expose parallelism at the instruction set. Eg itanium and graphcore. And the PS2 made cache management the programmer's problem. I don't think any of these experiments proved successful in the long run.

This article is correct that your computer is not a fast PDP-11 but wrong that this has anything to do with C. Eg, "another core part of the C abstract machine's memory model: flat memory. This hasn't been true for more than two decades."

This has nothing to do with C. The hardware insists on this abstraction. And its a good job too, otherwise your programs would stop working when moved to a machine with different cache.

Elite 3 (aka First Encounters) was before my time. Braben kept wanting to get another Elite project going, but there was barely enough resource to do a decent job of the two games that were already in development at the time (Dog's Life and Wallace & Gromit in Project Zoo). Most of the staff had been promised that another Elite game was imminent when they were hired. None of us could quite understand why we were making two games about dogs when we owned the Elite franchise. I still don't understand. Probably something to do with Money and Business Deals.

This was a long time ago, when I was only a baby programmer. It's changed beyond all recognition since I was there. It was sort of lovely. The "office" was a farm house in the Fens. There were two dogs in the office. One was a big soft greyhound called Tigger on account of his stripes. The other was a whippet that had to be kept away from people because it was a nervous creature that would occasionally snap at people. I think there was probably about 15 people there when I started. The software development was chaotic. The chaos provided a lot of freedom and opportunity but caused some serious problems too. Suffice to say that when I left after three years to go and write Darwinia with Chris Delay, we wrote a game engine of our own over about 3 months and once we had that, I'd say we were 20x more productive at creating game content than was possible at Frontier on the Dog's Life team. That said, the Frontier tech at the time did have a nice animation system capable of relatively convincing quadruped animation. It could blend walk/trot/canter/gallop animation loops, do inverse kinematics for foot placement and I think it did vertex blending for polys near skeletal joints. And the engine worked OK on a PS2. Darwinia could do none of those things.

Interesting stuff. I'm going on a 20 year old memory of a conversation I probably didn't understand at the time, so I'm very fuzzy on the details.

Many years ago, when I worked at Frontier, David Braben told me a fun anecdote about NES Elite. He said they initially got the game working using the hardware timer in the NES to keep track of real time so that the in-game physics progressed at a constant rate regardless of the frame rate, which varied. When they submitted the game to Nintendo for pre-release checks, Nintendo said they couldn't use the hardware timer because a few of the earliest NESs didn't have working ones. So Bell/Braben had to make the functions in the game maintain their own estimate of how many clock cycles they each took that frame. At the end of the frame they were all added up and used as an estimate for how much real time had elapsed.

Looking at the source github, it appears I misremembered, or likely didn't even understand what Braben was saying. elite-source-bank-7.asm has a comment saying, "Update the NMI timer, which we can use in place of hardware timers (which the NES does not support)". It looks like they somehow implemented their own real time (ish) clock by counting non-maskable interrupts.

> no, it won't move your memory around into larger areas every time you call it. Most of the time it will simply bump up the allocation end point. This happens more frequently than you think.

I just tried some simple "I want to grow my block of memory" test cases. A malloc of 1000 bytes couldn't be increased by a single byte without being moved to a new location. An allocation of 1 million bytes couldn't be increased by 1% without being moved to a new location.

https://godbolt.org/z/Gr4bchxv5

Here's one way to get to the "it's never going to happen" outcome:

The grand-parent comment argues that we need AI that works in a much broader set of circumstances to "solve" self driving. In particular it would need to understand how other humans would react to its actions in novel situations. That is approximately a description of having a Theory of Mind. Some argue that you can't have a Theory of Mind without being conscious. We might ban captive conciousnesses for ethical reasons.

I think you could invent lots of other scenarios that yield the "never going to happen" outcome. They probably all sound ludicrous, because having an AI that understands the workings of human minds sounds ludicrous (and frightening).

The same game (almost) with the same slider (almost) is not at all confusing: https://www.chronophoto.app/game.html

Getting the subtle elements of a UI wrong have a profound effect.

Yeah brother, me too. An fx-100D to be precise. I had to put new batteries in it ~8 years ago. I love the minimal UI. I use Real Calc on my phone when not near my fx-100D. Each time I'm infuriated by the overhead of: unlock phone, launch app, dismiss the "do you want to upgrade" banner.

I guess the way I presented thoughts looked like I was saying NSS are bad for you. I don't have the evidence for that claim. But I don't think the balance of evidence is in favour of NSS either.

I know you can cherry pick health studies to support any argument you like but I don't feel like I've done that. The WHO guidelines/study that we linked to is supposed to be a broad summary of the whole research area. The guidelines document doesn't recommend NSS for anything. It only recommends _against_ using them for things.

> Ref[3] is obviated by ref[2] and meaningless in isolation, reasons described in the 200 page WHO report.

Whereabouts? I couldn't find what you're referring to.

I'm not sure artificial sweeteners are good for anything.

A 2019 meta analysis published in the British Medical Journal said, "Most health outcomes did not seem to have differences between the NSS (Non-sugar sweeteners) exposed and unexposed groups." - https://www.bmj.com/content/364/bmj.k4718

A few months ago, "WHO advises not to use non-sugar sweeteners for weight control in newly released guideline" - https://www.who.int/news/item/15-05-2023-who-advises-not-to-...

My guess is that things tasting sweet is part of the problem. For example:

"Ingestion of these artificial sweeteners (AS) results in the release of insulin from pancreas which is mistaken for glucose (due to their sweet taste). This increases the levels of insulin in blood eventually leading to decreased receptor activity due to insulin resistance." - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7014832/

And:

"the role of sweet taste in energy intake and appetite regulation is controversial" - https://www.mdpi.com/2072-6643/6/9/3431

I think rear underrun protection and sideguards became mandatory in May 1983. https://www.legislation.gov.uk/uksi/1982/1576/pdfs/uksi_1982...

From the article, "A commonly heard advice is to not use binary search for small arrays, but to use a linear search instead. I find that not to be true on the Apple M1 for integers, at least compared to my branchless binary search, when searching a runtime-sized but otherwise fixed size array".

I expect the linear search is better when the data being searched isn't yet in cache because it allows the memory subsystem to better predict what the CPU will access next. I'm not sure how large this effect is. It would be interesting to see the benchmarks redone on uncached data.

Hmmm. Fair point. I got this argument from a HW engineer I know. You forced me to think more about what he was saying. His point was actually that the TSO model requires the HW to keep track of more stuff. More stuff uses more energy and adds latency to every memory access. It also limits how many accesses the memory subsystem can handle in parallel. He points out that ARM, RISC-V and even ia64 (Itanium) chose the relaxed model because it is better.

edit: The emphasis is wrong here. The main benefit of a relaxed memory model is that it reduces the amount of work the memory subsystem HW needs to do.

Another ISA difference not discussed by the article is the memory model. I expect that the memory model and the degree of reordering permitted by the architecture could have a significant impact on performance.

x86 imposes stricter ordering constraints on memory accesses. The choice of this memory model was made long ago, when, I guess, it was felt that this made the behaviour easier to understand for the programmer.

In contrast, ARM's memory model permits more reordering of memory accesses, which can lead to potential data races and inconsistent program behavior. However, this greater flexibility can also lead to higher performance, as the processor can execute memory accesses in a more efficient manner by overlapping and reordering them.

I can't find any studies that measure the impact of this, but I'd be surprised if it wasn't a significant win for the ARM ISA in many programs.

How does the benchmarking work here? I always find this kind of micro-benchmarking hard. I feel like I want to see results with and without a preceding cache flush. And with/without clearing of the branch predictor state. Other things I find hard are: 1) ensuring that the CPU is running at full(ish) speed and isn't in a slower-clocked power saving mode for some of the test, 2) effects of code and data alignment can be significant - I want to measure a bunch of different alignments.

Does gtest (that the author used) help with these things? Does anything?

Find me a regular Mk1 or Mk2 Escort in really good condition, and I will gladly pay you £3126.

Even the boring models command ridiculous values now: https://www.classiccarsforsale.co.uk/ford/escort/351743

For £6750 you can have one in really bad condition and with the steering wheel on the wrong side: https://www.ebay.co.uk/itm/234972695631

I think Ford Escort means something different here in the UK. They've gone up in value hugely in the last 20 years and are generally worth a lot more than Model T Fords now. (Annoyingly they're worth much more than a contemporary Porsche 944, which was much more desirable when new. Annoyingly because I own a 944 and not an Escort).

https://www.silverstoneauctions.com/1980-ford-escort-rec0351...

https://www.evoke-classics.com/auction/1922-ford-model-t/

How can we quantify "not actually much"? Here's my attempt for multiply:

You'd have to do a imul instruction followed by a right shift. On, say, Ice Lake, the imul has a reciprocal throughput of 1 and a latency of 3. The shift has RT of 0.5 and a latency of 1.

So compared to regular integer multiply, a fixed-point implementation on Ice Lake would be 0.67x the speed if you were throughput bound and 0.75x the speed if you were latency bound.

But most (all?) other operations wouldn't be any slower than regular integer operations, so a real program would slow down by less than the figures calculated above.

Efficient fixed-point arithmetic requires hardware support.

"Some DSP architectures offer native support for specific fixed-point formats, for example signed n-bit numbers with n−1 fraction bits (whose values may range between −1 and almost +1). The support may include a multiply instruction that includes renormalization—the scaling conversion of the product from 2n−2 to n−1 fraction bits.[citation needed] If the CPU does not provide that feature, the programmer must save the product in a large enough register or temporary variable, and code the renormalization explicitly."

From: https://en.wikipedia.org/wiki/Fixed-point_arithmetic#Hardwar...

I'd also add speed to that list. Resizing is an expensive operation. Correctness is often traded off for speed. I've written code that deliberately ignored the conversation to a linear color space and back in order to gain speed.

But is also expected to life 7.5 years longer.

I think the Xlib dependency would prevent compilation as an αpε. I put some effort into doing X11 from scratch (without Xlib or Xcb) to make this possible. Or at least, my aim was to be able to build with musl libc and generate a single executable that would run on many different Linuxes.

https://github.com/abainbridge/deadfrog-lib/blob/master/src/.... It is janky though.

How would I do that? I think there is any such function in the Win32 API.

I used to use a timer to limit the frame rate to 60 Hz too. But on Windows, I found that DwmFlush() seems to act like WaitVSync(), so I've been using that in preference for years now. I think this is undocumented behaviour. I guess what it actually does is wait until the compositor is ready for another frame.

To be able to call that function, I LoadLibrary("dwmapi.dll"), and then GetProcAddress(dwm, "DwmFlush").

std::midpoint also seems to yield less efficient code with g++12 targeting x86-64: https://godbolt.org/z/j695ce98Y

Possibly true, but it yields less efficient code in GCC 12 for x86-64. https://godbolt.org/z/oafPrb4K8