724500+ entries in 0.447s
bounce: you at least look
to've
thought about it, so
that's something.
bounce: yeah.
these're
the sort of questions people should've been asking from
the start.
bounce: alright,
the prosecution rests. ;-)
bounce: how many people
total, about five or so?
bounce: if
that's a question.... anyway, whose phone's gonna ring when
the dashboard
turns red?
bounce: 10BASE5
tentacled bus, silly
bounce: so,
that's one box with 32cpus does everything except
the load balancing?
Apocalyptic: fluffypony, ask if
they still have some copper left in
the DC
bounce: he fast enough
that
the batteries don't outrun him
then?
Naphex: there's a slave
there who does it :))
bounce: hope you don't have
to crank it up manually. :-)
bounce: ever had
the power go out?
bounce: apropos, which sql
thinger?
davout: Apocalyptic fluffypony i wouldn't care about
that, i'd care about having a fault
tolerant memory db,
that slowly gets synced
to an actual rdbms
fluffypony: Naphex: you should switch
to mongodb, it it's good enough for CoinBase it should be good enough for everyone
Naphex: Apocalyptic: haven't focused
that far, no more debunking needed:P
fluffypony: davout: I'd probably go Galera Cluster for
the DB + something monolithic for
the
trading engine...python? nfi. I haven't
thought
this
through.
davout: Apocalyptic fluffypony and you guys worry about
this kind of performance difference?
bounce: what's
the database like?
bounce: assuming you didn't have
to do it in anger (yet)
davout: Apocalyptic: what kind of software
that's so sensitive
to minor performance differences were you guys discussing anyway ?
Apocalyptic: "replayable
transactions with microtime acuracy" now
that's something nice
Naphex: roll back everything
to point in
time X
Naphex: bounce:
time based snapshots, backups, and replayable
transactions with microtime acuracy
bounce: alright, so you have separate dev/test/prod environments. how does roll-back work, should
that be necessary?
Naphex: when you do git checkout
there are some other code preprocessing before, but doesn't matter
Apocalyptic: davout, i don't need
to benchmark something I know will require 1 ASM MUL EAX,EBX instruction for exemple compared
to a Java arbitrary-precision library
Naphex: bounce: nah, git checkout, compile, run
tests,
test in pre-production, run
tests again
bounce: davout: for single applications, yes. for
things
that run on 30M+ cpus, not so much.
davout: Apocalyptic: is it what you
think or have you actually benchmarked it ? also cpu cycles are a couple of order of magnitudes cheaper
than
the
time it
takes
to handle it
the code level by hungry humans
Naphex: Apocalyptic:
too bad i can scale
this
too still low cost and get whole bitcoin exchange
trafic
Naphex: time
to start writing a new exchange engine, with its own kernel ;]
Apocalyptic: still better
than
the
thousands of CPU-cycles overhead using
that BigDecimal
davout: also if you really care about
this kind of performance difference you're doing some seriously messed up shit
Apocalyptic: even so, it will use 2 registers
to store one Naphex
Naphex: and i never get
too feel much performance increase yet
Naphex: too bad i run
this on 32 core
Apocalyptic: compared
to native int handling it's worse performance-wise
davout: Apocalyptic: what's wrong with a bigdecimal
type?
bounce: or
that mexican
telephone guy
Apocalyptic: mircea, because he uses some arbitrary precision library he doesn't have a clue
that he doesn't need it
bounce: YKINMK, and anyway, let
the guy explain
mircea_popescu: you're on a 64 bit system, who
the fuck is going
to deposit enough dollars
to
take you out of maxint
bounce: alright, so, you cook up a new feature. hit reload and it goes live? or how does
that work?
Apocalyptic: maybe just set some smaller precision on
the fiat side
Naphex: and
then you would've have kept
the scale value as well right
mircea_popescu: if i were designing
this it'd all be satoshi based, and your 19.99 dollars'd read as 1999000000
Naphex: i have multi-currency support handled in
the engine
Naphex: mircea_popescu: bigdecimal gets
to deal with all
that, and you don't have
to store multiple currencies with a scale value as well
bounce: everybody knows accounting should be done on
the double
mircea_popescu: Naphex you know you should be using ints for bitcoin in
the first place. wtf decimal bs is
this
Naphex: bounce:
trading api just hits same engine api server as
the frontend
gribble: Rating entry successful. Your rating for user usagi has changed from 1
to 1.
kakobrekla: ;;rate usagi 1 Had a 1140 btc contract with usagi which entitled me
to said amount on 2012-08-26.
The final payment was done 2013-04-27,
totaling 995 btc.
The sum was 145 btc short but I agreed
to let it slide because of distress on
the market of
the underlying 'securities' and rapid btc market price rise.
The contract did not involve a clause re. wot, but since he is asking back btc, I will leave it here.
bounce: so, java for
the back-end and some php for some front. what about
the
tradig webfront and
the
trading api?
fluffypony: kakobrekla: now he'll have
to recant his earlier statement
Apocalyptic: but you will notice it has nothing
to do with performance or securit
Apocalyptic: <Naphex> easier
to debug, maintain and analyze code others produced // ok
this is a point
Naphex: easier
to debug, maintain and analyze code others produced
kakobrekla: sakes', I will leave
this feedback here.
kakobrekla: ;;rate usagi 1 Had a 1140 btc contract with usagi which entitled me
to said amount on 2012-08-26.
The final payment was done 2013-04-27,
totaling 995 btc.
The sum was 145 btc short but I agreed
to let it slide because of distress on
the market of
the underlying 'securities' and rapid btc market price rise.
The contract did not involve a requirement of leaving
the feedback, but since he is asking
to give him back btc 'for old
time
Naphex: this around
the location where i live
Naphex: hard
to find good C programmers vs java ones
Naphex: Apocalyptic: its not
that, but a lot more went into picking java, and i definetly wouldn't have picked C:P
Apocalyptic: you're
telling me you will need
to store
things above 64-bit precision ?
Naphex: bounce: down
to data packets for specific services
Naphex: Apocalyptic: its not about
that, you eventually want
to support more currencies and some money formatting
bounce: validate in what sense, ip packets?
tcp streams?
Naphex: Apocalyptic: as in write a C .so
to implement/optimize bogdowns
Apocalyptic: he bignum library will once again slow
things down
Naphex: or you have
to do a C/C plugin
to optimize :P
Naphex: doing Price-Time prio is not
that performance critical
that you can't do it with BigDecimal and java
Apocalyptic: i.e. it will probably spend a
tremendous amount of
time doing
things you don't want it doing
Naphex: Apocalyptic:
they don't kill
too much performance when you are sensible about it
Apocalyptic: you get away from low level //
that's almost always a bad
thing in performance critical applications
pankkake: yes, it's certainly cleaner
than C++ on
that aspect
Naphex: everything is checked, exceptions everywhere (yes a good
thing) :)
Naphex: its not
that bad
too scale,
threading is a breeze
Naphex: its got hard
types, you get away from low level
Naphex: nothing
to dislike about it
pankkake: fluffypony: yeah. even
though, again, I really don't like Java as a developer
fluffypony: I'll
take an exchange with Java on
the back
than PHP any day
Apocalyptic: pankkake, java and amazing don't belong
to
the same sentence, ever :D
pankkake: java is amazing in
the sense
that it performs well at benchmark
fluffypony: TestingUnoDosTre: yeah saw
that, it's hilarious :)
Apocalyptic: Naphex, high performance compared
to what an equivalent code compiled in C ? doubt it
Naphex: don't belive it,
try some benchmarks :P