libera/#sbcl - IRC Chatlog
Search
17:35:04
z0ltan
Hello folks, running sbcl 2.1.9 (locally built) on macOS 10.14 (Mojave). Invoking `sbcl` on the terminal takes almost 30 seconds to load (used to be a couple of seconds some time back). Is this a known thing, or is there something I can check locally?
17:47:06
mishugana
Hello folks, using SBCL 2.1.9.83-c0a8e0749 on macOS Mojave (10.14). Starting sbcl on the terminal takes around 15-20 seconds now (used to take just a couple before, last tested around a year back). Is this a known issue, or is there something I can test out locally? Anybody else face the same issue?
17:49:00
mishugana
yitzi: Yes, quicklisp is included. Also, thanks for the compliment - shows my state of mind of late :D
17:49:33
mishugana
This also probably (maybe?) explains why loading SLIME takes around 5-10 seconds.
17:51:13
yitzi
No idea. I know it takes a while, but I am not on a Mac so haven't got a clue there. Maybe check to make sure the quicklisp client and library is updated?
17:51:58
mishugana
yitzi: I could try that out. This alone helps out massively though, so thank you so much! :-)
21:12:18
stassats
i barely see any difference between not calling anything and tail calling on M1, but a normal call is really slow
21:12:33
stassats
similar things on x86-64, although i do see a difference between not calling and tail-call
22:36:14
john-a-carroll
stassats: thanks for looking at function calls on M1! A little while ago I tried the tak benchmark and was surprised that M1 was slower than x86-64. (However I thought nothing further of it when I found that the M1 version of my system ran so much faster overall)
22:40:26
stassats
although x86-64 uses the same calling convention as C, surely it should be able to
22:43:42
john-a-carroll
this was in one of the first m1 releases: 2.1.5 comparing the m1 native version to x86_64 under Rosetta 2. (time (dotimes (n 10000) (tak 18 12 6))) -> 2.4 secs in emulated x86_64, 4.7 seconds in native m1
22:53:23
john-a-carroll
looks good. I'm still with 2.1.5, and for my system's main benchmark the figures are rosetta 16m46s, m1 15m24s
1:10:48
stassats
loading and storing the same register on the stack in quick succession doesn't seem to be great
1:11:17
stassats
i guess there's no way around that, except for making leaf functions not touch the stack
1:26:35
stassats
i mean, with different out of order paths it's always difficult, but here the call/return/save the iteration variable just dominate the computation being measured