TinkersW

Oh my bad, I read that as nullptr, I use a custom optional that does not support such a silly mode as "disengaged"

That is actually memory safe, as null will always trigger access violation..

Anyway safety checked modes are sufficient for many programs, this article claims otherwise but then contradicts itself by showing that they caught most issues using .. safety checked modes.

Error Log/assertions prints are by are the most likely code to have not been run prior. Some compilers type check printf, but not all.

Good article, but for profiling you are missing the big daddy of them all, Tracy.

I my experience you absolutely must have type checking for anything that prints, because eventually some never previously triggered log/assertion statement is hit, attempts to print, and has an incorrect format string.

I would not use iostreams, but neither would I use printf.

At the very least if you can't use std::format, wrap your printf in a macro that parses the format string using a constexpr function, and verifies it matches the arguments.

My understanding is Rust compiles each crate in the same way C++ compiles each .cpp file, so if you stick everything in a single crate you get horrible compile times.

This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times.

It also seems like a disaster for incremental compilation.

The android team wasn't comparing like to like, though people seem to gotten the impression they were.

OpenAI appears to have bought the DRAM, not to use it, as they are apparently buying it in unfinished form, but explicitly to take it off the market and cause this massive price increase & squash competition.

I would call that market manipulation(or failure if you wish)--in a just society Sam Alton would be heading to prison.

FEX is a CPU JIT, so your GPU settings are irrelevant to it, it is translated but not by FEX, and there is no real perf hit for the GPU

The old games don't really matter with regards to FEX perf, so the only relevant bit is the semi newer games at 30/40 fps, which seems very slow to me, given that you are only running at 1080p/Medium, so you likely have a CPU bottleneck there.

One other accident that was similiar, but these planes have had a ton of crashes for other reason.

I am surprised Intels server chips can only do 2 AVX512 ops per cycle, that is rather sad given how long they have supported it in server chips, and I hope isn't a sign of things to come with Nova Lake.

Nova lake looks potentially pretty good, AVX512/APX and very very high core count, so maybe we will see AMD have some competition next year.

The article is simple wrong, dithering is still widely used, and no we do not have enough color depth to avoid it. Go render a blue sky gradient without dithering, you will see obvious bands.

The python example looks fixable with a reentrant mutex, no idea if that translates to the Rust issue.

Ya ever heard of this thing called a debugger? They have this amazing ability to show you what the problem is right when it happens!

I think memory safety is fine, but I plan to do it in C++ not Rust-- nothing in this article is remotely new either, just repeating the same tired stuff.

It seems pretty clear statistical hardware level memory safety is coming(Apple has it, Intel/AMD have a document saying they are planning to add it), the safety zealots can turn that on, or you can use FilC if you need absolute memory safety, but really C++ with various hardening features turned on is already fairly solid.

Also I think that memory safety is generally less important than thread safety(because memory safety is rather easy to achieve and detect violations), which almost all those languages recommended by this article blow chunks at. Rust could actual make a solid argument here, instead of wasting time yammering about memory safety.

The author refers to casting ints to floats but seems to actually be talking about converting. Casting is when you change the type, but don't change the data..

I don't really think much of Zig myself for other reasons, but comptime seems like a good design.

If you had read like even the basic part of that article you would know that && is not a pointer to a pointer.

Anyway C++ isn't as complicated as people say, most of the so called complexity exists for a reason, so if you understand the reasoning it tends to make logical sense.

You can also mostly just stick to the core subset of the language, and only use the more obscure stuff when it is actually needed(which isn't that often, but I'm glad it exists when I need it). And move semantics is not hard to understand IMO.

So you have to write fugly code just to get something that should be a compiler switch?

My experience was that every game ran.. but also nearly every game had issues with controls being different than Windows(mouse sensitivity was way off), control pad not working, screen or font scaling issues, and full screen wonkyness.

Somehow changing the font scaling in Linux caused the game to be scaled by a similiar amount.. so 2x font scaling = full screen is 2x bigger than actual monitor.. and I can only see 1/4th the screen.

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

  C++ has had whole program optimization since forever. And you can use static linking if you want, the same as Rust.

I dunno, the C++ template implementation of this macro would be far easier to read as it is just normal C++.

Your average none shared memory GPU communicates with the CPU over PCIe which is dogshit slow, like 100x slower than DRAM.

I can upload about an average of 3.7 MBs per millisecond to my GPU(PCIe gen 3, x8), but it can be spiky and sometimes take longer than you might expect.

By comparison a byte based AVX2 prefix scan can pretty much run at the speed of DRAM, so there is never any reason to transfer to the GPU.

What? He is a moron, and is advised by morons, I mean we are talking about a person that started a trade war with Canada.

Article doesn't make much sense, rambles on about frame stacks and calling convention etc, when these don't matter very much on modern hardware, and are hardly standardized(windows and linux don't use the same CC).

Modern hardware is about keeping the compute as busy as possible with as fast as possible access to memory, pretty much the opposite of the proposed solution..message passing.

Somewhat interesting read, if rather long..

My experience is that multi-threading has quite abit of overhead, not necessary from the scheduling, but from the cache misses because now everything is unlikely to be in cache, so a naive parallel for can easily end up consuming a ton of CPU resources, it may indeed finish quicker, but use 5x the overall CPU time to do so.

Then there is the other issue that parallel_for suffers from, the "starter" thread has to finish the loop, and if may end up with nothing to do for some time(like when one of the helper threads get suspended..), or it might end up going off to process some other work, causing the entire loop to take much longer to finish. So parallel_for kinda sucks, and I prefer using dependency graphs when I can.

They are optional though, and who can be bothered to add that when typing.

Reserve(reserve_exact in rust lingo) as a concept doesn't throw away amortized growth promise, so this entire post makes no sense.

You would need a very shitty implementation to achieve anything close to what you are describing(perhaps only allocating in powers of 2), and even then it would recover fairly quickly.

I wouldn't mind, but might need to increase cache line size on x86, as avx512 has reached the current size.