IRC channel logs

2020-10-18.log

back to list of logs

<fossy>OriansJ: I would be too concerned about performance rn it is sufficiently fast in 99% of cases
<OriansJ>fossy: fair
<OriansJ>I figured out an O(1) solution for the application of macros; the downside is that it is 8times slower
<OriansJ>well shit
<OriansJ>who knew hashing really cut down the processing time
<xentrac>haha
<OriansJ>it went from 8times slower to 10times faster
<OriansJ>(possibly more as 1 second is down to .1 second)
<xentrac>awesome!
<xentrac>replacing a sequential search?
<OriansJ>xentrac: yep
<OriansJ>with probably the worst hash possible
<OriansJ> https://paste.debian.net/1167637/
<OriansJ>with a 65536 entry table for 13K distinct symbols
<OriansJ>So it could probably be even faster if I can get the collision rate down
<xentrac>heh, my paper address book uses the first and third letter of people's name as the hash
<xentrac>lumped into categories: ab, cd, ef, gh, ij, etc., to fit the hash table on the page
<OriansJ>i = (i << 5)+ i + s[0]; would probably give a better spread
<xentrac>yeah but it's harder to do in my head
<OriansJ>fair
<OriansJ>I think some people however go a little too far: http://burtleburtle.net/bob/c/lookup3.c
<xentrac>you can always count on bob to go too far
<OriansJ>xentrac: did you have your meeting with the Bobs yet? ;-p
<OriansJ>for added fun converting @9 to 0009 is now done only exactly once (instead of as many times as @9 appears)
<OriansJ>and when it is built via GCC it is so fast, it doesn't even show up in htop when running the M2-Planet tests
<xentrac>haha, niice
<OriansJ>now I just need to speed up hex2
<OriansJ>and commit is up for review (I admit it is probably ugly)
<OriansJ>I'll profile hex2 tomorrow and figure out what is slow there but first sleep
<OriansJ>I spent way too much sleeptime on programming today. Good night
<xentrac>nigh
<xentrac>t
<xentrac>good job!
<OriansJ>hopefully with a speed upgrade in hex2 and a release of mescc-tools; janneke will be able to cut his bootstrap time by half
<OriansJ>oh thank god; finally after a week. guix pull and guix package -i emacs finally worked
<OriansJ>(yes I was forced to use mg to do development this week)
<OriansJ>oh tree-undo mode, org-mode and magit how I missed you
<vagrantc>couldn't you have just used an old generation?
<OriansJ>vagrantc: not on a fresh install
<OriansJ>hence my frustrations going from a fresh tarball to successfully doing a single guix pull
<OriansJ>if it wasn't for efraim's help and his missing tarballs collection; I'd still be stuck at the unable to successfully guix pull
<efraim>I gathered a couple while trying to revive the mips64el port for Guix, but the 1GB of ram on the board wasn't enough
<efraim>most of them I grabbed from bayfront
<vagrantc>ah.
<OriansJ>sadly 4GB might be too small for builds soon. (ghc really can't tolerate that little)
<OriansJ>It is weird, I remember when 8MB was alot of RAM
<efraim>the mips board has 1GB and I gave it 4GB of swap, all on an SSD. I forget if it exhausted itself compiling guix or guile, but I only made it as far as about 0.15
<OriansJ>efraim: I'd say guile probably as it really doesn't like less than 2GB of RAM for some reason
<OriansJ>possibly due to how it handles garbage collecion; resulting in rather bad page thrashing even with an SSD
<OriansJ>builds in general have gotten way less [computer resource] efficient for questionable improvments in developer efficiency
<xentrac>congratulations!
<rain1>ive been looking into SSDs
<OriansJ>rain1: they have gotten alot cheaper over the last few years but they still have a price premium over spinning disks; ironically all of the biggests disks are SSD only (100TB+ Drives) and spinning disks are now just a fraction of the size of SSDs (<20TB)
<xentrac>rain1 has left :(
<xentrac>hopefully they will reincarnate soon
***ChanServ sets mode: +o rekado