clasp icon indicating copy to clipboard operation
clasp copied to clipboard

Performance - inquiry

Open mdbergmann opened this issue 4 years ago • 12 comments

Hi.

I've recently (last week or so) built clasp on macOS. I've noticed that startup is very slow and general performance even compared to CCL is slow as well.

So I was wondering whether the built I made is a debug version or so. Is there a way to tweak the performance of clasp?

mdbergmann avatar Dec 05 '20 12:12 mdbergmann

See https://github.com/clasp-developers/clasp/wiki/Relative-Compile-Performance-of-clasp

In summary:

  • compile time performance of clasp is much worse that ccl (factor 20)
  • compile time performance is getting a lot better (used to be way slower)
  • runtime performances varies, see the gabriel benchmarks

kpoeck avatar Dec 05 '20 13:12 kpoeck

OK, thanks. Can you tell what is the expectation, or what is the goal for clasp to reach for compile time and runtime performance? Since Clasp inherits from ECL I'm assuming that runtime performance will be that of ECL, or maybe a bit faster?

mdbergmann avatar Dec 05 '20 15:12 mdbergmann

Code generation is totally different from ECL.

The expectation is that generated code is quicker than ecl. If you look at the table I mentioned in the wiki (clasp is at the right), you see that this sometimes is the case, but in the majority of cases ecl is still quicker.

kpoeck avatar Dec 05 '20 15:12 kpoeck

Thank you for the info.

mdbergmann avatar Dec 05 '20 15:12 mdbergmann

mdbergmann - Hi Christian Schafmeister here (lead designer). Clasp is very different from ECL in terms of how it generates code. Clasp uses the llvm C++ API directly and generates LLVM-IR and does just-in-time compilation as well as ahead of time compilation. ECL generate C code that is then compiled by the clang compiler and that uses the same llvm library we do. The goal for clasp is to get the best runtime performance we can - better than ECL and then SBCL. The goal for clasp compile time is to approach ECL. Both ECL and Clasp ultimately run through the llvm library and so it's unlikely that we can do better because llvm will become the bottleneck.

drmeister avatar Dec 07 '20 17:12 drmeister

I also just noticed that kpoeck's compilation timings are not using the parallel compiler. By using the parallel compiler (the default) compilation can be sped up by 1.5 to 3 fold. Comment out USE_COMPILE_FILE_PARALLEL=False

drmeister avatar Dec 07 '20 17:12 drmeister

Thank you @drmeister I think the USE_COMPILE_FILE_PARALLEL is already enabled for osx/darwin.

mdbergmann avatar Dec 09 '20 16:12 mdbergmann

I documented it wrong ib the wiki page, is now fixed

kpoeck avatar Dec 09 '20 20:12 kpoeck

FWIW, I had to use this config:

#LLVM_CONFIG_BINARY = '/usr/local/Cellar/llvm/9.0.1/bin/llvm-config'                                                                                                                
PREFIX = '/opt/clasp/'
# set this to false if you have less than 16 GB of RAM                                                                                                                              
USE_PARALLEL_BUILD = True
USE_BUILD_FORK_REDIRECT_OUTPUT = False
#CLASP_BUILD_MODE = 'object'                                                                                                                                                        
USE_COMPILE_FILE_PARALLEL = True
REQUIRE_LIBFFI = True
CPPFLAGS = [ "-Wno-nullability-completeness"]

It seems 'configure' figures out by itself where llvm is. CLASP_BUILD_MODE = 'object' didn't work here on macOS Big Sur.

mdbergmann avatar Dec 10 '20 07:12 mdbergmann

I have not experienced that configure figures out where llvm is, but am glad that it works for you. I don't have bigSur yet, perhaps its different there.

I honestly believe you don't need USE_BUILD_FORK_REDIRECT_OUTPUT = False.

kpoeck avatar Dec 10 '20 19:12 kpoeck

That is possible. I took the the example config from the wiki and adapted until it did build.

mdbergmann avatar Dec 11 '20 07:12 mdbergmann

my own fault :-) I fixed the wiki entry now

kpoeck avatar Dec 11 '20 18:12 kpoeck