freenode/#clasp - IRC Chatlog
Search
14:39:09
drmeister
Martin: I'm getting a 2.5-3.7x speed improvement with the new parallel compiler. But there are problems.
14:39:48
drmeister
I'm using the LLVM ORCV2 in a way that the ORCV2 designers didn't intend and it doesn't work on linux at the moment.
16:37:21
cracauer
I check exception handling. Throwing an exception is 150 x slower than not throwing it.
16:38:23
cracauer
Although, there is a difference here in that OSX and FreeBSD have llvm as the default compiler, Linux has gcc.
16:39:08
cracauer
(not that throwing exceptions in gcc is flower than in clang, but this is a real difference)
16:44:19
drmeister
Ok, I see. 16min26sec for aboehm, 3min28sec for bboehm and 1hour 41min 19sec for cboehm.
17:20:27
drmeister
cracauer: Are you able to get a clasp up on macOS and linux at the same time and time some code?
17:32:09
drmeister
What we are looking at is bclasp running cclasp and compiling cclasp - so the runtime is bclasp and it relies on non-local exits a lot more than cclasp does I believe.
17:32:59
drmeister
We might be able to track down what non-local exits are causing the problem and rearrange the code to avoid them.
18:22:03
drmeister
I need to start getting ready for guests to arrive so I'm going to core dump some stuff that I've been working on.
18:24:26
drmeister
To materialize an object file - you need to look up a symbol. I've thought that was a huge problem but it turns out that we can in memory create multiple JITDylib's and associate object files with them. As long as the symbols are unique to a single JITDylib - everything is ok.
18:25:03
drmeister
So I think we will generate a StartUpXXX symbol in every object file and increment XXX across the object files that belong to a single JITDylib.
18:25:47
drmeister
It's like linking at compile time - but instead we load and link together the object files at runtime.
18:26:26
drmeister
Each source file will generate multiple object files and they will ultimately generate one JITDylib in memory.
18:27:34
drmeister
I have code to get function symbols and addresses from the object files once they are linked and to get stackmaps so that we can get arguments in backtraces.
18:28:36
drmeister
Jumping to source needs more work. The info will come with the object file - but currently we call out to llvm-dwarfdump and it expects a linked library on disk to be able to figure out source positions. We need to switch this to using the object files.
18:29:21
drmeister
There is an API for this in LLVM that llvm-dwarfdump uses and we need to look at the source code for llvm-dwarfdump to figure out how to use it to interogate our object files in memory.
18:30:38
drmeister
If we get all this to work then we can eliminate compile time linking except we will want to keep it around for LTO.
18:39:10
cracauer
cclasp" If bclasp is compiled with "cc" or "gcc" on Linux and with "cc" on OSX and FreeBSD that would be a good explanation.
18:47:38
drmeister
Come up with a benchmark that doesn't depend on non-local exits. Like getting the length of a long list.
18:50:08
drmeister
You need to specify what the symbol name will look like for FreeBSD. I can't keep straight who has an underscore prefix and who doesn't
18:54:01
cracauer
I can also boot the machines into each other's OSes. But of course not while they are building.
20:05:18
cracauer
I could never figure out whether these build hangs are caused by a different error that is in the debugger or tries to get into the debugger, or whether the hangs are a build system problem.
20:11:45
cracauer
for the nonlocal exit benchmark above FreeBSD is 6x slower than linux on comparable-ish hardware. I don't think this causes the linux slowness.
20:13:26
cracauer
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1444: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled.