Bulat, On Dec 27, 2005, at 1:58 PM, Bulat Ziganshin wrote:
no problem. my library handle about 10-15mb/s, and i think that speed can be doubled by using unboxed ints
Would you like to present your version of the timeleak code plus statistics from a test run? This will demonstrate the technical superiority of your library. I'm sure it can talk the talk but can it walk the walk? Please make sure that you have bots reading from the file all at the _at the same time_, not sequentially.
these delays says nothing about speed. you are mixing two things - your end goal is to make delays short, but your instrument - speeds of different processes and to decide what you need to optimize you must calc these speeds separately. without it, your "optimization" is just random game
I need to reduce the overall delay. Individual delays do me no good. Show me a 1-2s delay in the "timeleak" unstuff code then I will be convinced.
JR> Each bot is given 5, 15 or 35 seconds to respond by the poker server
so you don't need to create complex timer thread machinery, just use 3 threads which proceed requests in FIFO order
Socket read is a blocking operation. An easy way to handle a blocking read is to launch a thread that reads from a socket and posts packets somewhere once they are retrieved. I cannot handle large numbers of bots if I block on a socket read.
JR> I spent 3 hard months (barely any weekends, no holidays) polishing my JR> Haskell code.
... wasting your time to speed up code that is slow by design. don't forget that this article was published as FUNCTIONAL pearl, not damn-fast pearl
Not quite. I ended up with the pickler code but I did not start with it.
i think that you will get just the same problems as with Haskell and forced to switch back because it's easier to low-level optimize in Haskell than in Erlang
Absolutely not. I wrote a poker server in Erlang (see the openpoker/ erlang sections of http://wagerlabs.com) so I know what I'm talking about. There's usually no need to optimize anything low-level with Erlang, it's fast enough as it is for network operations. It's also optimized for pickling as well. See http://erlang.se/doc/doc-5.4.12/ doc/programming_examples/bit_syntax.html#4, for example.
JR> My only requirement is that there be a _single_ spec for pickling and JR> unpickling, i.e. no separate methods. The following is not acceptable JR> to me ;-).
say exactly WHY you need this single spec. i know at least 4 solutions, what is the best depends on your exact needs
Because I have 150 records with a lot of fields and writing separate code for pickling and unpickling is a nightmare?
for example, one of these solutions looks like this:
instance Binary TableInfo where put_ bh (TableInfo a b c d) = put_ bh (a,b,c,d) get bh = do (a,b,c,d) <- get bh; return (TableInfo a b c d)
instance Binary GameType where put_ bh = putWord16 bh . fromEnum get = liftM toEnum . getWord16
This gets tedious very quickly. Thanks, Joel -- http://wagerlabs.com/