Hide table of contents

Introduction

This is a preliminary report on Finite Field Assembly (FF-ASM), a programming language designed to emulate GPUs on regular CPUs using Number Theory and Finite Field Theory. 

Finite Field Assembly (FF-ASM) empowers programmers to utilize Number Theory to invent their own math and solve their most immediate tasks.

FFASM summary

Use Cases

  1. Matrix multiplications for Artificial Intelligence.
  2. Emulate GPU-level parallelization on regular CPUs in specific cases.
  3. Error-correction coding for Communications.

Finite Field Assembly Language Features

  1. Finite Field is the primary data structure - FF-asm is a CUDA alternative designed for computations over finite fields.
  2. Recursive computing support - not cache-aware vectorization, not parallelization, but performing a calculation inside a calculation inside another calculation.
    • Recursive computing - performing one outer calculation lets you perform several inner calculations at the same time.
  3. Extension of C89 - runs everywhere gcc is available.
  4. Low-level systems language - no garbage collector so user handles memory allocation.

    Syntax for Finite Field Assembly

Is AI Compute a Hardware or a Software Problem

Sam Altman, the CEO of OpenAI, believes that access to computational resources will become the world's most valuable commodity. His views align with the growing demand for AI and machine learning capabilities among consumers and businesses. A multitude of companies offer hardware-first solutions to satisfy this demand for compute.

The market is saturated with hardware startups focused on delivering compute power for the next generation of AI inference. Custom hardware like Nvidia's GPUs, Groq's TPUs, and Etched's Transformer ASICs aim to address this growing demand for computational resources.

But what if hardware isn't the real bottleneck? Perhaps all our calculations are correct, and the issue lies in the possibility that we're computing in the wrong number system?

Meme highlighting the absurd nature of modern-day compute

Finite Field Assembly: A Language for Inventing Your Own Mathematics

Finite Field Assembly is built on the thesis that mathematics is largely invented rather than discovered. For example, while binary digits (0 and 1) are discovered concepts, binary floating-point arithmetic—the mathematical framework for storing fractions on computers—is entirely invented. 

Finite Field Assembly is a programming language designed to empower users to define their own mathematical systems. We provide a framework for creating custom rules, operations, and structures to enable entirely new ways of computation. 

The language is built around number theory, congruences and the divisibility properties of primes.

Prime numbers and finite fields serve as fundamental data structures in Finite Field Assembly. This focus permits a unique approach to computation, rooted in mathematical principles rather than conventional programming paradigms.

How addition works in Finite Field Assembly

Getting Started with Finite Field Assembly

Finite Field Assembly (FF-asm), much like CUDA, is an extension of the C programming language. It is built on top of C89, commonly referred to as ANSI C or ISO C, with the goal of ensuring compatibility wherever a standard C compiler is available. This design allows FF-asm to be highly portable and accessible across a wide range of systems.

Installing Dependencies

  1. One needs a working installation of the GNU MP Bignum library.[1] Here's the link to install libgmp.
    1. Ubuntu installation instructions here.
  2. Create a file called 01_HelloWorld.c in the same directory that contains ff_asm_runtime.h and ff_asm_primes.h
    • Sample Directory Structure

Writing Hello World in FF-asm

Remember, FF-asm, just like CUDA, is an extension of C. It's super low-level so you need to hande memory allocations. 


This Hello World Program creates an 8-bit unsigned integer finite field.  You can find the source code here.

#include <stdio.h>
#include "ff_asm_runtime.h"

//Run : gcc 01_HelloWorld.c -lgmp -lm -o m.o && ./m.o
int main()
{
	//Unsigned 8-bit array
	uint8_t data[] = {50, 100, 20};
	uint64_t fieldOrder[] = {8, 9, 11};
	size_t dataLength = sizeof(data) / sizeof(uint8_t);
	
	//Allocate memory for a FF-asm field of type Int_8_U_Field
	ff_asmField field = ff_asmMalloc(dataLength, Int_8_U_Field);
	
	//Set our finite field order
	ff_asmSetFieldOrder(field, dataLength, fieldOrder);
	
	//Place data in the FF-asm fieldNode at index 0
	ff_asmAppendData(field, dataLength, data, Int_8_U_Field);
	
	//Print the FF-asm field
	ff_asmPrintField(field);
	
	//Free the FF-asm field
	ff_asmFreeField(field);
	return 0;
}

Compiling a FF-asm module using GCC

Remember to link libGMP.

$ gcc 01_HelloWorld.c -lgmp -lm -o m.o && ./m.o
$ ./m.o

Understanding the output of our Print Function

You should observe this output once you compile and run your code.

Field Data Type: Int_8_U_Field
Field Length: 3
Field Node Count: 1
Field Order : 8 9 11 
	Node Data Type: Int_8_U_Field
	Node Data Length: 3
	Node Data :  50, 100,  20, 
	Node integer : 658
  1. Int_8_U_Field : This is the field data type, an unsigned 8-bit integer in this case.
  2. (8,9,11) : Field order (the number of elements your field can hold). i.e you can store 8 * 9 * 11 elements in the field .
  3. 658 : This is a unique integer that represents your specific the set of finite field elements. It is the solution to a linear congruence.

Next step : Emulating a GPU on a CPU using Number Theory

If you've made this far, we invite you to look further into our documentation here

Finite Field Assembly Documentation

