IRC channel logs
2026-06-14.log
back to list of logs
<old>probie: for 128-bit that can be difficult <old>maybe with bytevectors <old>otherwise, if 124-bit is fine, two fixnum (64-bit machines) <probie>old: I rounded up; technically I only need 121 bits (11x11 board), so two fixnums might work <old>you would need more on 32-bit <old>but using fixum would at least avoid many allocations <probie>Are there 32-bit machines still around? Realistically I'm only going to be targeting x86_64 and aarch64. I guess wasm is technically 32-bit, since it supports 64-bit operations natively, I'm not sure what hoot does <probie>s/since it supports/but since it supports/ <JohnCowan>32 bits is dead, except for armv7; you lirerally cannot buy any 33-bit stuff any more <rlb>also x86 when trying to run "old binary-only programs"...? <dsmith>Ya, 32bit is dead, except for all the old hardware I still have running... <dsmith>Hmm. Now that I think about it, that's all arm stuff. <dsmith>I've got a 32bit mac mini I was planning on resurrecting some day... <sneek>I've been faithfully serving for one month and 3 days <sneek>This system has been up 4 weeks, 5 days, 11 hours, 15 minutes <sneek>Sneeky bot running on Guile version 3.0.3 using bobot++ release.2.3.1-6-a463-dirty <sneek>Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux <rlb>After (define-module (foo) #:use-module ((guile) #:hide (make-bitvector))) make-bitvector is still bound. Is that expected? <saravia>why a script with guile and sqlite over internet costs more work then gccgo sqlite the same work with gccgo and sqlite is more efficient <ieure>saravia, Do you have some benchmarks or something? I'm not sure I understand what you mean by "sqlite over the internet," SQLite is usually only used on one machine. <saravia>for example a “CRUD” of users, with gccgo you can have more use with the same machine <identity>you are asking why a static binary runs faster than a virtual machine interpreter with a JIT compiler? <saravia>I'm wondering why a GUILE binary is not optimal... why a GCCGO binary is more efficient <identity>Guile does not make «binaries», it creates byte code <mwette>the guile compiler does not generate machine code like gccgo does; it generates custom instructions to run on a "synthetic" CPU <sham1>Fairly sure Guile does also compile to native machine code with the Lightening stuff, doing it just-in-time <saravia>Should I try the same test with native compilation? <sham1>You'll probably need to have the system warm up before taking benchmarks <rlb>sham1: sure, depends on whether we're comparing what's on disk, or what's actually executed. <rlb>saravia: yes, in large part so you don't have to handle "all architectures"; and then guile's (newer) template jit can handle *some* platforms for some things. <saravia>sham1: interesting, you say... GUILE with time work better? <saravia>rlb, sham1 why do you use GUILE and not GCCGO? Maybe there's something I'm not seeing <rlb>As yet, I've not been particularly interested in go, and at the moment, I'd likely choose a number of other languages over go if performance were the main goal, and depending what the other constraints for the project were. <saravia>rlb: e.g. I'm looking for a good license like gccgo, sqlite or guile but also faster functionality because I'm starting with small machines <old>tell me if this fix your problem <saravia>I want to create API CRUD RESTful systems and I find gccgo works better than guile for optimal and faster <sham1>I mean, comparing guile scheme and go is like comparing an apple to a bicycle <rlb>Could be go is a better fit for your constraints. <sham1>Yeah, I don't know what the idea here is. Like, go code compiled with gccgo fits the specified constrains better than guile scheme. Okay? Like, unless the idea is to think about how to make the guile runtime more efficient for microservice workloads or whatever, I really don't see what this is about <sham1>Well, microservices and/or "lambdas"/"serverless" <saravia>And in which case is Guile a good candidate? <saravia>Because Microservice is not a good job by Guile <rlb>...as an example of my personal selections, and depending on what you mean by microservice I suspect I'd pick (optimized) clojure on the jvm all day long over go, but that's making a lot of assumptions about what I've heard about go, not based on personal experience with go. <sham1>Eh, I wouldn't say that. Guile should be just fine for the vast majority of microservices, since for them the startup latency or "inefficiency" shouldn't matter anyway. The only place where that _might_ be a problem is the aforementioned "serveless functions" and even then, people do those with languages like Python (using CPython) so clearly Guile should be just fine <old>Guile is fun to write, I can't say the same for go