logoalt Hacker News

Why we write our own C and C++ inference engines

61 pointsby eatonphillast Friday at 4:17 PM27 commentsview on HN

Comments

stephbooktoday at 3:51 AM

Should have started with writing your own blog posts.

show 5 replies
aabditoday at 9:12 AM

I don’t think it would be surprising that people want to write their own kernels.

A big problem with the existing engines like llama or sd is that they don’t support optimal graph compilation. Usually this means about a real 2 or 3x multiplier loss relative to optimal. Cuda graphs do okay but they still leave a lot on the floor

It’s usually worth it to optimize in that context if you are willing to peer into the mechanics.

Of course that’s expensive. You need to know how to appropriately pipeline and merge your kernels.

dennis16384today at 4:14 AM

I had a similar success with Model2Vec static embedder and NER inference (both GGUF, compiled for WASM), ported to plain C from ONNX Runtime.

Wasm size from 30Mb to 300kb and 1.5x speedup. It's definitely worth it for performance or distribution size.

scottcodietoday at 4:58 AM

I did took a native c++ approach when writing a relational transformers engine (RelativeDB). My journey was pytorch -> c++ -> Triton (lang). While C++ was more performant than Triton, I couldn't afford to optimize on every gpu. I just accepted the ~15% throughput loss for my cloud service, which honestly wasn't bad for the amount of flexibility I got out of it.

But the cpp port of vllm looks great, that'd be great if you'll maintain that. I hit the same limitations with vllm.

piterrrotoday at 6:27 AM

Could this vllm port be faster to install? Im starting gpu machine multiple times a day and it takes 5 minutes to set vllm up. If Inise this port that time is minimized?

adithyassekhartoday at 4:25 AM

What you get: X is the A, Y is the B.

federicoTXTSlast Saturday at 7:43 PM

[flagged]

openrocketstoday at 8:08 AM

[dead]