178500+ entries in 0.109s
mircea_popescu: vpatches seem historically
to go about 512 - 65535 bytes or so
mircea_popescu: asciilifeform useful for different
things. apparently all of modern computing comes
to "adjust your expectations". what do you need 1gb codebases for ?
mircea_popescu: asciilifeform i can't really visually saw
that appart, but looks like it's a hlen ** b mlen or such.
mircea_popescu: kinda badly chosen cutoffs
too, i don't specifically care re diff between 40 byte and 70 byte message. make it log on
that side and do 16, 128, 1024, 8192 and 65536 byte messages, for 32, 256, 2048 bit hash lengths as a standard of
testing.
mircea_popescu: but other
than
that, looks like exponential on mlen and perhaps linear on hlen ?
mircea_popescu:
http://btcbase.org/log/2017-07-02#1678479 <<
to my eye
the worst part of it is
that it's very badly drawn. a) about half of
the Y space is actually used, which is
terrible. b) all
the same color,
they melt
together, can't
tell apart. can use color gradient ? (yes, on blue, not on red, can't see red).
☝︎ a111: Logged on 2017-07-02 07:11 BingoBoingo: Your lawn? Compost. Don't mulch your lawn, it needs
to breath.
mircea_popescu: (you are aware, yes, usg vulnerable
to nuclear blasts, latest studies show ?)
mircea_popescu: historically,
the best way
to "inexplicably" die suddenly was
to attempt
to attack groups of strictly selected, very determined,
technologically superior people. bitcoin is no exception, whatever
the hallucinations of
the "we are
talking about it
therefore involved in it" crowd may show.
mircea_popescu: and
this isn't just mp being hoity
toity.
the point here is
that
the sort of superficial schmuck who imagines bitcoin has 6k nodes, is also
the superficial schmuck who imagines if bitcoin is framed
through usg owned internet,
that'll "just oiccur". it won't just occur,
the same day
there's a nuclear blast on capitol hill, no questions asked.
mircea_popescu: sina "The Bitcoin network has more
than 6,000 nodes," << lost interest at
that point.
a111: Logged on 2017-07-01 23:52 asciilifeform: and nao bernstein, henninger (
this is what, 3rd paper since she was attached
to him ) 'unhappened and rehappened' it
a111: Logged on 2017-07-01 23:36 sina: if you write a systemd unit file with "User=0day", it launches
the process as root. Pottering sez: "not a bug"
ben_vulpes: but if you'll excuse me, i'm going
to go make a hash of breakfast
a111: Logged on 2017-07-02 03:58 ben_vulpes: in re benchmarking, is 'perf' a reasonable
thing
to use?
a111: Logged on 2017-07-02 06:06 ben_vulpes: why disregard runtime startup
time?
a111: Logged on 2017-07-02 07:56 ben_vulpes: sina if you can get your implementations
to print <execution_ms>\n<hash>
that'll save me a bit of fiddling
ben_vulpes: sina if you can get your implementations
to print <execution_ms>\n<hash>
that'll save me a bit of fiddling
☟︎ BingoBoingo: Your lawn? Compost. Don't mulch your lawn, it needs
to breath.
☟︎ ben_vulpes: well if i
time just
the hash impl it does squeak in under
the go implementation
ben_vulpes: had like five followups, all of which are probably answered by "this is probably one of
those
things worth doing rigorously"
ben_vulpes: not "unix
tool as it may or may not be used in
the future"
mircea_popescu: ben_vulpes or you could just instrument your impl
to read
time at start and end ?
ben_vulpes: i'm well supplied with compute
tho,
thx
sina: ben_vulpes: I am about
to head out
the door so currently not
the best
time, but if it would help in anyway I can donate some compute
to
the effort
ben_vulpes: but i am definitely interested
to see how performance plays out on large sets
ben_vulpes: well who knows, who'm i
to make guesses like
that
sina: well, I guess lets see how
the benchmarks play out over a larger dataset, maybe it evens out over a certain bitlength or bytesizer
sina: cos
that'd be pretty interesting
sina: ben_vulpes: did you use sbcl
the other day when you mentioned golang impl was faster
than lisp impl?
sina: it does sound like lisp is doing something JIT-like, except you can "re-JIT" at any
time during execution?
sina: black box doesn't have
to be invoking from CLI each
time
tho, you could write a daemon around each impl and measure how long it
takes
to return a value
a111: Logged on 2017-07-02 04:33 ben_vulpes: no i do intend
to black box it
sina: or you are OK with a blackbox, in which case can just use
time and avoid calling it with small loops where
the runtime startup cost dominantes `time`
sina: my point was, either you *really* care about evaluating
the actual main loop, which is a fair apples/apples
sina: ben_vulpes: you asked what else "it" can depend on, where "it" == whether or not runtime startup is a cost of
the program or not
ben_vulpes: "cython wouldn't know
the input
type without chasing pointers all over
the place"?
ben_vulpes: sina: how does
the paste relate
to
the JIT
thread?
sina: <+ben_vulpes> runtime startup is a cost of
the program, innit? <<
sina: ben_vulpes: sorry. I am referring
to pypy JIT vs python
ben_vulpes: buddy how do you
think i've been comparing
things?
sina: its reading something closer
to native compiled code
sina: faster in
the run because its no longer "interpreting"
ben_vulpes: faster in steady state runs or faster
to compile?
sina: for example, pypy is much faster
than cpython for long running programs, because it Just In
Time compiles
ben_vulpes: but extending from what i know of java's jit (not much), no.
the whole file (at least in
the
tests i'm running) is compiled.
ben_vulpes: i've no idea what you mean by
that in
this context
ben_vulpes: i wouldn't keep a lisp runtime hanging around just on
the offchance i want
to hash
things
sina: well, I dunno
too much about lisp, does it "JIT" for long running programs?
sina: that might be a fairer blackbox
test?
sina: if I make an mpfhf daemon,
then no
ben_vulpes: runtime startup is a cost of
the program, innit?
sina: of
the main loop iterating
through M
sina: so if you really want super precise, apples <=> apples comparison, you would need
to instrument performance on a per lang basis, no?
sina: because, for example, python and lisp, probably most of
the
time will be spent in starting
the runtime/interpreter
than actual computation, unless you're doing larger sized stuff
sina: here is
the
thing, it depends on how anally you want
to measure
ben_vulpes: obvious counterargument is
that "don't bother with subsecond executions, dork"
ben_vulpes: something something not great subsecond resolution or so
the various reddits say?
sina: is
that all you want
to measure? why not just use `time`
then?
sina: e.g. "how long does it
take
to hash document of N bytes size in M bits hash" with varying N and M?
sina: ben_vulpes: oic. and why not just using black box
testing?
sina: ben_vulpes: can we roll back and start at
the usecase?
sina: mircea_popescu: around? any
time
to play with gossipthing?
sina: but again, I haven't used
that one
BingoBoingo: Isn't dtrace
that Sun Microsystems
thing
that came with Solaris 10?
sina: I heard good
things about systemtap but never used it myself
ben_vulpes: sina: got any better ideas for comparing program runtimes
than perf?
BingoBoingo: <asciilifeform> mircea_popescu: afaik
there is no konsoomer nife.
there are only industrial. << In UK "consumer" sets are being marketed for solar crowd
BingoBoingo: Unless you go full synthetic on
the fuel and
they why
the fuck not drill for natural gas
then