by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Tharindu Mathew
@mackiem
after profiling I see that chaiscript Thread_Storage<chaiscript::detail::Stack_Holder> is eating a lot of my performance
any tips on improving performance, I'm using 5.8.6 with VS 2013
Jason Turner
@lefticus
If you don't required thread safety use -DCHAISCRIPT_NO_THREADS. This will make it something like 20% faster. Also, benchmarking ChaiScript accurately is very hard, so don't assume that where your profiler is saying it's spending a lot of time, that it is.
Finally, upgrade to 6.0 and upgrade your compiler :) in all seriousness VS 2017 generates MUCH better code, and each release of chaiscript is faster than the last
and also, if you are running it inside Visual Studio's debugger - that is very slow. I've tried to minimize the impact of that, but it's slow regardless from inside the debugger. ChaiScript relies heavily on compiler optimizations
Daniel Church
@anprogrammer
I have a script. In the script there is an array of around 20 objects, each of which has an "update" method. These are objects created/written in ChaiScript, not from the C++ side
Every frame, I have some ChaiScript code which loops through the array and calls draw on each object. With a debugger attached I noticed every call was throwing multiple guard_error exceptions
ChaiScript has been slow for me so I figured, maybe it's the potentially 100 exceptions per frame or more being thrown and caught, slowing things down
I modified ChaiScript to check if a function can be called for an object-type before trying to do so (preventing the guard_errors from triggering). Got a 25-50% performance improvement for my particular use-case. Would this code be interesting for anyone, or am I approaching this from the wrong direction?
Jason Turner
@lefticus
I have actually gone many many rounds with trying to reduce the cases for when those exceptions are caught and handled internally. If you have something I've not seen before, I would love to see it
can you put it on a github fork @anprogrammer and open a pull request?
That's the best way for me to evaluate it
Daniel Church
@anprogrammer
Sure I'll do that. On a more general note, I'm guessing the (very flexible and powerful) dispatch system is a pretty big performance hug? Building a list of functions, sorting them, searching them for each call? Someday I'm considering trying to work on some sort of system which adds a map of function name to actual call on individual object instances. Cache methods on an object instance itself to skip lookup the second time you call it. Would that be a useful idea... or crazy talk?
performance hog*
Jason Turner
@lefticus
I've gone down that road already before. The cost of any caching system, that I was able to come up with ended up being more expensive than the dispatch
but yes, the dispatch is where all the hard work happens. I've also (probably because of a lack of imagination) have not come up with any kind of caching system that would not potentially break things that are currently allowed
I have debated doing a parse time resolution of the functions being dispatched. Kind of like a "compile" option. For users that don't care about the possibility that new functions with different overloads could be added later during execution
I think that's probably the option with the most potential. No cache to manage, the func_call nodes would just know if they have a fixed thing to call
Daniel Church
@anprogrammer
Good to know. I may be foolhardy and take a crack at it someday, but I can see why that would be problematic
btw, just wanted to say thank you. It's an amazing piece of software, and even more amazing the level of support you provide to end-users
Jason Turner
@lefticus
I attempt to. I have lots of travel and business right now, so I know there are a few support issues and PRs languishing
I'm glad it's working out for you
Daniel Church
@anprogrammer
Hope your business trip goes well!
Tharindu Mathew
@mackiem
@lefticus I just got some cycles to recompile chaiscript with thread support. Performance improve is at least 10x on VS 2013. It is mind blowing. I do use multi threading but I create my own instance of chai for each (maybe not the best way, but this is only for a non interactive optimization use case, so doesn't matte if it hogs memory and cpu). Making it thread safe by design.
without thread support*
I would encourage you to release without thread support, just for the perf gains
Jason Turner
@lefticus
@mackiem I don't think I'll ever make thread-unsafe the default, it's a very easy compile time option. Been there almost since the very beginning nearly 10 years ago now
but I'm glad it worked out well for you
on my systems, with my performance tests, it's only about a 20% performance difference (mostly on Linux)
Tharindu Mathew
@mackiem
so is it just compile time option? I had to recompile chaiscript to get libs and dlls.
stdlib
Jason Turner
@lefticus
Does that mean you are using the precompiled version of ChaiScript? I rarely recommend that, since it's just a header file to include
you just have to set CHAISCRIPT_NO_THREADS
Tharindu Mathew
@mackiem
Ok, I can't remember as to why I went along this path. Is 5.8.6 header only with visual studio?
2013
Jason Turner
@lefticus
Yes, it's been header only since it was first created
you can compile the stdlib separately, but you certainly don't have to
This version is out of date for 6.0.0, but correct for 5.8.6 https://gist.github.com/lefticus/9456197#file-chaiscript_compiled_in_stdlib-cpp
Tharindu Mathew
@mackiem
Ok, cool I will try it out
So, you claim that this will be even faster with VS 2017. This is very tempting. I have a bunch of legacy code I need to clean up, but I probably will give that a try.
Jason Turner
@lefticus
Yes, not my claim, claim from the VS team
each version of VS is faster than the last version. if you move to VS2015 then also upgrade to chaiscript 6, as that is significantly faster also
Tharindu Mathew
@mackiem
but native code will be faster? That's not surely possible.
Jason Turner
@lefticus
Why not? Optimizers are always getting better with every new compiler release
plus the C++ standard library is getting more and more optimized with each new compiler release
Tharindu Mathew
@mackiem
so can we optimize our way to 8K output? :)
Jason Turner
@lefticus
Well... there's probably some limit, but we aren't there yet
Tharindu Mathew
@mackiem
Like I can understand something move operaitons being optimized or tail recursion being optimized. But, there's always a limit if you try to make your code as simple as possible
Jason Turner
@lefticus
You're mostly correct, but thinking too low level
The compilers are able to better order operations and use better CPU instructions also