3 ms·
If you find yourself setting out to write Haskell that can outperform C, you will probably be disappointed. I love Haskell, but the myth that it just takes a l
by chadaustin 10y ago
If you find yourself setting out to write Haskell that can outperform C, you will probably be disappointed. I love Haskell, but the myth that it just takes a little bit of elbow grease to make it as fast as C really needs to die. See for example: https://chadaustin.me/2015/02/buffer-builder/ https://chadaustin.me/2015/02/buffer-builder/
THAT SAID, I have a relevant story. IMVU used this file format called "CFL" for its 3D content. It was basically a kind of zip file except it used LZMA for asset compression. The original CFL library was written in C++, and while it worked fine, it was getting annoying to maintain and compile it, as well as inefficient to pass data from Python file buffers into C++ and back out. So one day I decided to see if I could replace it with a bit of Python code and pylzma. After I made this change, parsing our content files was _twice_ as fast. Having the code in a couple hundred lines of simple Python allowed me to optimize the data flows, minimizing copying from the file buffers into the LZMA decoder and then to the consumer of the data.
Sometimes the best way to make something fast is to write it in a safe, expressive language that lets you directly express your intent. :)
- khedoros 10y agoWhere was the wasted time? Something about converting the data back and forth through the CFFI? Just convoluted data flow?
- chadaustin 10y agoConvoluted data flow and unnecessary copies! The C++ implementation was thousands of lines and the Python one was a couple hundred, so it was much easier to see the path the data had to take.