freenode/#clasp - IRC Chatlog
Search
22:11:52
drmeister
The allinone build generated a .o file - so it works - but it's a lot less relevant now that we are looking towards dumping image files.
22:20:24
attile_lendvai
::notify kpoeck 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
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