-
Notifications
You must be signed in to change notification settings - Fork 2k
Huge speedup #2765
Comments
This is the version of lolex adapted for tinyqueue: "use strict"; const TINY_QUEUE = require('./tinyqueue.js'); function withGlobal(_global) {
} var defaultImplementation = withGlobal(global || window); exports.timers = defaultImplementation.timers; |
Hi, thanks for posting this. I am trying to run many simulations in parallel and am finding I am CPU bound once around 15-20 are running, even though I have quite a lot of power available. So this change is of interest to me ;) I pasted your source code above over the contents of The simulation starts ok but after a short while I get this error;
I am not using By the way, just so you know, there are funny characters in the signature of two |
I didn't have this error, but my mongo was on localhost.
If you really want to use zenbot (I'm now convinced it's not a viable
option for what we both are trying to do), I strongly recommend you
implement something where:
1. You take the k-lines/trades from mongo and write them to a file
2. You use that file instead of mongodb in zenbot when running a backtest
It should improve performance immensely, *and* will make sure you can't
have any mongodb error (the current mongodb code in zenbot is utter crap,
just look at how it does things...)
I actually changed a lot of how zenbot worked with mongo before I gave up
on it, but lots of my work broke parts of zenbot I don't use (like paper),
so I don't think it'd be helpful to others as-is.
FYI, I'm now using bbgo instead, and it works incredibly well, and it's
very actively developped (and supports grid, which is what I was adding to
zenbot). The only issue is it's lacking documentation at the moment.
…On Sun, Jan 23, 2022 at 2:05 PM Geoff Clayton ***@***.***> wrote:
Hi, thanks for posting this. I am trying to run many simulations in
parallel and am finding I am CPU bound once around 15-20 are running, even
though I have quite a lot of power available. So this change is of interest
to me ;)
I pasted your source code above over the contents of
node_modules/lolex/src/lolex-src.js and also added tinyqueue.js in the
same directory, with the contents pasted from here:
https://raw.githubusercontent.com/mourner/tinyqueue/master/index.js
The simulation starts ok but after a short while I get this error;
UnhandledPromiseRejectionWarning: MongoServerSelectionError: Server selection timed out after 30000 ms
at /home/zenbot/node_modules/mongodb/lib/core/sdam/topology.js:438:30
at callTimer (/home/zenbot/node_modules/lolex/src/lolex-src.js:367:20)
at Object.tick (/home/zenbot/node_modules/lolex/src/lolex-src.js:647:21)
at withOnPeriod (/home/zenbot/lib/engine.js:779:17)
at onTrade (/home/zenbot/lib/engine.js:950:7)
at /home/zenbot/lib/engine.js:904:5
at /home/zenbot/node_modules/async/dist/async.js:4011:13
at Object.process (/home/zenbot/node_modules/async/dist/async.js:1674:21)
at /home/zenbot/node_modules/async/dist/async.js:1532:23
at /home/zenbot/node_modules/async/dist/async.js:74:45
I am not using localhost as my Mongo address so I wonder if that is the
cause. Did you have to work through this error when you implemented this?
By the way, just so you know, there are funny characters in the signature
of two for loops in the above
for(let id = 0;Â id < clock.timersq.data.length; id++)
for(let id = 0;Â id <= clock.timersq.data.length; id++)
—
Reply to this email directly, view it on GitHub
<#2765 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2SFLPRFNNJPEQU7LCZ2DUXP4JFANCNFSM5I4T7LUQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
勇気とユーモア
|
Hi, thanks for the reply. Writing data to a file for Zenbot to read from sounds like a good idea. I already tried running Mongo with the inMemory storage engine to see if that would make a difference, but it made no difference at all. My app is rather deeply integrated with Zenbot at this point so I am not going to give up on it just yeat. Though I may change the way in which I expect to use it to fit with the limitations on parallelisation. I did have a set up where I was using AWS Farscape with auto-scaling to handle parallelising up to hundreds of processes, and it worked quite well, but I was not keen on the costs. I just had a look at bbgo and as far as I can see it is also limited to running one backtest at a time so would require similar tolling around it as I have built for Zenbot. I would need to do some analysis of resource usage of bbgo vs. Zenbot before committing to that route. Much to think about! |
On Sun, Jan 23, 2022 at 2:24 PM Geoff Clayton ***@***.***> wrote:
Hi, thanks for the reply. Writing data to a file for Zenbot to read from
sounds like a good idea. I already tried running Mongo with the inMemory
storage engine to see if that would make a difference, but it made no
difference at all.
Tried that too.
My app is rather deeply integrated with Zenbot at this point so I am not
going to give up on it just yeat.
That's called the "sunk cost fallacy", look it up, it cost me 3 weeks of
zenbot work...
Though I may change the way in which I expect to use it to fit with the
limitations on parallelisation. I did have a set up where I was using AWS
Farscape with auto-scaling to handle parallelising up to hundreds of
processes, and it worked quite well, but I was not keen on the costs.
That's my long-term plan. For now a server with 40 cores does the job,
though a bit slowly.
I just had a look at bbgo and as far as I can see it is also limited to
running one backtest at a time
But it's very cheap in terms of ressources, and very fast at starting/going
through it (insanely faster compared to zenbot). Especially after I
reported a whole bunch of bugs and asked for features that make this easier.
Currently, in my system, running a backtest on one day, takes under 0.1
second (starting, stopping, writing the report to disk as json, everything
included). Zenbot was at least several seconds.
… so would require similar tolling around it as I have built for Zenbot. I
would need to do some analysis of resource usage of bbgo vs. Zenbot before
committing to that route.
Much to think about!
—
Reply to this email directly, view it on GitHub
<#2765 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2SFO2SLWZ35AHMQZPLVLUXP6RFANCNFSM5I4T7LUQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
勇気とユーモア
|
I can see how the sunk cost fallacy applies here, but I have limited to spend on this stuff, so if my choices are either
...then I think I'd go for option 1 :) I wish there were an option 3: spend a bunch more time on it, but there is not... I will take another look at bbgo though. I like the idea of making the underlying sim engine in my framework selectable from a variety. |
On Sun, Jan 23, 2022 at 2:53 PM Geoff Clayton ***@***.***> wrote:
I can see how the sunk cost fallacy applies here, but I have limited to
spend on this stuff, so if my choices are either
1. Find a suitable use-case for the system I have already built
2. Do nothing
...then I think I'd go for option 1 :)
I wish there were an option 3: *spend a bunch more time on it*, but there
is not...
I will take another look at bbgo though. I like the idea of making the
underlying sim engine in my framework selectable from a variety.
That's how I started: I made my bot class a parent, made a zenbot and a
bbgo class that inherited it, rewrote the tests to run on both, and in a
couple of days I had it switchable from one to the other.
It was much easier than I first expected. Maybe give it a quick go/make
this a side project.
… —
Reply to this email directly, view it on GitHub
<#2765 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2SFPGFOGDBR6CHWIKXA3UXQB3ZANCNFSM5I4T7LUQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
勇気とユーモア
|
I've been profiling zenbot (in simulation mode)
It was spending most of it's time in lolex doing Object key lookups.
I solved that by storing lolex timers in a queue instead of an Object, giving an over 10x speed increase.
However, after further review, it was still taking most of it's time handling "fake" setTimeouts to call checkorder again and again.
I replaced that mechanism with a .done() .fail() mechanism instead (required a small change to the sim exchange, instead of polling for an order to be done, the exchange calls the callback once the order is done), and now simulations that at the beginning of the day took over 30 seconds, now run in well under a second (they are seemingly instant).
I think there's some more I can do to improve still, but for the moment this is enough for my needs (ie make it fast enough for genetic optimization to be pratical/not take days).
The source is available to anyone who wants the speed upgrade, but isn't good enough for a PR yet (that's the plan though): I don't think the current code would work outside of simulations (ie trade/paper).
The text was updated successfully, but these errors were encountered: