freenode/#clasp - IRC Chatlog
Search
1:57:32
drmeister
Loading and compiling foundation.lsp with the JIT - with no llvm optimization is 1.039 seconds
2:04:37
drmeister
At 0 - there is no inlining and no other optimization - just native code generation.
2:39:09
drmeister
I compile-file 69 source files with optimization level 3 using code compiled at optimization level 3 -->
3:00:03
drmeister
I'm going to try a different trade-off. Knock *optimization-level* to 0 and build everything.
3:10:10
drmeister
I might be able to do inlining in a different way - more deliberate inlining at call sites.
3:10:50
drmeister
But still - we are balanced right now with the bclasp compiler - where the it takes about half the compilation budget and llvm takes the other half.
3:12:44
drmeister
I figure if I compile everything with *optimization-level* 0 and then compile-file the 69 source files at optimization level 3 (as above) - that will be a decent comparison of optimized code vs unoptimized code.
3:53:48
beach
karlosz: &key processing, if performance critical, could be done with a compiler macro.
3:54:24
karlosz
beach: can that be done for local functions too? this is in the context of inlining local functions
3:55:32
beach
karlosz: I don't expect many local functions to 1. be performance critical and 2. to have keyword arguments.
6:28:16
Colleen
kpoeck: attile_lendvai said 8 hours, 7 minutes ago: do you mean the changes that are already checked in the repo? if yes, then of course, that'd be a major offense... :) if you mean changes that are not in dev, then do warn me
10:02:14
Colleen
attila_lendvai: drmeister said at 2018.07.05 02:44:52: I'd rather keep it - C++ code size isn't really an issue and faster is better in my eyes.
10:02:14
Colleen
attila_lendvai: frgo said at 2018.07.08 17:28:56: I would like to align with you on how we define a protocol for integrating extensions into the build process automatically.