seacount

Inspiration

Microsoft's BitNet paper in 2024 showed a result that should have shaken the foundation of AI- models inference cost brought down so low, that the model's storage + usage dropped down 7-8x that of a normal fp64 models. The unfortunate thing is, this is special only for Microsoft's model. You can't properly train a model without Microsoft's harness, which closes off a lot of things. A normal person can train a normal model at any time at full fp64, but he cannot do the same with ternary models. Hence, the idea of seacount was born. It's original idea came to me in high school, I already had the design ready and what it would have in it that bugged me in other languages. Later, when I came across the BitNet paper, I realised that this is what Seacount can be. An on-device, local AI, in ternary, fully trained on seacount, and the firmware image flashed onto it also by seacount (targetting Pico devices in the future first), would be the future.

What it does

It's a custom built language currently, with it's own unique syntax that is nothing like out there on the market. It's speciality is contract based relations. All relationships between data is fixed at compile time itself. If your data is of a wrong shape, the code won't even compile. Example- int.array(5) arr = {1,2,3,4,5}; The above array's shape is initialised even before the data was read. In the IoT and embedded world, this is massive and crucially important, since we work with such low hardware and magnanimously lesser SRAM. So, to make a ternary model work on such weak devices, you have to be absolutely optimised.

How we built it

It uses Rust as it's backend

Challenges we ran into

Accomplishments that we're proud of

Reached NumPy and PyTorch levels of performance in terms of CPU (Not GPU, I don't any personal GPUs of my own). Fully Contract based syntax accomplished. The entire programming language reads like a legal document between the programmer and the compiler, and it's meant to be that.

What we learned

That building a language is fucking hard. And I am sure it will get even worse when I decide to build Rivercount. Explaining that in the next section.

What's next for seacount

When the language is fully performance optimised and completed, I will move on to Rivercount. It's a subset of Seacount, that basically takes seacount files, and spits out a no_std version of it as a firmware image of the device we are targetting. For Rivercount to know what files you want to target, you create a rivercount header file within the project directory you have your seacount files in (.rvrh). Then, you fill the file with such statements- @bundle()::for: (); Then, rivercount is run on the rvrh file, and it spits out a firmware image that can be flashed onto the embedded device. Sounds easy when I explain it, but mind you, this will probably be harder than building the language itself. But, I still got trust in myself for it. Ternary models will be the future, and I want seacount to be the leader of it, just like how Python became the undisputed king of data and ML.

Built With

• rust