« first day (834 days earlier)      last day (701 days later) » 

3:14 PM
Yes, amend is way faster. Thanks for the tip. Primes < 200000:

\t (0<)#&1<{@[@[x;&n#~!p;1];p:*&~x;2]}/:2>!n:200000
1716

\t (0<)#&1<{x|(p=!n)+n#~!p:*&~x}/:2>!n:200000
7079
 
ngn
3:28 PM
@jordancurve hm, that still looks slow
 
this is extremely weird, ngn/k for me is extremely slow, 900+ms for just 1+1
seems like there's a constant 800ms or so
 
ngn
@rak1507 it's instant for me. what compiler do you use and what version?
 
oh, not locally, the web editor
 
ngn
that too is almost instant for me
 
strange
at least the repl is instant
 
ngn
3:36 PM
the timings it reports in the upper left corner are a bit strange though - randomly ranging from 2ms to 200ms
 
the timings are definitely right because I can feel the latency
 
ngn
@ngn s/upper left/upper right/
@rak1507 what browser do you use?
 
firefox
 
ngn
same here
 
ok, that's really weird, I just spammed some stuff a few times and then it dropped from ~500ms to ~3ms, so seems to work now
nope, back to slow speed...
firefox just crashed lmao I think something might just be wrong with my laptop
 
ngn
3:52 PM
@jordancurve does k9 optimize *&~x? maybe something involving x?0 would be faster?
&n#~!p is another candidate for easy optimization
&n#~!p <-> p*!1+_(n-1)%p
@rak1507 i've had that happen to me because of plugin autoupdates
who knows what they're doing.. might be mining crypto coins or something
 
 
1 hour later…
ngn
5:20 PM
@ktye @dzaima fyi, i made some experiments with grading algorithms on modern hardware: c stdlib is slow (300+ ms, including its mergesort impl), hand-written pure mergesort is fast (200ms, the half-copying variety brings no measurable benefits), radix sort is crazy fast (100ms)
 
well, that was strange, but it all seems fine now
@ngn it's weird to me that the standard library would be slower than a hand written thing, is it not at all optimised?
 
ngn
@rak1507 idk. this is what i measure.
 
@rak1507 things in the C standard library are lacking in many aspects
 
ngn
tbf, stdlib has the disadvantage of having to call a non-inlined cmp() function, but even when i changed my own code to do the same, stdlib was still slower
(all timings i mentioned above are for grading 10^7 pseudo-random 64bit ints)
 
5:42 PM
probably worth testing other sets of data - !1000000, reversed that, almost-sorted, smaller ranges, many/all duplicates, etc
 
 
1 hour later…
7:00 PM
the design of the c stdlib qsort() is really a pain in the ass, since there's no way to inject context into the comparator function except globals
if you're doing anything other than sorting an array of values the api is simply inadequate
 
ngn
7:12 PM
@JohnE see qsort_r()
 
that's a gnu extension, though
 
 
4 hours later…
11:40 PM
should be fairly self explanatory
 

« first day (834 days earlier)      last day (701 days later) »