On 09/21/2014 02:37 PM, Thorsten Glaser wrote:
Lorenzo dixit:
On 09/20/2014 07:14 PM, Thorsten Glaser wrote:
appears good enough for implementing it myself, and it may be
possible even to implement it in constant-time which is important
Hm, or maybe not. Also, the algorithm is extremely slow as is
already, and since MirBSD caters to the low-end machines, like
my 80486SLC-25 and my by now seven (I got another) SPARCstations…
Wait, wait - 1. MirBSD? 2. what did you measure exactly?
1. MirBSD (I had to google 80486SLC-25 :)
Are you considering RS14 for /dev/random?
Making a portable arc4random() based on RS14 should be more than good
enough for the portable version of mksh, even in terms of speed - or did
you stop using arc4random() for $RANDOM because of this slow machines?
2. Speed
I used this script
# test $RANDOM speed
if [ x"$N" = x ] ; then N=$((1000*1000)) ; fi
echo "N = $N..."
while [ $N -gt 0 ] ; do
N=$(($N - 4))
: $RANDOM $RANDOM $RANDOM $RANDOM
done
# RESULT:
# < 7% time increase with rndget() => repeat 123 times original_rndget()
# Spritz-RC4 is NOT 123x slower than an LCG!
# Fwiw: bash is significantly slower than mksh, but zsh is faster than mksh
Ie slowing down rndget() by a factor X has an impact which is much
smaller than X due to the shell having to parse over and over, not to
mention that in real usage you'd actually be doing something other than
generating random numbers...
I'd expect the rc4/rs14 speed ratio to be more or less the same on my
computer or on your 486, since the size of the state is very similar and
it only uses byte operations - am I missing something? Too few registers
on 486?
<OT>
I quit toying with archlinux when updating to linux3.0 broke my p3
coppermine, as in, it couldn't boot and (unlike debian) there was no
older version installed.
Downgraded via livecd, and waited a few kernel upgrades (break,
curse,downgrade again) to see if anyone else would notice. Nope.
</OT>
… but then, if Spritz is really that good, I could greatly
simplify the arc4random design with its several separate pools
and all that, which would remove some of the speed overhead.
(For example, we generate 5½ bytes of entropy to read a 4-byte
quantity, all the time, which reduces speed to about ⅔ anyway.)
Its 1732 bit state beats the about 1700 bit of aRC4, too ;)
although that is due to the increase in registers.
And some of it is lost due to the CRUSH function, at least
possibly, but I think it doesn’t affect use of it as an SRNG.
Glad to hear it :)
Right ☺ No promise as to when I get around looking at it more;
there are massively more important things to do, and I’m spread
enough as is. But I’ve cached the PDFs and the bib.txt locally.
bye,
//mirabilos
