Subscribe
Hello Steven Perry :-) You are now subscribed Subscribe Please subscribe me to the PicoLisp mailing list. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: slow nth
hi, would you mind sharing the performance improvement you achieved using a better suited data structure (tree vs linked list) on your machine once you fully implemented the SBOXES for both cyphers? On my machine (2010 netbook with Intel Atom core using PIL version (3 1 8 0)) i get the following numbers from bench: 8.627 sec '(nth) 5.331 sec '(lup) freeemint_ 2016-10-01 14:41 GMT+02:00 Mike Pechkin : > hi, > > Current implementation of bcrypt is slow (8 rounds == >4secs). > Its ok, nth is not for free. > o) blowfish encrypt one block of input data takes 32K nth calls. > o) 8 round's bcrypt takes 16M nth calls. > > I will try re-implement blowfish's sboxes access and modifications via > balance+lup > Check this out: > http://pastebin.com/SQ6FtdCx > > Note: balance+lup gives more profit under pil64 on the same hardware. > > Mike > >
slow nth
hi, Current implementation of bcrypt is slow (8 rounds == >4secs). Its ok, nth is not for free. o) blowfish encrypt one block of input data takes 32K nth calls. o) 8 round's bcrypt takes 16M nth calls. I will try re-implement blowfish's sboxes access and modifications via balance+lup Check this out: http://pastebin.com/SQ6FtdCx Note: balance+lup gives more profit under pil64 on the same hardware. Mike
Unsubscribe
Re: Unexpected behaviour from (sort) with
Hi Rowan, > first sentence at http://www.software-lab.de/doc/refS.html#sort > changed from: > > > Sorts lst by destructively exchanging its elements. > > to something more explicit like: > > > Returns a sorted lst by destructively exchanging the original lst's > > elements. Good idea! Thanks! Done :) > guess there may be other "destructive but not in-place" functions > whose documentation this suggestion could be relevant to as well. Of Yes. 'flip' is such a typical case: : (setq L (1 2 3 4)) -> (1 2 3 4) : (flip L) -> (4 3 2 1) : L -> (1) # Oops However, the ref of 'flip' is already as you suggest. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Unexpected behaviour from (sort) with
On 30 September 2016 at 20:24, Alexander Burger wrote:
> Hi Rowan,
>
> the explanation is simple.
> ...
> It is the *return* value of 'sort' which is relevant:
> ...
Ah, [facepalm], thanks. Because I hadn't used picolisp for a while,
when I first used (sort) again in a new context I saw the altered (but
not NIL) initial ("A") value before paying attention to the
return-value, and was so convinced that it must be the meaningful part
- and that (sort) must be "destructive and in-place" - that I never
even looked at sort's return-value (or noticed that the documentation
shows its return-values). Ironically picolisp code of mine from 2
years ago uses it correctly [sigh]. I suggest it might be more useful
for newcomers, for people-with-terrible-memory, and for
people-who-have-to-do-too-much-context-switching (like me) if the
first sentence at http://www.software-lab.de/doc/refS.html#sort
changed from:
> Sorts lst by destructively exchanging its elements.
to something more explicit like:
> Returns a sorted lst by destructively exchanging the original lst's elements.
I realise the examples implicitly show the "returns..." part of this,
but it is easy to get distracted from that by the initial "lst" being
transformed (but not NIL-ed) in such initially surprising ways. I
guess there may be other "destructive but not in-place" functions
whose documentation this suggestion could be relevant to as well. Of
course you might feel that is being too verbose in order to pander to
the n00bs and the forgetful though...
--
Rowan Thorpe
PGP fingerprint:
BB0A 0787 C0EE BDD8 7F97 3D30 49F2 13A5 265D CCBD
"A riot is the language of the unheard." - Dr. Martin Luther King
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
"Ignorance requires no apologies when it presents questions
rather than assertions." - Michael Sierchio (OpenSSL mailing list)
"What we need more than an end to wars is an end to the
beginning of all wars." - Franklin Roosevelt
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
