Blog posts discussing the technical implementation detail "SSA"
← Back to all tagsBlog posts discussing the technical implementation detail "SSA"
← Back to all tagsThe “AI industrial complex” in its current form is not sustainable. While transformers have delivered remarkable capabilities, their energy consumption and computational demands reveal a fundamental inefficiency: we’re fighting against nature’s design principles. The human brain operates on roughly 20 watts, processing massive volumes of information through sparse, event-driven spikes. (at least, as we currently understand it today) Current AI systems consume thousands of watts to support narrow inference capabilities, forcing dense matrix operations through every computation.
Read MoreWhen we set out to build Firefly, we faced a fundamental question that cuts to the heart of functional systems programming: how far down the compilation stack can we preserve the elegant abstractions that make F# powerful? Specifically, can delimited continuations - the theoretical foundation for async/await, generators, and algebraic effects - survive the journey from high-level F# through MLIR’s SSA form to executable code? And perhaps more importantly, should they?
Read MoreIn 1998, Andrew Appel published a paper that heralded a change to how we should think about compiler design. “SSA is Functional Programming” demonstrated that Static Single-Assignment form, the intermediate representation at the heart of modern optimizing compilers, is exactly equivalent to functional programming with nested lexical scope. This insight has profound implications as we enter a new era of hardware-software co-design. At SpeakEZ, this revelation validates our approach with the Fidelity framework more than 25 years after its first publication: lowering F# to native code through MLIR isn’t just possible, it’s aligned to the fundamental structure of well-principled compilation.
Read MoreWe at SpeakEZ have been working on the Fidelity framework for a while, and it’s been a journey to find the right balance of familiar conventions with new capabilities. Nowhere is that more apparent than in the async/task/actor models for concurrent programming. The Iceberg Model: Familiar on the Surface, Revolutionary Underneath Think of Fidelity’s concurrency model as an iceberg. Above the waterline, it looks remarkably similar to what you already know:
Read MoreFor .NET developers, the term “frontend” already carries rich meaning. It might evoke XAML-based technologies like WPF or UWP, the hybrid approach of Blazor, or perhaps JavaScript visualization frameworks such as Angular, Vue or React. Within the .NET ecosystem, “frontend” generally refers to user interface technologies - the presentation layer of applications. When that same .NET developer encounters terminology like “MLIR C/C++ Frontend Working Group,” something doesn’t quite compute. This clearly isn’t referring to user interfaces or presentation technologies.
Read MoreThe computing world has fragmented into specialized ecosystems - embedded systems demand byte-level control, mobile platforms enforce strict resource constraints, while server applications require elasticity and parallelism. Traditionally, these environments have forced developers to choose between conflicting approaches: use a high-level language with garbage collection and accept the performance overhead, or drop down to systems programming with manual memory management and lose expressiveness. Beyond Runtime Boundaries The Fidelity Framework represents a fundamental rethinking of this dichotomy.
Read MoreIn our work to bring F# to systems programming, we’re pursuing a vision of deterministic memory management outside the familiar boundaries of managed runtimes. For developers who have only known automatic memory management as an omnipresent runtime service, the concept we’re pursuing - applying RAII (Resource Acquisition Is Initialization) principles to actor-based systems - represents a significant departure from established patterns. Our current research focuses on how three complementary systems work together: RAII-based arena allocation, the Olivier actor model we’re developing, and our proposed Prospero orchestration layer.
Read More