Re: [Rails-devel] Revenue calculation performance

[Stefan F. <ste...@we...>]

Mike:
your assumption that the calculation threads are not terminated 
correctly seems to be a good first try.

To turn of logging for the revenue calculation:

* If you have a working development setup simply change a line inside
log4j.properties (change from INFO to FATAL).

# log4j.logger.rails.algorithms=INFO
log4j.logger.rails.algorithms=FATAL

* If you use the latest release version:

Copy the attached logging file into the working directory of rails (that 
with the rails jar and rails.sh rails-bat) and start rails with this 
command:

java -Dlog4j.configuration="file:log4j_woa.properties" -jar rails-1.7.5.jar

Stefan

PS: If you can think about a good reuse of previous calculation results 
I would be glad to hear about your suggestions. I do not see how you are 
able to use any previous result if any detail has changed on either 
graph, trains running or special bonuses.

And keep in mind that the main run time stems from the brute-force 
search taking (after the revenue prediction cut-offs), the effort for 
the creation of the graph and all optimizations are neglectable.


On 05/31/2012 08:14 PM, Mike Bourke wrote:
> Saved Game: Will do. Nothing "blocks" the UI but it responds at the same
> slow pace as everything else, so the in-effect result is the same. Note that
> earlier in the game there is no problem. I have monitored the log file size
> as play proceeds and can state that the delays are roughly proportional to
> the size increase in the log file, though that may be nothing more than
> coincidence. I have also used task manager and can comment that the memory
> usage appears quite low; it's the cpu cycles that are maxing out.
>
> Stefan, from your description of how things are supposed to operate, I have
> a sudden suspicion that perhaps revenue calculation threads never terminate,
> each starting in a new thread parallel to the previous one. By the time you
> get to op round 9 or 10, you would then have hundreds of them running
> simultaneously.
>
> My idea for route calculation is similar to your caching of old solutions
> but several steps further developed. In essence it records all existing
> routes as they are created by tile lays and upgrading a tile also updates
> those calculations. Right now, the system recalculates route values from
> scratch each company's turn in each op round. That entails a lot of
> redundant calculation; my idea is an attempt to remove that redundancy by
> caching of possible runs. This would probably slow tile laying slightly in
> the early/mid-game, but should speed things up in the end game. I'll discuss
> that more fully some other time, preferring to deal with that as a separate
> issue, possibly even something to consider for version 3 (after version 2 is
> up and running, in other words) because it's a fairly fundamental change.
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday, 1 June 2012 2:45 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Revenue calculation performance (was: An ongoing
> rails issue)
>
> Mike:
> those are the current options to prevent
>
> * To deactivate revenue calculation as a whole (all phases, complete
> game) choose the GameOption at the start of the game accordingly.
>
> * To avoid revenue calculation during the non-payout step use the
> Configuration Option in Panel "Map" =>  "Display Routes of active company".
>
> How the interface to the UI it is implemented (at least how it is supposed):
>
> * Revenue Calculation always runs in a separate thread and should never
> block the UI. If it does, it is a bug to be fixed.
>
> * During the Non-Payout steps it only shows the best route as hint (as
> request by John David Galt). You should always be able to select the
> next action and this itself should stop the current calculation and
> restart a new one based on the changed setting.
>
> * During the payout step it should provide intermediate best routes. As
> soon as you enter your own figure or choose distribution it should again
> stop calculation.
>
> Some more comments:
> * We had this discussion before (I remember your multiple Diesel 1830
> scenario). Same reply here that running two Diesels on an open map is a
> pretty hard scenario (even for a human player).
>
> * 1835 can be special case as well if the PR has three trains running
> (especially e.g. a 5+5, 6+6, 6+6), as the PR has many tokens so a pretty
> open map for PR too. However it should not be possible to have
> a multiple Diesel scenario in 1835.
>
> * Logging should not be an issue (in principle), but one could check
> that too. Logging can be switched by changing the log properties I will
> send you an adjusted one tomorrow for testing.
>
> * Improving the performance after reloading could also point to a java
> garbage collection issue or a problem with available memory on your
> system, however the revenue algorithm does not demand that much memory
> resources, but it could be something else in Rails which limits
> performance here.
>
> Potential improvements to revenue calculation are:
> * Dominating train heuristic (already implemented, will be merged into
> rails 2.0):
> This avoids calculating the same routes where the two Diesels simply
> swap their routes. Or e.g. that for a 6+6 and 5+5 combination, the 6+6
> will always run the longer route than the 5+5. For two diesels this cuts
> the running time nearly in half, for three trains there can be up to a
> six-fold speed increase.
>
> * Caching old solutions (not yet implemented, will come into rails 2.0
> branch soon):
> If the same network is run by identical trains the previous optimal run
> will be taken from cache. This will especially speed up undo/redo activity.
>
> * Design and implement a Maximum-Flow algorithm (not yet started, so
> nothing to expect soon):
> Create a different graph which allows to use a maximum flow algorithm to
> calculate the optimal runs (like John Tamplin reportedly did years ago).
> However this will only cover games with standard trains and no dynamic
> bonuses or other complex features (so it should cover 1830, but I am not
> sure about 1835). This would improve speed drastically for those scenarios.
>
> So please do as discussed on the list already: Provide a rails file,
> which allows to test this on other machines and by the developers and
> this could help to figure out the reasons for the problematic
> performance behavior.
>
>
> Stefan
>
>
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120531-0, 31/05/2012
> Tested on: 1/06/2012 4:14:05 AM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel