FPHG available

[_dave_]

[ QUOTE ]
[ QUOTE ]
i've been using .07b for a few weeks, 12 tables on either party or empire 24 hrs a day. its been running great and i've had no problems. it stays around 2% (sometimes spiking to at most 4%) CPU usage and 3.5 MB of RAM

[/ QUOTE ]

I think I'll give .7b a try here. It can't hurt. [img]/images/graemlins/smile.gif[/img]

Rob

[/ QUOTE ]

I just had 0.07b running for 5k hands, no troubles:

40 tables at a time:

10 user accounts, 4x party tables per acct, running DeMonster 1.2.2, SafeMine 3.0 (and of course FPHG 0.07b) on each acct.

I was using FPHG options "-p -1 -d 200 -r", since I think realtime mode should do better with split pots, not sure about this tho.

Using between 45-60% CPU at all times, nowhere near enough to impact me doing other work on the main account.

I didn't multi-user-account for FPHG before 0.07b, so I don't know if performance is better than 0.06b or no, but it seems good for me ATM.

My CPU is an Athlon64 (Single Core) @ 2.25GHz, FWIW. 1GB DDR500 RAM.

I was not importing into PT at this time, I just did that now (~7-10 minutes)


YMMV,

dave.

[Entity]

When you run .7b, do you set it at p -2, or just leave it as "normal"?

[jukofyork]

[ QUOTE ]
I was using FPHG options "-p -1 -d 200 -r", since I think realtime mode should do better with split pots, not sure about this tho.

[/ QUOTE ]
It shouldn't do, as the code which looks for "New Data" and adds it to the end of the HH is separate from the realtime stuff. Also using "-p -1" might make it more likely to miss hands if the system is very overloaded ("-p 1" might be better, but can make your system/GUIs feel 'chuggy' sometimes).

