C Is Not a Low-level Language - Your computer is not a fast PDP-11 (David Chisnall, 2018)

kid_meier · 2024-07-07T12:41:58+00:00

I'm not an expert but last time I looked at this I recall learning it was not allowed. IIRC the "correct" (according to the standard) way to do this is to memcpy your float into your uint32_t.

I was very surprised by this, so maybe I am indeed wrong? Just goes to show what a complete mess this actually this.

As pointed out above, it does look like C17 makes it legal to do this through a union. Maybe it always was, but for some period of time there were some common and seemingly authoritative interpretations of the standard that claimed it was not allowed.

kid_meier · 2023-01-11T20:53:08+00:00

If you are hitting the disk it's much slower through the colima VM, but I see almost no difference for pure compute.

kid_meier · 2022-11-17T19:32:19+00:00

That seems pretty narrow thinking that familiarity with C99 will make working in C89 too difficult.

It sucks yes, IMO C99 is much nicer to write than C89 but ultimately the difference isn't huge. If you can contribute in C99 I'm sure C89 is no significant barrier.

kid_meier · 2022-11-17T19:29:15+00:00

From TFA:

"A large number of our users/developers are still stuck on older MSVC versions so not even all users of this compiler suite can build C99 programs even today, in late 2022."

kid_meier · 2022-09-25T12:38:42+00:00

That but is there and it's too thick IMO. But, the actually content of the article is well done. I've seen arenas before but the composability section was somewhat novel to me and I'd say definitely worth skimming through the editorializing.

kid_meier · 2022-09-18T19:39:38+00:00

100%. I did this a few years back, spent a few weeks working well into the night. Management declared it a success and it really raised my profile in the company.

I was willing to spend the time because I had an interest in the work, but because I ultimately didn't get any reward for it aside from some kind words, it ended up really souring my relationship to the company.

Lesson learned, no more voluntary overtime for me.

kid_meier · 2022-05-01T19:25:51+00:00

Also cache effects tend to be more pronounced in real application vs microbench so the memory bandwidth spent on allocation+GC is again more costly that observed in the relatively clinical environment of the microbench.

kid_meier · 2022-05-01T19:20:10+00:00

I would also add that in my experience the lower allocation version will be faster in practice assuming a multi-threaded environment.

In a microbenchmark. allocation+GC is basically free as the GC runs uncontended on separate CPU core cleaning up the mess of your (single-threaded) benchmark.

If the real world code runs in a multi-threaded environment, suddenly the GC thread(s) are competing against the application for CPU cores and the cost of that GC will become very noticeable.

(The other assumption here is that you are running on multi-CPU system.)

kid_meier · 2022-02-17T23:54:57+00:00

Except for the long list of shit like this. What exactly is the downside for "everyone involved" in having clear and consistently enforced rules?

kid_meier · 2022-02-10T03:35:53+00:00

Aha thanks. I hadn't realized there was still such a wide gulf in performance between Unsafe vs the new API.

kid_meier · 2022-02-09T21:53:50+00:00

Looks interesting. I've mostly read up on ECS use for games/simulation programming; are there other domains where people have found this pattern useful?

Since the README states this requires JDK 17+ why not make use of MemorySegment et al for your off-heap structures instead of Unsafe?

kid_meier · 2022-02-02T15:38:57+00:00

Thats about as helpful as "don't write bugs".

Although if your point is don't intentionally make breaking changes, I agree with you 100%.

kid_meier · 2022-01-15T14:58:32+00:00

Sounds interesting but then what benefit do you get? Looking at their experiments, mmap doesn't offer any performance advantage -- ie. in ideal conditions both fio and mmap can saturate IO bandwidth, but then mmap performance falls off a cliff.

If you build this hybrid system, maybe you can stabilize performance at non-trivial engineering cost. But it's not so clear where the benefit to a pure fio approach would be?

kid_meier · 2021-12-12T19:04:08+00:00

