ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
_whitelogger has joined #picolisp
tankf33der has quit [Ping timeout: 240 seconds]
root__ has quit [Ping timeout: 240 seconds]
root__ has joined #picolisp
tankf33der has joined #picolisp
ym has joined #picolisp
ym has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 256 seconds]
<Regenaxer> tankf33der, you *did* make some speed comparisons, no?
rob_w has joined #picolisp
<tankf33der> morning
<tankf33der> what operation you would like to benchmark ?
<tankf33der> also post email to ML several hours ago, dont see it.
<Regenaxer> Good morning tankf33der!
<Regenaxer> I see the mail
<Regenaxer> that's why I asked
<Regenaxer> + - * and / would be interesting
<tankf33der> ok
<Regenaxer> What might have happened with the mail?
<beneroth> I got the email
<Regenaxer> good
<Regenaxer> It is frustrating that e-mail is so unreliable
<beneroth> email isn't. spamfilters are.
<beneroth> it is a non-technical problem.
<Regenaxer> Yes. But I'm now experimenting with Element/Matrix (matrix.org) to perhaps replace Delta Chat
<beneroth> ok.
<Regenaxer> cause Delta has the same problems
<beneroth> you see chat messages lost in delta (because of email transport) ?
<Regenaxer> not me, but friends
<Regenaxer> lost or delayed a lot
<Regenaxer> Matrix looks promising
<beneroth> I would say it depends on the mail infrastructure involved. so mostly by the email of the receiver, sometime sender.
<Regenaxer> right
<beneroth> but it is a big mess and often the people who could solve it have zero incentive to do so.
<Regenaxer> too bad
casaca has quit [Ping timeout: 272 seconds]
orivej has joined #picolisp
_whitelogger has joined #picolisp
<tankf33der> Did not get email and mail-archive site too
<Regenaxer> yes, indeed
<Regenaxer> Could it be one of the links in the mail?
<Regenaxer> What if you send a test mail without any embedded link?
<Regenaxer> tankf33der, now I "bounced" your mail back to the list. Let's see if it gets through
<tankf33der> What if you send a test mail to you or to the list ?
<tankf33der> thinking how would be better to do math benchmarking.
<Regenaxer> Hmm, my bounced mail also got lost
<Regenaxer> So it must be something *in* the mail
<Regenaxer> For example, I know that some mails with log files to me get lost if they contain malicious links
<Regenaxer> SIGH
<Regenaxer> I hate it
<Regenaxer> Your next mail arrived
<Regenaxer> or is it the one I bounced?
<Regenaxer> yes, so the bounce worked, but it is again not in the archive :(
<beneroth> probably removed in the incoming spamfilter of the archive :/
<beneroth> the inherent problem with Spam is, it is subjective. cannot be automated really, and most spamfilters are stupid beyond believe
<beneroth> I've sometimes the problem that clients want to send/forward me a spam mail, on purpose to talk about it... in such an instance the email is not spam even if it looks like one
<beneroth> spam emails try too look as close to a legitimate email (esp. newsletter) as possible, naturally
<beneroth> we should do our own archive. :/
<Regenaxer> This also would not make tankf33der (and others perhaps) receive the messages
<tankf33der> it was the same like this:
<tankf33der> TXT mail but without links.
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
rob_w has quit [Remote host closed the connection]
<tankf33der> Benchmarking on real modern hardware server
<Regenaxer> Yeah, I would expect so
<Regenaxer> GMP is optimized for speed
<Regenaxer> and Pil uses linked lists for bignums
<Regenaxer> triggering garbage collection etc., while GMP probably allocates big memory ranges
<tankf33der> picolisp process is not growing itself.
<Regenaxer> yes, cause gc runs
<tankf33der> let me try (gc 128) then
<Regenaxer> So a factor of 10 in speed increase is ok
<Regenaxer> A bigger total heap will not change much
<Regenaxer> only in the beginning until the max size is reached
<Regenaxer> Total collection is the same, i.e. less often but bigger heaq
<Regenaxer> (gc 128) helps a lot if the memory is allocated in the beginning slowly, for example by a monotoneously growing list
<Regenaxer> The bignums are not so big, but created and deleted very often
<Regenaxer> I think the Pil bignums are optimal for their purpose, in the interpreted environment
<Regenaxer> Speeding them up would not improve total program speed very much for a typical program
<tankf33der> With correct heap
<Regenaxer> yeah, not much faster
<Regenaxer> How much heap is needed?
<tankf33der> on real hardware difference is small but on vmware and heap pc performance boost 50%
<tankf33der> Just + several MB
<Regenaxer> ok
<tankf33der> i put (gc 8)
<Regenaxer> good
<Regenaxer> should be enough
<tankf33der> sure
<tankf33der> after all run pil shows 3 in (heap) call
<Regenaxer> so about 1 MiB needed
<Regenaxer> or 2
<Regenaxer> Very good to know
<Regenaxer> And if *really* fast bignums are needed, GMP can be recommended now
<Regenaxer> Which function in libgmp.l can be used for conversion?
<Regenaxer> mpz_set ?
<Regenaxer> or via strings?
<tankf33der> conversion to what ?
<Regenaxer> PicoLisp bignums <-> GMP
<beneroth> I agree with you, Regenaxer. PicoLisp bignums are fine for what they are meant. PicoLisp is not meant for big efficient number crunching. I'd say picolisp is ideal to maybe prototype such tasks, and do metadata management, the pure computing can be left to other software optimizes for that, via native etc.
<beneroth> all other languages with sane implementations to the same thing, technically. most python libs are just C++ libs. the only difference is that picolisp is more transparent and gives more control - but sometimes is lacking ready-made wrappers
<beneroth> which tankf33der is changing :)
<tankf33der> mpz_set_str and mpz_set_ui
<tankf33der> mpz_get_str
<Regenaxer> beneroth, right, so gmp isdexcellent for that
<Regenaxer> tankf33der, yes, so numbers are passed via format -> mpz_*_str
<Regenaxer> A direct pass would be nice though
<Regenaxer> eg accessing the bignum cells with 'adr', extracting the binary data, and convert them with bit operations
<Regenaxer> 'format' is expensive as it does a decimal conversion
ym has joined #picolisp
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
Seteeri has joined #picolisp
<Seteeri> good news! I have picolisp running bare metal on raspberry pi 4 (arm64 aka ARMv8/AArch64) :)
<Seteeri> zx
Seteeri has quit [Remote host closed the connection]
Seteeri has joined #picolisp
<Regenaxer> Congratulation Seteeri!
<Regenaxer> bare metal, no Raspian?
<Seteeri> no OS
<Regenaxer> cool
<Seteeri> I had to setup the MMU
<Seteeri> then the rest worked
<Regenaxer> all pil21? or pil64?
<Seteeri> setting up the pagetables is a lot more flexible than x86 so it takes more configuration
<Seteeri> all pil21
<Regenaxer> great!
<Seteeri> the older pi's are 32-bit but hooking up pil32 can be done in an afternoon ;)
<Seteeri> however I still need to finish the memory allocation for coroutines
<Seteeri> and external symbols won't work since I need to write the driver for the sd card
<Seteeri> the rpi 4 has either 4 GB or 8 GB of ram; I have both but so far I've been testing on the 4GB, the 8GB should work the same
<beneroth> awesome!
<beneroth> very cool project
<Regenaxer> hehe, yes, pil32
<beneroth> :D
<Seteeri> what's cool is I can optimize the virtual memory for the interpreter
<Regenaxer> Optimize in which way?
<Seteeri> disregard my last statement haha, I was thinking there's less layers/overhead which means running pure lisp should be just as fast
<Seteeri> I'm using 64kb granule since less translations
<Seteeri> arm also has some support for pointer tagging I think using the upper bits of the VA
<Seteeri> there's also a paper on it: Type Information Elimination from Objects on Architectures with Tagged Pointers Support
ym has quit [Ping timeout: 240 seconds]
casaca has quit [Ping timeout: 246 seconds]
Seteeri has quit [Ping timeout: 272 seconds]
casaca has joined #picolisp
orivej has quit [Ping timeout: 272 seconds]