Klar Wichamul

@cmuratori @ThePrimeagen @quantum_binary @burkeholland As unintentional

@c00ldata @ThePrimeagen @quantum_binary @burkeholland Not sure how else to take these if that wasn't your intent.

@c00ldata @ThePrimeagen @quantum_binary @burkeholland I'm tired of the entire conversation.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland But we don't have an ideal HW and we have to simulate, measure and verify that we can reliably meet the deadlines. And write a software in a way that verification is as cheap as possible. This is the hard and much harder engineering task than optimising for average performance.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland At this point I am getting a bit tired of this CPU cycle counts. Of course the main think is proving the execution count and in an ideal hardware this would be as easy as just " count the cycles".

In a way, this hurts me to read. My guy was holding out on AI for so long and I guess I felt like maybe he was right and programming would return somehow some way. AI is both the best and worst thing to ever happen to us.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland Where did I state that? O stated it is not as simple as just count the CPU cycles. Read your initial response lol

@cmuratori @ThePrimeagen @quantum_binary @burkeholland Yes, but this is not a simple count of clock cycles. Your statement was: HRT is *longer, not harder". All you have to do si count clock cycles. But deterministically counting clock cycles while keeping the determinism in your there devices is hard.

If you can prove that the code takes n cycles or less to execute, then how have you not proven the WCET of that code? And more broadly, if you have not proven that the code takes n cycles or less to execute, how could you possibly claim to have proven the WCET?

@cmuratori @ThePrimeagen @quantum_binary @burkeholland You think this approach is easy to do with resource contention? It is just like...yeah count the CPU cycles?

@c00ldata @ThePrimeagen @quantum_binary @burkeholland Well, maybe you can explain to me what part you think is missing. If you determine the upper bound on the number of cycles the code can take, then you know the maximum wall clock time it takes, ergo you have the HRT bound. That's the beginning and end of the story.

@AgileJebrim @cmuratori @ThePrimeagen @quantum_binary @burkeholland Which is my point. It is not only counting CPU cycles. It is harderand not just longer.

Technically there are multiple clock domains to consider. Every core has its own clock domain and the memory system has its own clock domain. There is occasional clock drift between them as well. The worst case is the maximum of all of the above. I think Casey has the skill to figure this out. He’s also got the right gist of what the goal is from a theoretical standpoint. I just don’t think he’s done much of any work personally for this specialized optimization target. No need for any disrespectful words to be used here. The real challenge is making it cheap to actually write large amounts of WCET-proven code that also doesn’t need to be reverified across a wide range of different hardware platforms and data configurations. V&V of what Casey is describing is currently very expensive in practice. Even more challenging is proving it in a situation where shared resources exist. If two cores try to touch the same hardware resource at the same time, you get nondeterminism. A big reason I’m building my own new compiler for all of this is because existing tools really aren’t well suited for making guaranteed hard real-time code cheap to produce and verify in a portable manner. Isochronous computing is the key to make it cheap and portable. Always run in the worst case at all times by always compiling exclusively to instruction patterns that have no variable latency, then it’s a simple matter of running and measuring any application with any data against the target tick time, alongside also proving the handful of compiler-generated instructions used actually have no variable latency.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland Yes. But that are not just cpu cycles. I don't know if you really don't understand or just pretending. Validation of WCET is not just counting CPU cycles. If you are claiming that, you really don't have a fucking clue what you are taking about.

WTF are you talking about? It's not hard real time if you don't put a maximum bound on all of those things! It's soft real time!

@cmuratori @ThePrimeagen @quantum_binary @burkeholland No. I think I just exposed you.

There are many, many, MANY ways that a uarch can produce varying cycle times for the same proven worst case O() bounds. So if you don't understand that, you have no business going on X and talking trash about HRT.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland Mate, you don't know what you are taking :) But sure you can try to convince you fanboys. Business is business.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland You just proved you actually don't know anything about HRT. You just thing about CPU clock. If you would actually know what you are taking, you would intuitively understand that hard real time is not about clock arithmetic but verifiable worst case bounds.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland Lol..no. it is not just counting :) You completely missed on the part where program design must be deterministic where WCET are always met. Not sometimes. Always. This is harder, not just longer.

@c00ldata @ThePrimeagen @quantum_binary @burkeholland But again, I would say, if you don't think I know how to do these things, why do you think I shouldn't be on The Standup? If you don't think I know how to program, then where is the "shouldn't be on the show" objection coming from?

@cmuratori @ThePrimeagen @quantum_binary @burkeholland This is much harder, l and costly work, than optimising for average execution times.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland It is not the same type of work. Not at all. People forget that hard real-time is not something you say you do, but needs to be verifiable and verified, especially with the regard to worst case execution time.

@cmuratori @ThePrimeagen @quantum_binary @burkeholland I am sure you think you can. In theory. But you've never produced a certified real time software with proven WCET...so why do you think you can?

@c00ldata @ThePrimeagen @quantum_binary @burkeholland OK, well, if you think I have that little knowledge about programming, then I'm not sure why you would care what podcasts I'm on :)

@cmuratori @ThePrimeagen @quantum_binary @burkeholland I do.

@c00ldata @ThePrimeagen @quantum_binary @burkeholland Not sure why I'm going to bother asking this, but are you implying that you don't think I would know how to write a hard real-time program?

@ThePrimeagen @cmuratori @quantum_binary @burkeholland Also the question was directed to you directly. Don't piggyback on Casey's content.

@ThePrimeagen @cmuratori @quantum_binary @burkeholland Hard real-time, safety critical systems for defense. Something neither Casey nor you and your pals come close to.

@cmuratori @quantum_binary @burkeholland Sure.

@c00ldata @quantum_binary @burkeholland Couldn't you just skip watching it, though?