* master:
vere: bump version to 0.10.7
libsigsegv: disable stack vma check
vere: bump version to 0.10.6
ci: add travis as trusted user
jets: use appropriate macro
noun: add -C to control memo cache size
jets: restore fond/play/peek hooks
jam: add commented-out functionality to count size of atom
jets: cap memo cache and remove peek, play, and fond jets
noun: add functions to count size of noun
This patches libsigsegv to not check the stack vma on Linux, since that
involves reading procfs, and we make very heavy use of sigsegv. This
eliminates most of urbit's performance discrepancy between Linux and
MacOS. These are the benchmarks used; note this is a local MBP vs a
cloud Linux server, and the MBP is almost certainly faster hardware.
We take two benchmarks, one of which decrements 10 million times and the
other simply allocates 125MB of memory. These are the results:
cpu-heavy == =/ n 10.000.000 |-(?~(n n $(n (dec n))))
mem-heavy == =a (bex 1.000.000.008)
macos, cpu-heavy: 6 seconds
macos, mem-heavy: 1 second
linux-before, cpu-heavy: 30 seconds
linux-before, mem-heavy: 160 seconds
linux-after, cpu-heavy 9 seconds
linux-after, mem-heavy 1.3 seconds
This represents a 3x speedup for the cpu-heavy operation and a 120x
speedup for the memory-heavy operation.
This check was used to try to distinguish stack overflow from other
forms of segmentation fault. In the comments in src/handler-unix.c, it
describes three heuristics it uses, depending on what's available from
the OS. In the linux-i386 case, all three are availble, so we simply
disable the slow one. This correctly recognizes stack overflow if you
simply alloca(10000000000).
* philip/mem:
vere: bump version to 0.10.6
ci: add travis as trusted user
jets: use appropriate macro
noun: add -C to control memo cache size
jets: restore fond/play/peek hooks
jam: add commented-out functionality to count size of atom
jets: cap memo cache and remove peek, play, and fond jets
noun: add functions to count size of noun
Signed-off-by: Philip Monk <phil@pcmonk.me>
The component for editing a post was tied up in checking for API
instantiation -- we want the check for a blank body to be independent
of that.
Fixes#3040.
This is a convenient way to count memory usage of noun by simplying
running `(jam 1.337 noun-1 noun-2 ... ~)`. This should
be a hint, but for debugging this is sufficient.
With these changes, about 90% less memory and 15% less time is needed to
compile hoon.hoon. The produced noun is within 3% of the same size,
which suggests this results in little if any duplication.
These are three of the four most commonly hit +ut jets. The other is
+nest, which cannot be un-memoized without taking much longer to compile
(it didn't finish in my test). These four jets combined for 2.3 million
out of the 2.4 million cache entries, the other +ut jets combine for
less than 100k, and literal ~+ accounted for about 50k entries.
This also caps the memo cache at 50k entries. Even with these jets not
memoized, the memo cache grows to 357k entries and 122 MB. Capping at
50k entries has no effect on time and reduces memory usage of the hash
table to about 25MB. Entries are reclaimed with the clock algorithm,
which seems to be sufficient for this use.
Adds a few functions to count the size of nouns in the current road.
Since this marks the nouns (high bit of refcount), you need to
"discount" them immediately after to unmark them. Parallel functions
exist for the counting the size of a hashtable.
It would nice to hook this up to a hint, but these are useful to have
available to run in the debugger or by inserting callsites as necessary.
It's also possible to hook them up to the +jam jet gated on a special
value.
