4 ms·

Prototyping in C

21 points by signa11 4y ago

daly 4y ago
I prototype in Common Lisp (described as "clay for the mind"). This gives a clear, standards-defined, prototype. Then I hand-translate it to C, usually without bugs since every function has a well-defined specification. The key issue is "impedence mismatch" (eg, hooking a soda straw to a firehose). C is "close to the machine" and "far from your problem". Lisp is the only language I know that is close to the machine and close to the problem. So, for example, (integrate (car x)) uses a machine pointer (car) on a data structure and then calls a "problem specific routine" all the same statement. Think in Lisp, code in C.
- jefftk 4y ago
  > This gives a clear, standards-defined, prototype ... every function has a well-defined specification This isn't specific to Lisp, right? Any other language would also ensure every function was unambiguous, no? I'm also not understanding how your "(integrate (car x))" example illustrates Lisp being "close to the machine". How does this differ from "integrate(x.first)" or something in other languages?
  - lispm 4y ago
    because .first invokes some machinery. Usually some OOP/FP machinery. The function CAR is a primitive operation in Lisp, which usually gets compiled to only a few basic machine instructions. CAR is basically just returning the first part of a cell made of two pointers (or similar sized immediate data like fixnum integers).
    - jefftk 4y ago
      > because .first invokes some machinery. Usually some OOP/FP machinery. It depends on the language and how you use it. Accessing a member of a C/C++ struct, a final member of a C++ class, Python class with __slots__, etc, is as efficient as a CAR operation. They all give you data that's at a particular place relative to the start your cell/struct/class.
      - daly 4y ago
        Which is fine until someone changes the C++ struct definition. This 'non-local' change affects the semantics of your code. Lisp's CAR definition is unaffected by non-local changes. You can think in any language but as noted by Wittgenstein “the limits of my language mean the limits of my world." For example, while it is technically possible in any language, the ability to write self-modifying code is unlikely to be thought of in most languages. Try writing non-object oriented code in Java.
        jefftk 4y ago
        > changes the C++ struct definition I don't think that's right? If we were talking about a class, then yes, but with a struct I don't think there is anything you can do that would change the nature of a property lookup. > This 'non-local' change affects the semantics of your code. I thought we were talking about how to pick a language for performance constrained solo prototyping? In which case you don't need to worry about someone else making changes to your code.
bluetomcat 4y ago
Anything that involves calling lots of OS primitives (syscalls) is a good candidate for prototyping in C. These are usually wrapped in higher-level languages like Python, but do not always have a direct 1:1 correspondence in terms of the flags and return values, have additional hidden behaviours due to the sandboxed environment, etc.
mattpallissard 4y ago
Sure, I don't like handling input or strings in C. But as the author notes, it's good for datastructures. Some, like his Trie, just can't be optimized or done sanely without a language that supports pointers. Additionally, if you're writing in a *nix system you have all the Posix man pages at your fingertips. Not exactly C specific, but I sure don't like reasoning about memory or compiler barriers like his shared memory example. Footguns galore. Footnote on barriers; The gcc extensions he was using; https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins..., https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync The kernel documentation naturally has different semantics and barriers available to it, but the behavior of compilers and cpu pipelining is documented well; https://www.kernel.org/doc/html/latest/staging/index.html#memory-barriers https://www.kernel.org/doc/html/latest/staging/index.html#me... Edit, footnote, formatting, link
- jefftk 4y ago
  > I sure don't like reasoning about memory or compiler barriers like his shared memory example. Footguns galore. I agree it's easy to screw this part up, but if you get it right the performance is far better than any of the other options.

21 points by signa11 4y ago

daly 4y ago

I prototype in Common Lisp (described as "clay for the mind"). This gives a clear, standards-defined, prototype. Then I hand-translate it to C, usually without bugs since every function has a well-defined specification. The key issue is "impedence mismatch" (eg, hooking a soda straw to a firehose). C is "close to the machine" and "far from your problem". Lisp is the only language I know that is close to the machine and close to the problem. So, for example, (integrate (car x)) uses a machine pointer (car) on a data structure and then calls a "problem specific routine" all the same statement. Think in Lisp, code in C.

jefftk 4y ago
> This gives a clear, standards-defined, prototype ... every function has a well-defined specification This isn't specific to Lisp, right? Any other language would also ensure every function was unambiguous, no? I'm also not understanding how your "(integrate (car x))" example illustrates Lisp being "close to the machine". How does this differ from "integrate(x.first)" or something in other languages?
- lispm 4y ago
  because .first invokes some machinery. Usually some OOP/FP machinery. The function CAR is a primitive operation in Lisp, which usually gets compiled to only a few basic machine instructions. CAR is basically just returning the first part of a cell made of two pointers (or similar sized immediate data like fixnum integers).
  - jefftk 4y ago
    > because .first invokes some machinery. Usually some OOP/FP machinery. It depends on the language and how you use it. Accessing a member of a C/C++ struct, a final member of a C++ class, Python class with __slots__, etc, is as efficient as a CAR operation. They all give you data that's at a particular place relative to the start your cell/struct/class.
    - daly 4y ago
      Which is fine until someone changes the C++ struct definition. This 'non-local' change affects the semantics of your code. Lisp's CAR definition is unaffected by non-local changes. You can think in any language but as noted by Wittgenstein “the limits of my language mean the limits of my world." For example, while it is technically possible in any language, the ability to write self-modifying code is unlikely to be thought of in most languages. Try writing non-object oriented code in Java.
      - jefftk 4y ago
        > changes the C++ struct definition I don't think that's right? If we were talking about a class, then yes, but with a struct I don't think there is anything you can do that would change the nature of a property lookup. > This 'non-local' change affects the semantics of your code. I thought we were talking about how to pick a language for performance constrained solo prototyping? In which case you don't need to worry about someone else making changes to your code.

bluetomcat 4y ago

Anything that involves calling lots of OS primitives (syscalls) is a good candidate for prototyping in C. These are usually wrapped in higher-level languages like Python, but do not always have a direct 1:1 correspondence in terms of the flags and return values, have additional hidden behaviours due to the sandboxed environment, etc.

mattpallissard 4y ago

Sure, I don't like handling input or strings in C. But as the author notes, it's good for datastructures. Some, like his Trie, just can't be optimized or done sanely without a language that supports pointers. Additionally, if you're writing in a *nix system you have all the Posix man pages at your fingertips. Not exactly C specific, but I sure don't like reasoning about memory or compiler barriers like his shared memory example. Footguns galore. Footnote on barriers; The gcc extensions he was using; https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins..., https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync The kernel documentation naturally has different semantics and barriers available to it, but the behavior of compilers and cpu pipelining is documented well; https://www.kernel.org/doc/html/latest/staging/index.html#memory-barriers https://www.kernel.org/doc/html/latest/staging/index.html#me... Edit, footnote, formatting, link

jefftk 4y ago
> I sure don't like reasoning about memory or compiler barriers like his shared memory example. Footguns galore. I agree it's easy to screw this part up, but if you get it right the performance is far better than any of the other options.