8 ms·

JS and Python are slow [see below] and heavyweight. Lua might work, I don't know... but this being header-only makes it pretty nice for simpler situations. EDI

JS and Python are slow [see below] and heavyweight. Lua might work, I don't know... but this being header-only makes it pretty nice for simpler situations. EDIT: Sorry, I wrote this a little too quickly and ended up writing a bit too coarse of a description. I meant JS and Python are both heavyweight to include in a project, and Python is slow both to initialize and to run. I didn't mean JS is slow to run. I don't know how fast it starts up either.

Erlich_Bachman 7y ago
I'm not sure about JS being necessarily that slow... The browser engines have done tremendous work in the last decade to make it very performant. It approaches java in some regards... It would be interesting to even see applications where this difference would be noticeable, let alone application examples where there would need to be so much complex logic in scripting itself, and also so much sheer computation requirements where this would ever make any difference... Also then, if this would be the selling point of ChaiScript, I would want to see some benchmarks (I have a hard time believing it will outperform lua with the built-in JIT or one of the faster JS engines with optimizations (it's not like performance is a novel desire in embeddable scripting languages, tons of manhours have been put into them already))... The website doesn't seem to have any such benchmarks.
- mehrdadn 7y ago
  See my edit, I think I was a little unclear with what precisely each adjective was referring to...
  - Erlich_Bachman 7y ago
    Alright, makes some sense and explains why they are doubling down on this "header only" thing.
rienbdj 7y ago
It is ridiculous that header-only is considered an advantage. The state of C++ build tools is very poor, and it is harming the language as a whole.
- mehrdadn 7y ago
  It's not an absolute advantage, it's just an advantage for some use cases. I certainly wouldn't mind a better build system that didn't make it less advantageous, but it's a hard problem...
- geezerjay 7y ago
  > It is ridiculous that header-only is considered an advantage. Why do you believe it's ridiculous? Being able to integrate a third-party library by just adding a few source files to your source tree is as simple as it gets. > The state of C++ build tools is very poor, and it is harming the language as a whole. This assertion makes no sense, particularly in the light of this discussion. Installing a headers-only library is a solved problem, and even template-heavy libraries such as Eigen are already distributed and installed quite easily with standard linux package managers.
  - rienbdj 7y ago
    I should clarify. Being able to add headers to a project in C++ is easy but adding translation units is not (usually). This encourages header-only libraries even when they are not really appropriate, increasing compilation times etc.
    - comex 7y ago
      Other things that become a huge albatross and are thus avoided: - Adding compile-time build steps, e.g. for code generation. - Adding dependencies of your own, even on, say, a tiny library of helper functions – unless you want to copy and paste it into your header. With a package manager, those things 'just work'. Package managers also make it much easier to update to newer versions of the library as they're released.
jacobolus 7y ago
Here, have a small embeddable Javascript: https://bellard.org/quickjs/ https://bellard.org/quickjs/
- mehrdadn 7y ago
  Edit: Turns out I saw this on HN earlier. It has a huge problem: it's not portable C!! Have fun with the __attribute__, unistd.h, __builtin_clz, etc.
earenndil 7y ago
How do you mean, python is slow to start up? $ time python -c 'exit()' python -c 'exit()' 0.01s user 0.01s system 98% cpu 0.021 total Seems pretty fast to me... And though python is no speed daemon, for a scripting/embedded language, it's likely to be fast enough.
- mehrdadn 7y ago
  10ms is already ridiculous for a program that just call exit(). Now try importing some stuff, and also testing a little more thoroughly... > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % (sys.executable, '-c', 'import re, argparse, subprocess'), 'import subprocess', number=n) / n))" Ubuntu (native): 20.82 ms/spawn Ubuntu (WSL): 43.16 ms/spawn Windows: 89.45 ms/spawn (without imports: 74 ms/spawn) For reference on Windows, here's PHP, taking half the time to start up: > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % ('php', '-R', ''), 'import subprocess', number=n) / n))" 45.14 ms/spawn Now consider that you'll generally be doing a LOT more on initialization than just importing these packages, a lot of packages end up being extremely heavyweight, and very likely you'll be calling Python several times in a row... it can easily waste seconds on startup, even on Linux.
  - earenndil 7y ago
    First off, WSL and MSYS2's startup time isn't really fair to compare, since if you're running on windows you're probably going to be running native python. Especially if you're using the kind of application that has scripts/plug-ins. I don't currently have a windows machine to test that, but I imagine you do since you just timed it. I also don't agree that 10ms is ridiculous. That's barely any time at all. That's less than a frame, at 60Hz. And, how many interpreter instances are you going to start up? Surely, no more instances than you have cores; that means, worst-case scenario if you have a ryzen threadripper or a maxed-out POWER9 (both have 96 cores), a second. For most people, it's going to take under half a second; considering most programs take tens of seconds to start up, I think that's fine. Not to mention that if you have 'complex initialization code', that's going to take a long time regardless of language; what we're testing the the language core baseline startup time.

