3 ms·

I recently plugged my extremely, abusively templated C++ library into Cling (the C++ interpreter mentioned) and everything worked like a charm. I can even use i

I recently plugged my extremely, abusively templated C++ library into Cling (the C++ interpreter mentioned) and everything worked like a charm. I can even use it in Jupyter notebooks. The speed feels more on the order of Python, though. But if the heavy lifting is done by precompiled libraries, I can see Cling having a pretty nice workflow for experimenting with and interfacing C++ code

binary132 3y ago
If I’m not mistaken, Cling is an LLVM-based JIT compiler, so it really should be performing close to the same level as an ahead-of-time Clang-compiled binary executable. Perhaps what you are noticing is JIT latency (from compiling on the fly.)
- WanderPanda 3y ago
  Maybe it is because of Debug vs. Release mode (and the optimization level coming with it) but I see a speed difference on the order of 10-100x vs. Release mode GCC
  - gpderetta 3y ago
    For heavily template code, a 10x-100x speed difference between -O0 and -O3 is not surprising in my experience. The cost of compiling at -O3 is going to affect interactive use of course though.
AtlasBarfed 3y ago
"The speed feels more on the order of Python, though." What part of "interpreted" did you not understand?
- WanderPanda 3y ago
  „Cling is an interactive C++ interpreter, built on the top of LLVM and Clang libraries.“ I don‘t understand your comment, do you care to enlighten me?
  - AtlasBarfed 3y ago
    Interpreters are slower than compiled code. Python is an interpreted language. Yes, dynamic recompiling, JIT-ing, etc etc. But you used a interpreter (for C++) with some expectation it would be faster than a language that is itself interpreted? I mean, I guess you could assume that the stronger typing of C++ would provide an advantage over Python... But if you hear "interpreted", you should assume 10x slowdown at minimum, unless there has been human-centuries invested in performance improvement like the JVM. RE: "nothing in the original message about expecting faster that interpreted code" He literally said "it's not any faster than Python" which is an interepreted language. He was expecting interpreted C++ to be substantially/perciptibly faster than Python ... an interpreted language. In case you didn't know a "scripting" language is 99% of the time interpreted.
    - pacha-- 3y ago
      There’s nothing in the original message that suggests that the commenter was expecting a faster execution in an interpreted environment.
    - teleforce 3y ago
      With D language you can have your cake and eat it too. This is because D has one of the fastest compilers. You can use rdmd as the REPL and also invoking the compiler for scripting [1]. [1]Why I use the D programming language for scripting: https://opensource.com/article/21/1/d-scripting https://opensource.com/article/21/1/d-scripting

binary132 3y ago

If I’m not mistaken, Cling is an LLVM-based JIT compiler, so it really should be performing close to the same level as an ahead-of-time Clang-compiled binary executable. Perhaps what you are noticing is JIT latency (from compiling on the fly.)

WanderPanda 3y ago
Maybe it is because of Debug vs. Release mode (and the optimization level coming with it) but I see a speed difference on the order of 10-100x vs. Release mode GCC
- gpderetta 3y ago
  For heavily template code, a 10x-100x speed difference between -O0 and -O3 is not surprising in my experience. The cost of compiling at -O3 is going to affect interactive use of course though.

AtlasBarfed 3y ago

"The speed feels more on the order of Python, though." What part of "interpreted" did you not understand?

WanderPanda 3y ago
„Cling is an interactive C++ interpreter, built on the top of LLVM and Clang libraries.“ I don‘t understand your comment, do you care to enlighten me?
- AtlasBarfed 3y ago
  Interpreters are slower than compiled code. Python is an interpreted language. Yes, dynamic recompiling, JIT-ing, etc etc. But you used a interpreter (for C++) with some expectation it would be faster than a language that is itself interpreted? I mean, I guess you could assume that the stronger typing of C++ would provide an advantage over Python... But if you hear "interpreted", you should assume 10x slowdown at minimum, unless there has been human-centuries invested in performance improvement like the JVM. RE: "nothing in the original message about expecting faster that interpreted code" He literally said "it's not any faster than Python" which is an interepreted language. He was expecting interpreted C++ to be substantially/perciptibly faster than Python ... an interpreted language. In case you didn't know a "scripting" language is 99% of the time interpreted.
  - pacha-- 3y ago
    There’s nothing in the original message that suggests that the commenter was expecting a faster execution in an interpreted environment.
  - teleforce 3y ago
    With D language you can have your cake and eat it too. This is because D has one of the fastest compilers. You can use rdmd as the REPL and also invoking the compiler for scripting [1]. [1]Why I use the D programming language for scripting: https://opensource.com/article/21/1/d-scripting https://opensource.com/article/21/1/d-scripting