Discussion
Loading...

Post

Log in
  • About
  • Code of conduct
  • Privacy
  • Users
  • Instances
  • About Bonfire
Mason Loring Bliss
Mason Loring Bliss
@mason@partychickens.net  ·  activity timestamp 19 hours ago

I'm a C fan, and I get a lot of resistance as a result. (I'm also a Lisp fan, so maybe that balances the scales?)

From @david_chisnall we can read about some of the problems with C. This is from https://queue.acm.org/detail.cfm?id=3212479&doi=10.1145%2F3212477.3212479

"C code provides a mostly serial abstract machine (until C11, an entirely serial machine if nonstandard vendor extensions were excluded). Creating a new thread is a library operation known to be expensive, so processors wishing to keep their execution units busy running C code rely on ILP (instruction-level parallelism). They inspect adjacent operations and issue independent ones in parallel. This adds a significant amount of complexity (and power consumption) to allow programmers to write mostly sequential code. In contrast, GPUs achieve very high performance without any of this logic, at the expense of requiring explicitly parallel programs."

"The quest for high ILP was the direct cause of Spectre and Meltdown. A modern Intel processor has up to 180 instructions in flight at a time (in stark contrast to a sequential C abstract machine, which expects each operation to complete before the next one begins). A typical heuristic for C code is that there is a branch, on average, every seven instructions. If you wish to keep such a pipeline full from a single thread, then you must guess the targets of the next 25 branches. This, again, adds complexity; it also means that an incorrect guess results in work being done and then discarded, which is not ideal for power consumption. This discarded work has visible side effects, which the Spectre and Meltdown attacks could exploit."

Today a colleague shared another article, digging deeper into the myth that a flat memory model is central to C:

https://carminatialessandro.blogspot.com/2026/02/cheri-fil-c-are-they-c-memory-safe.html

I'd love a similar analysis of branch prediction complexity for Scheme and/or Common Lisp if folks know of one. I'm also curious how code that comes out of, for instance, Chicken Scheme compares to typical C code with regard to branching complexity.

#lisp #scheme #c

Cheri & Fil-C, are they the C memory-safe solution?

Looking at the past Pointers Were Never Meant to Be Just Numbers (And C Didn’t Kill That Idea… We Did) Ask a C programmer what a point...
  • Copy link
  • Flag this post
  • Block
David Chisnall (*Now with 50% more sarcasm!*)
David Chisnall (*Now with 50% more sarcasm!*)
@david_chisnall@infosec.exchange replied  ·  activity timestamp 19 hours ago

@mason

I am also responsible for the CHERI C/C++ abstract machine and the unification of the capability and fat-pointer models in CHERI, so these two posts are quite closely related things.

Branch prediction in languages with dynamic dispatch is interesting. I never got around to tidying up the work I did on software-hinted branch predictors for this kind of thing and publishing it, but if you have a deterministic dispatch model (ideally fewer than CLOS has) then you can do quite a lot sinking a fast path subset of it into hardware.

  • Copy link
  • Flag this comment
  • Block

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances
Bonfire social · 1.0.2-alpha.7 no JS en
Automatic federation enabled
Log in
  • Explore
  • About
  • Members
  • Code of Conduct