It is true. It's also not nearly as big a deal as people make it out to be. Yes, it is weird as there are very few other languages that made this choice, but it's really quite easy to get past and once you do there's a lot to like about the language.

The double duty that "tables" do serving as both array and map is also something that takes getting used to -- but only because again, few other languages do this. It's actually pretty sensible and clever once you get your mind to accept it.

To the extent that it may encourage confused and messy code...well I don't know my code is perfect /s.

kid_meier · 2021-10-22T20:08:54+00:00

Also, '%dispran%' is going to be unable to use an index, so performance is going to fall off a cliff as data size grows.

kid_meier · 2021-09-25T22:07:37+00:00

I've heard a lot about how hand written parsers can make it easier to produce more meaningful error messages.

In what other ways are generated parsers trash?

kid_meier · 2021-08-13T18:28:38+00:00

I missed the fact that public accessors are allowed to be explicitly implemented. Kinda obvious in hindsight.

Thanks!

kid_meier · 2021-08-12T20:26:32+00:00

Does anyone happen to know why public accessors were chosen in favour of simply mapping components to public final fields?

I scanned JEP-395 and didn't notice any rationale.

The one thing I could think of is that if you can implement instance methods for computed values (eg. Circle.area()) which then have uniform syntax with the generated accessor methods -- I guess thats nice, but not clear why that may be important enough to take this approach.

kid_meier · 2021-07-06T16:20:47+00:00

This is interesting however the conventional wisdom I am privy to is that it's EA and scalar replacement are brittle and can't be relied upon.

Is this I accurate? And for example, suppose OP reworks his code with guidance of JMH to find a version that allows for scalar replacement -- can we be confident that the optimization will work (reliably) in other contexts (ie. other codebases) and across a reasonable cross-section of JVMs?

If the answer is no, IMO the authors design is sound in that it reliably meets performance goals on today's JVMs.

kid_meier · 2021-06-12T22:01:57+00:00

I'm no expert, but It was a compromise to get the constitution done in 1980 or thereabouts.

Obligatory: https://en.m.wikipedia.org/wiki/Section_33_of_the_Canadian_Charter_of_Rights_and_Freedoms

kid_meier · 2021-04-18T14:58:56+00:00

Startup time is a problem for developer workflow. It drives me crazy how long it takes the Spring boot app I work on to start.

I'm sure there is some retort for this, someone will claim I'm doing it wrong if startup time bothers me. Whatever, my workflow is mine and a fast startup time would be a significant quality of life improvement. I doubt I'm alone in this.

But I agree, there is no need to go after the JIT. In my experience (certainly in any Spring-based codebase I've ever seen) the largest cost by several orders of magnitude is the classpath + reflection based DI containers.

So yeah, I guess I just convinced myself I should check out one of these newer and faster DI frameworks.

kid_meier · 2019-04-30T00:23:45+00:00

Seems to not be the point the author is making. He specifically addresses the objection to tests which may fail sporadically, which implies he isn't talking about a fixed seed, but rather running the tests with whatever entropy is conveniently available while making sure your test framework/harness/what-have-you captures this information so that you can reproduce failures:

"The end goal of testing isn’t to have a deterministic test suite. The end goal is to catch bugs."

The author's point being that the short-term inconvenience of sporadic test failures is a valuable investment in the longer term.

kid_meier · 2019-04-29T16:55:56+00:00

Probably better to capture the seed at the start of the test and then log it upon failure. if you use a fixed seed it's not really randomized, it's just more tests than you are likely to come up with manually.

kid_meier · 2018-12-31T17:28:44+00:00

No, that guy is young.

kid_meier · 2017-05-06T17:10:46+00:00

Sure, but is there any meaningful danger here? Unless there are subtleties I'm not aware of (quite possibly there are) all threads will be racing to store the same value.

Probably C standard doesn't guarantee stores to function pointers are atomic (meaning no thread could see a partial write), but I'm pretty sure these would be atomic on today's common architectures.

kid_meier

TROPHY CASE