Erlich_Bachman 7y ago

I'm not sure about JS being necessarily that slow... The browser engines have done tremendous work in the last decade to make it very performant. It approaches java in some regards... It would be interesting to even see applications where this difference would be noticeable, let alone application examples where there would need to be so much complex logic in scripting itself, and also so much sheer computation requirements where this would ever make any difference... Also then, if this would be the selling point of ChaiScript, I would want to see some benchmarks (I have a hard time believing it will outperform lua with the built-in JIT or one of the faster JS engines with optimizations (it's not like performance is a novel desire in embeddable scripting languages, tons of manhours have been put into them already))... The website doesn't seem to have any such benchmarks.

mehrdadn 7y ago
See my edit, I think I was a little unclear with what precisely each adjective was referring to...
- Erlich_Bachman 7y ago
  Alright, makes some sense and explains why they are doubling down on this "header only" thing.

rienbdj 7y ago

It is ridiculous that header-only is considered an advantage. The state of C++ build tools is very poor, and it is harming the language as a whole.

mehrdadn 7y ago
It's not an absolute advantage, it's just an advantage for some use cases. I certainly wouldn't mind a better build system that didn't make it less advantageous, but it's a hard problem...
geezerjay 7y ago
> It is ridiculous that header-only is considered an advantage. Why do you believe it's ridiculous? Being able to integrate a third-party library by just adding a few source files to your source tree is as simple as it gets. > The state of C++ build tools is very poor, and it is harming the language as a whole. This assertion makes no sense, particularly in the light of this discussion. Installing a headers-only library is a solved problem, and even template-heavy libraries such as Eigen are already distributed and installed quite easily with standard linux package managers.
- rienbdj 7y ago
  I should clarify. Being able to add headers to a project in C++ is easy but adding translation units is not (usually). This encourages header-only libraries even when they are not really appropriate, increasing compilation times etc.
  - comex 7y ago
    Other things that become a huge albatross and are thus avoided: - Adding compile-time build steps, e.g. for code generation. - Adding dependencies of your own, even on, say, a tiny library of helper functions – unless you want to copy and paste it into your header. With a package manager, those things 'just work'. Package managers also make it much easier to update to newer versions of the library as they're released.

jacobolus 7y ago

Here, have a small embeddable Javascript: https://bellard.org/quickjs/ https://bellard.org/quickjs/

mehrdadn 7y ago
Edit: Turns out I saw this on HN earlier. It has a huge problem: it's not portable C!! Have fun with the __attribute__, unistd.h, __builtin_clz, etc.

earenndil 7y ago

How do you mean, python is slow to start up? $ time python -c 'exit()' python -c 'exit()' 0.01s user 0.01s system 98% cpu 0.021 total Seems pretty fast to me... And though python is no speed daemon, for a scripting/embedded language, it's likely to be fast enough.

mehrdadn 7y ago
10ms is already ridiculous for a program that just call exit(). Now try importing some stuff, and also testing a little more thoroughly... > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % (sys.executable, '-c', 'import re, argparse, subprocess'), 'import subprocess', number=n) / n))" Ubuntu (native): 20.82 ms/spawn Ubuntu (WSL): 43.16 ms/spawn Windows: 89.45 ms/spawn (without imports: 74 ms/spawn) For reference on Windows, here's PHP, taking half the time to start up: > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % ('php', '-R', ''), 'import subprocess', number=n) / n))" 45.14 ms/spawn Now consider that you'll generally be doing a LOT more on initialization than just importing these packages, a lot of packages end up being extremely heavyweight, and very likely you'll be calling Python several times in a row... it can easily waste seconds on startup, even on Linux.
- earenndil 7y ago
  First off, WSL and MSYS2's startup time isn't really fair to compare, since if you're running on windows you're probably going to be running native python. Especially if you're using the kind of application that has scripts/plug-ins. I don't currently have a windows machine to test that, but I imagine you do since you just timed it. I also don't agree that 10ms is ridiculous. That's barely any time at all. That's less than a frame, at 60Hz. And, how many interpreter instances are you going to start up? Surely, no more instances than you have cores; that means, worst-case scenario if you have a ryzen threadripper or a maxed-out POWER9 (both have 96 cores), a second. For most people, it's going to take under half a second; considering most programs take tens of seconds to start up, I think that's fine. Not to mention that if you have 'complex initialization code', that's going to take a long time regardless of language; what we're testing the the language core baseline startup time.