abainbridge

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

How would Rust fix this? Here's a Rust program that overflows a u8, with no compile error or warning. https://godbolt.org/z/ME3e9KeMe

You can turn on runtime overflow checking with the Rust compiler, but you can do that with gcc compiling C too.

I guess the answer is that you wouldn't do the memcpy like that in idiomatic Rust - you'd use some higher level construct that gives the compiler more chance to catch your errors. Could anyone comment on how this works in a case like this?

edit: Can't reply to repliers. Defined overflow doesn't help here. A checked_add() function could be used in the Linux kernel in C, just as easily as in Rust. Forcing checked_add() to be used in the Rust compiler would help, but would also have performance and readability impact, which is presumably why it is still being debated.

No. It sounds like Detours works even when the function hasn't got MOV EDI, EDI at the start.

Oh yeah, sophisticated: https://github.com/microsoft/Detours/wiki/OverviewIntercepti...

From https://www.microsoft.com/en-us/research/project/detours/

"Detours is a library for instrumenting arbitrary Win32 functions Windows-compatible processors. Detours intercepts Win32 functions by re-writing the in-memory code for target functions."

Doesn't that just re-write the DLL import table? ie it only allows interception of a Win32 API calls, not interception of my function A calling my function B?

> Cosmopolitan Libc allows you to log every function call over the program’s execution – just pass --ftrace at the end of your program, like this:

> ./hex16.com ./missing.txt --ftrace

That seems like magic. It seems you have to build with a special flag that tells GCC to put a nop at the start of each function. Then, before main runs, Cosmopolitan sees the --ftrace on the command line, and modifies the code in memory to replace those nops with calls to something that does the logging. See https://justine.lol/ftrace/.

Gah.

Here's an Android Tablet with that chip for £99 ($88 at current exchange rate). https://www.laptopsdirect.co.uk/tcl-tab-10s-32gb-10.2-inch-w...

Ahhh, that's why MT/s exists. All I need to know now is how many data bits are in a transfer and how many memory channels there are, and I'll be able to calculate how fast the memory interface is.

Good question. I'm thinking of morning rush hour because that I did a traffic survey then. I noticed a lot of building trades vehicles. All the trades people seem to want to be at their site for the day by 8.30am. I guess that is so they can do a full day's work before it gets dark (which is at 3.30pm in winter). There is also a lot of food suppliers delivering in time for catering teams to make lunch in schools, offices, cafes etc.

I probably shouldn't have called it rush hour. The traffic is busy from 7am until 7pm on weekdays.

Commercial traffic needs to drive - trucks and vans need cannot easily be replaced with public transport. I live on a busy road in Cambridge UK. At rush hour the traffic is about 50% commercial. I don't know what the proportion is in Paris, but my expectation is that the roads would still have lots of motor vehicle traffic even once you convert everything that can be to bike/public transport.

I'm fascinated by how this works. Does it do any CFD type of simulation of the gas flow in the engine? Is the simulation entirely 2D?

I've thought about doing a similar project myself but would like to be able to simulate the effects of engine tuning techniques such as "porting" of the cylinder head. I think that is quite hard - I don't think a simple incompressible flow CFD simulation would be sufficient. Particularly if you wanted to simulate the pressure waves in a tuned-length-induction system, I'm pretty sure you'd need compressible flow.

I haven't been able to find any suitable tutorials on simulating compressible flow. Most of the teaching material I found starts with vast amounts of pencil and paper maths exercises and assumes graduate level vector calculus. I want something that starts with for loops and a hand waving understanding of the concepts of vector calculus.

I think you could still do something interesting in 2D. I've struggled to find anywhere to discuss such ideas.

Gee thanks. I tried typing olive.c there. That didn't help. The string "tsoding" is the magic I needed.

How can I find them?

From the Zig language reference: Zig has many instances of undefined behavior. If undefined behavior is detected at compile-time, Zig emits a compile error and refuses to continue. Most undefined behavior that cannot be detected at compile-time can be detected at runtime. In these cases, Zig has safety checks. [...] When a safety check fails, Zig crashes with a stack trace

I agree with all of that. How theoretical are the optimization gains from the extra constraints guaranteed by Rust's borrow checker?

> Assuming you're thinking of the same thing

Yes.

> are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed?

Yes, the compiler for the first two and the standard library's heap implementation for the third.

> This path leads you to something like Rust

There are stops along this path before you get to Rust. If you just add the 3 things I mention above to a C like language, it would still be perfectly possible to leak memory. But that isn't a safety problem.

The 3 things don't include a borrow checker. You could still make doubly linked list and graph data-structures.

You can have safe manual memory management. The main cases of bugs are:

1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them.

2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking.

3. Use after free. Can be fixed by the free function zero'ing heap objects smaller than a page (eg 4KB), and unmapping larger ones so that future accesses are a seg fault. The heap also needs to not create new objects at the same address as deleted ones, but we have 64-bit address spaces, so maybe that's fine.

These all have costs, but so do all solutions to these problems.

I can't think of any reasons that a language with manual memory management has to be less safe than one with a Garbage Collector / ARC.