You can also 

  1. Support our next research goal - ff-GEMM : Finite Field GEMM Matrix Multiplication
  2. Star our GitHub repo.

 

 

 

Comments


No comments on this post yet.
Be the first to respond.
Curated and popular this week
LintzA
 ·  · 15m read
 · 
Cross-posted to Lesswrong Introduction Several developments over the past few months should cause you to re-evaluate what you are doing. These include: 1. Updates toward short timelines 2. The Trump presidency 3. The o1 (inference-time compute scaling) paradigm 4. Deepseek 5. Stargate/AI datacenter spending 6. Increased internal deployment 7. Absence of AI x-risk/safety considerations in mainstream AI discourse Taken together, these are enough to render many existing AI governance strategies obsolete (and probably some technical safety strategies too). There's a good chance we're entering crunch time and that should absolutely affect your theory of change and what you plan to work on. In this piece I try to give a quick summary of these developments and think through the broader implications these have for AI safety. At the end of the piece I give some quick initial thoughts on how these developments affect what safety-concerned folks should be prioritizing. These are early days and I expect many of my takes will shift, look forward to discussing in the comments!  Implications of recent developments Updates toward short timelines There’s general agreement that timelines are likely to be far shorter than most expected. Both Sam Altman and Dario Amodei have recently said they expect AGI within the next 3 years. Anecdotally, nearly everyone I know or have heard of who was expecting longer timelines has updated significantly toward short timelines (<5 years). E.g. Ajeya’s median estimate is that 99% of fully-remote jobs will be automatable in roughly 6-8 years, 5+ years earlier than her 2023 estimate. On a quick look, prediction markets seem to have shifted to short timelines (e.g. Metaculus[1] & Manifold appear to have roughly 2030 median timelines to AGI, though haven’t moved dramatically in recent months). We’ve consistently seen performance on benchmarks far exceed what most predicted. Most recently, Epoch was surprised to see OpenAI’s o3 model achi
Dr Kassim
 ·  · 4m read
 · 
Hey everyone, I’ve been going through the EA Introductory Program, and I have to admit some of these ideas make sense, but others leave me with more questions than answers. I’m trying to wrap my head around certain core EA principles, and the more I think about them, the more I wonder: Am I misunderstanding, or are there blind spots in EA’s approach? I’d really love to hear what others think. Maybe you can help me clarify some of my doubts. Or maybe you share the same reservations? Let’s talk. Cause Prioritization. Does It Ignore Political and Social Reality? EA focuses on doing the most good per dollar, which makes sense in theory. But does it hold up when you apply it to real world contexts especially in countries like Uganda? Take malaria prevention. It’s a top EA cause because it’s highly cost effective $5,000 can save a life through bed nets (GiveWell, 2023). But what happens when government corruption or instability disrupts these programs? The Global Fund scandal in Uganda saw $1.6 million in malaria aid mismanaged (Global Fund Audit Report, 2016). If money isn’t reaching the people it’s meant to help, is it really the best use of resources? And what about leadership changes? Policies shift unpredictably here. A national animal welfare initiative I supported lost momentum when political priorities changed. How does EA factor in these uncertainties when prioritizing causes? It feels like EA assumes a stable world where money always achieves the intended impact. But what if that’s not the world we live in? Long termism. A Luxury When the Present Is in Crisis? I get why long termists argue that future people matter. But should we really prioritize them over people suffering today? Long termism tells us that existential risks like AI could wipe out trillions of future lives. But in Uganda, we’re losing lives now—1,500+ die from rabies annually (WHO, 2021), and 41% of children suffer from stunting due to malnutrition (UNICEF, 2022). These are preventable d
Rory Fenton
 ·  · 6m read
 · 
Cross-posted from my blog. Contrary to my carefully crafted brand as a weak nerd, I go to a local CrossFit gym a few times a week. Every year, the gym raises funds for a scholarship for teens from lower-income families to attend their summer camp program. I don’t know how many Crossfit-interested low-income teens there are in my small town, but I’ll guess there are perhaps 2 of them who would benefit from the scholarship. After all, CrossFit is pretty niche, and the town is small. Helping youngsters get swole in the Pacific Northwest is not exactly as cost-effective as preventing malaria in Malawi. But I notice I feel drawn to supporting the scholarship anyway. Every time it pops in my head I think, “My money could fully solve this problem”. The camp only costs a few hundred dollars per kid and if there are just 2 kids who need support, I could give $500 and there would no longer be teenagers in my town who want to go to a CrossFit summer camp but can’t. Thanks to me, the hero, this problem would be entirely solved. 100%. That is not how most nonprofit work feels to me. You are only ever making small dents in important problems I want to work on big problems. Global poverty. Malaria. Everyone not suddenly dying. But if I’m honest, what I really want is to solve those problems. Me, personally, solve them. This is a continued source of frustration and sadness because I absolutely cannot solve those problems. Consider what else my $500 CrossFit scholarship might do: * I want to save lives, and USAID suddenly stops giving $7 billion a year to PEPFAR. So I give $500 to the Rapid Response Fund. My donation solves 0.000001% of the problem and I feel like I have failed. * I want to solve climate change, and getting to net zero will require stopping or removing emissions of 1,500 billion tons of carbon dioxide. I give $500 to a policy nonprofit that reduces emissions, in expectation, by 50 tons. My donation solves 0.000000003% of the problem and I feel like I have f