It could be that v0.7b is faster for realtime mode though, as I know Mogobu optimized the realtime part most of all (this could explain why it's working better possibly).

Juk [img]/images/graemlins/smile.gif[/img]

[_dave_]

[ QUOTE ]
When you run .7b, do you set it at p -2, or just leave it as "normal"?

[/ QUOTE ]

[ QUOTE ]
[ QUOTE ]
I was using FPHG options "-p -1 -d 200 -r", since I think realtime mode should do better with split pots, not sure about this tho.

[/ QUOTE ]
It shouldn't do, as the code which looks for "New Data" and adds it to the end of the HH is separate from the realtime stuff.

[/ QUOTE ]

[ QUOTE ]

Also using "-p -1" might make it more likely to miss hands if the system is very overloaded

[/ QUOTE ]

I changed it from -p -2 (default) to -p -1 in the hope that it would bw less likely to miss hands, but still run at a lower priority than "normal" apps, because...

[ QUOTE ]

("-p 1" might be better, but can make your system/GUIs feel 'chuggy' sometimes).


[/ QUOTE ]
I was running this while "working" - doing PHP / postgres stuff on my work machines - chugging GUI can also mean chugging SSH connections to work machines, causing them to time out and lose my command line history - also causing me to reconnect, but that is less of an irritation [img]/images/graemlins/smile.gif[/img]

[ QUOTE ]

It could be that v0.7b is faster for realtime mode though, as I know Mogobu optimized the realtime part most of all (this could explain why it's working better possibly).

Juk [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]

I think the realtime mode is much improved - I had serious slowdown issues using 0.06 in realtime mode after ~1000 hands or so, but not with this version [img]/images/graemlins/smile.gif[/img]

I only use realtime mode since I was under the impression normal mode quits reading the hand when it detects "wins", and I thought realtime just kept on scanning regardless, maybe that was not the case?

dave.

[jukofyork]

[ QUOTE ]
I think the realtime mode is much improved - I had serious slowdown issues using 0.06 in realtime mode after ~1000 hands or so, but not with this version

[/ QUOTE ]
Cool, I just never got any real feedback about the 'b' versions, so couldn't be sure until now.

I know Mogobu did some profiling and found it worked significantly faster on his machine, but was just waiting for some feedback (we should have made sure we used the same defaults to make comparison easier).

If people have been using this without problems and it's confirmed to be running better, then I think I'll take down the old 'a' links.

[ QUOTE ]
I only use realtime mode since I was under the impression normal mode quits reading the hand when it detects "wins", and I thought realtime just kept on scanning regardless, maybe that was not the case?

[/ QUOTE ]
No both have the ability to read the extra bit, just the non-realtime version would detect it separately and then add it to the end (my main fear with realtime model is it would pickup junk/corrupted HHs, but it seems ok in practice).

I think the reason it's running better is bc the code is more optimized meaning less chance it misses the end of the hand after the wins line (but not 100% sure).

Juk [img]/images/graemlins/smile.gif[/img]

[matt42s]

I have a couple of ideas for increasing fphg's performance - particularly for realtime mode but I wanted to bounce them off you before I got too far with implementing my hacks. The inner loops are solid but we're not taking advantage of the fact that most active hands turn up in the same region time after time. I added some tables to track the 'active' regions and scan them on every loop - the inactive regions get scanned once every 5-50 loops depending on delay settings, with delay at zero, I'm scanning twice as many 'active' regions and still picking up new hands in new regions when they do occur.
The other thing I saw is that readprocessmemory is kinda slow - tracking regions means we don't have to do it every cycle, but virtualqueryex is an absolute dog. I haven't tried it yet but I think storing the MBI's, trying readprocessmemory and only doing the virtualquery when rpm fails will be much quicker. Combining these, we'll end up with another outer, outerloop of 1 - 2 seconds where all 'previous' regions are rpm'd and queried only if rpm fails, all regions are then scanned, but inside this loop we rpm and scan the 'active' regions - maybe 5 to 10 times and we have a much better chance of catching all the data.
I'm already tracking the regions but am not doing it in a 'nice' way and my C has been rusty for a decade. eg
unsigned int RegionStart[80];
Pls let me know if you think I'm off base or am about to hit a wall.
I just read my post preview and it seems the coffee has got to me, sorry if its completely unreadable. I hope I got the idea across though.


just added the following couple lines to prove that virtualqueryex doens't HAVE to be called immediately before readprocessmem - we can store the MBI's and MOST of the time the page boundaries won't move (they do move around when opening and closing tables but that happens in macro time)
void* NextAddress = SI.lpMinimumApplicationAddress;
NextAddress = (void*)((DWORD)MBI.BaseAddress + (DWORD)MBI.RegionSize );
MEMORY_BASIC_INFORMATION MBI2;
DWORD Ret2 = VirtualQueryEx(hProcess,NextAddress,&MBI2,size of(MEMORY_BASIC_INFORMATION));

[jukofyork]

[ QUOTE ]
I have a couple of ideas for increasing fphg's performance - particularly for realtime mode but I wanted to bounce them off you before I got too far with implementing my hacks. The inner loops are solid but we're not taking advantage of the fact that most active hands turn up in the same region time after time. I added some tables to track the 'active' regions and scan them on every loop - the inactive regions get scanned once every 5-50 loops depending on delay settings, with delay at zero, I'm scanning twice as many 'active' regions and still picking up new hands in new regions when they do occur.
The other thing I saw is that readprocessmemory is kinda slow - tracking regions means we don't have to do it every cycle, but virtualqueryex is an absolute dog. I haven't tried it yet but I think storing the MBI's, trying readprocessmemory and only doing the virtualquery when rpm fails will be much quicker. Combining these, we'll end up with another outer, outerloop of 1 - 2 seconds where all 'previous' regions are rpm'd and queried only if rpm fails, all regions are then scanned, but inside this loop we rpm and scan the 'active' regions - maybe 5 to 10 times and we have a much better chance of catching all the data.
I'm already tracking the regions but am not doing it in a 'nice' way and my C has been rusty for a decade. eg
unsigned int RegionStart[80];
Pls let me know if you think I'm off base or am about to hit a wall.
I just read my post preview and it seems the coffee has got to me, sorry if its completely unreadable. I hope I got the idea across though.


just added the following couple lines to prove that virtualqueryex doens't HAVE to be called immediately before readprocessmem - we can store the MBI's and MOST of the time the page boundaries won't move (they do move around when opening and closing tables but that happens in macro time)
void* NextAddress = SI.lpMinimumApplicationAddress;
NextAddress = (void*)((DWORD)MBI.BaseAddress + (DWORD)MBI.RegionSize );
MEMORY_BASIC_INFORMATION MBI2;
DWORD Ret2 = VirtualQueryEx(hProcess,NextAddress,&MBI2,size of(MEMORY_BASIC_INFORMATION));

[/ QUOTE ]
Hey, just had a quick read through this and I think there is still alot of scope for optimizing FPHG.

The only things is that FPHG hand grabbing mechanism is going to be completely overhauled sometime over the next few weeks (likely within a month - I'm just about to move house, so can't really put the time in yet). Another 2+2er has already done all the groundwork and showed the new method works (and uses 0% CPU time with no missed hands).

It will mean all of the memory polling method will be gone, so it's prolly not worth putting in too much time fixing up the current FPHG code (you are welcome to if you want though, and just send me any code/patches and I'll post them as a beta).

I also think that FPHG needs a GUI, as when I first posted it I wasn't 100% sure how Party would take it (and assumed they would be less bothered by a simple looking CLI application). Well 8 months on and it seems prety much accepted byt Party and I think a GUI would now be a good idea to reduce the number of confused posting about how to add CLI args, etc.

Also, a FPHG FAQ is needed badly, as I seem to get 2/3 emails every few days saying basically "FPHG is saving the .hhf fine, but PT won't import them, can you help?". Ben has allready offered some space on hiw Wiki for this, but I just havn't had any time to get started on it...

Juk [img]/images/graemlins/smile.gif[/img]

[matt42s]

I did have one idea for the core loop that I almost forgot, when processing a text frag we search all the way up the buffer for a terminator like 'wins', wouldn't it be quicker to branch as soon as we detect stars, and compare something like tables[i].lastchar to &buffer[tables[i].len] to see if the last char of buffer matches our stored lastchar value? if it does, we can work backward until we're confident its a match and not a random hit. This should save a few hundred compares per stars hit at a cost of storing a few chars per table.

edit: sorry, just realised the extra cost of matching the table name for every stars hit will very likely outweigh any gain

[matt42s]

having quad aces rivered doesn't feel as bad as optimising obsolete code [img]/images/graemlins/smile.gif[/img]

does the new method have a realtime mode?

[jukofyork]

[ QUOTE ]
having quad aces rivered doesn't feel as bad as optimising obsolete code [img]/images/graemlins/smile.gif[/img]

does the new method have a realtime mode?

[/ QUOTE ]
Hehe, sorry I should put a note on the main FPHG page warning that it's soon to be updated with a new method.

Yes, it should be 100% realtime mode (the reason for different modes in the old code was to try to reduce chance of corrupted HH appearing, but by skipping the first HH seen this seemed to negate that problem).

Juk [img]/images/graemlins/smile.gif[/img]