4 ms·

I use C(as a backend) because I understand it. In reality I use anything that gets the job done faster. That usually means prototyping in C++,lisp, python, swi

I use C(as a backend) because I understand it. In reality I use anything that gets the job done faster. That usually means prototyping in C++,lisp, python, swift, java, perl, lua. After I have the prototype I code it automatically with C, or minimal C++ and my own DSLs, done in Lisp controlling C, C++ code generation. I have reinvented the wheel a lot. Someone told me you are not going to be smarter than a compiler, but having read several of them, they are so dumb, and they have to be because they are generic. E.G In a project I was using std::vector and predicted the expected performance of the whole program by O notation and "on the park" calculation needs as X. When I completed the program, it was X/1000. Fair enough I made some stupid mistake...in the end I got X/100 performance and could not optimize farther. I got so frustrated so I started replacing components to see if numbers improved. Replacing std::vector by a c vector made the program X/1.4!! So I started studying std::vector implementation and it was a template of a template of a template... I could not wrap my head around such a mess. My implementation was done in lisp with proper macros and was way simpler and efficient and generated c code, that was so easy (although tedious) to understand.

klodolph 7y ago
Reading std::vector or most parts of the C++ standard library is the path of insanity. It puts you in touch with some fairly arcane parts of C++, and on top of that you have the allocator class, which std::vector inherits from rather than embeds because if it were embedded, it couldn’t be zero bytes (otherwise every object wouldn’t have a different address). By comparison, glibc isn’t so bad to read. Same with the standard library for Python, Go, Rust, etc… I have never had such a problem reading library source code as I have with the C++ standard library.
ainar-g 7y ago
If this[1] article is to be believed, STL can also perform poorly in a debug build. [1] https://zeux.io/2019/01/17/is-c-fast/ https://zeux.io/2019/01/17/is-c-fast/
BubRoss 7y ago
If a std::vector is causing performance problems there is some major disconnect between how it is being used and how it is meant to be used. Someone else noted that debug more will stifle performance, which is true and the most likely culprit. Other problems can include constant resizing and memory allocation and copying, but when something is 1/100th the speed it should be, that screams debug mode being left on, which will do bounds checking on every access.
wuschel 7y ago
Could you perhaps elaborate on the LISP/DSL approach to programming that leads to efficent and safe C code? Thanks.
- taylodl 7y ago
  I second this request!
  - wuschel 7y ago
    A quick Google search gave quite a bit of results e.g. C-Mera [1]. [1] https://github.com/kiselgra/c-mera https://github.com/kiselgra/c-mera
taylodl 7y ago
Seriously, I'd like to see more about your Lisp DSLs controlling C, C++ code generation. I'm intrigued.

klodolph 7y ago

Reading std::vector or most parts of the C++ standard library is the path of insanity. It puts you in touch with some fairly arcane parts of C++, and on top of that you have the allocator class, which std::vector inherits from rather than embeds because if it were embedded, it couldn’t be zero bytes (otherwise every object wouldn’t have a different address). By comparison, glibc isn’t so bad to read. Same with the standard library for Python, Go, Rust, etc… I have never had such a problem reading library source code as I have with the C++ standard library.

ainar-g 7y ago

If this[1] article is to be believed, STL can also perform poorly in a debug build. [1] https://zeux.io/2019/01/17/is-c-fast/ https://zeux.io/2019/01/17/is-c-fast/

BubRoss 7y ago

If a std::vector is causing performance problems there is some major disconnect between how it is being used and how it is meant to be used. Someone else noted that debug more will stifle performance, which is true and the most likely culprit. Other problems can include constant resizing and memory allocation and copying, but when something is 1/100th the speed it should be, that screams debug mode being left on, which will do bounds checking on every access.

wuschel 7y ago

Could you perhaps elaborate on the LISP/DSL approach to programming that leads to efficent and safe C code? Thanks.

taylodl 7y ago
I second this request!
- wuschel 7y ago
  A quick Google search gave quite a bit of results e.g. C-Mera [1]. [1] https://github.com/kiselgra/c-mera https://github.com/kiselgra/c-mera

taylodl 7y ago

Seriously, I'd like to see more about your Lisp DSLs controlling C, C++ code generation. I'm intrigued.