Isn't Christian Schafmeister the guy attempting to make a Common Lisp frontend to the dreaded LLVM infrastructure?
SCNR 😇 Am 3. Mai 2020 23:17:49 MESZ schrieb Guido Stepken <gstep...@gmail.com>: >Plain wrong. Christian Schafmeister will teach you the use of Lisp in >high(est) end number crunching: > >https://youtube.com/watch?v=8X69_42Mj-g > >He's the Super Brain behind all the compute stuff of that famous >Genomic >Reasearch Institute in NY (proteine folding ... Corona) ... ;-) > >In fact, he's using the AI Lisp language to compose all those mighty >C/C++ >libraries to new libraries. Means: His Lisp AI is (re-)writing >software. > >I fear, you're a decade behind of what's 'state of the art' in >programming! >Lisp, until today, is a highly important language. It also optimizes >machine code within GCC, generating highest efficient machine code for >any >CPU in the world - see MELT, a Lisp dialect: > >http://www.starynkevitch.net/Basile/gcc-melt/ > >Binding GSL (GNU Scientific Library) and magic OpenBLAS (searching >through >huge graph structures in zero time) to PicoLisp is piece of cake. > >https://picolisp.com/wiki/?interfacing > >Automated marshalling and unmarshalling C interfaces in Lisp is a >nobrainer, simply extract .c header files. Finished! > >Have fun! > >Best regards, Guido Stepken > >Am Sonntag, 3. Mai 2020 schrieb John Duncan <duncan.j...@gmail.com>: >> For heavy number crunching, picolisp might not be appropriate. In >modern >systems you would probably want something that used the vector >instructions. But if it’s a few divisions here and there, you’d be >surprised how little the efficiency in clock cycles matters anymore. >> On Sun, May 3, 2020 at 14:28 Wilhelm Fitzpatrick <raf...@well.com> >wrote: >>> >>> >> I'm not finding such a thing in the function reference, but >asking on >the off chance I'm >>> >> overlooking it. Is there a way in Picolisp to get a division >result >and remainder as a single >>> >> operation? >>> > Sure >>> > http://ix.io/2kBM >>> >>> Thanks! But as Alex intuited, I was looking to leverage the >underlying >>> processor operation that returns both parts of the integer divide in >a >>> single operation. But if I follow his response correctly, the cost >of >>> building the memory representation of the answer swamps the actual >cost >>> of the divide, and that's going to be similar regardless of if the >>> divide and remainder wind up being one machine instruction or two. >>> >>> -wilhelm >>> >>> >>> >>> -- >>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >> -- >> John Duncan -- You have zero privacy anyway. Get over it. Scott McNealy 1999
