PokerTracker: The Next Generation (NEW SOFTWARE DISCUSSION)

[APerfect10]

You can do that now in PokerAce Hud using the Player Ranges. Options->Preferences->Filters

-AP10

[Chaser8]

[ QUOTE ]
You can do that now in PokerAce Hud using the Player Ranges. Options->Preferences->Filters

-AP10

[/ QUOTE ]

Yes, but it only specifies a range. What would be much better is if the program automatically displays stats from ONLY 5-handed games when you're playing at a 5-handed table, for example. And ONLY 4-handed stats when you're playing at a 4-handed table. The stats would be more accurate that way, plus there are more and more people datamining nowadays so there is lots of data available.

Right now, no matter how many players are at my table, the stats I see are 4-handed combined up to 6-handed.

[PokerAce]

You can do that with these ranges:

10-10
9-9
8-8
...
2-2

[choccypie]

Will PT3 work with Linux?

[PokerAce]

We're hoping for a Linux port, but it's not set in stone.

[Chaser8]

[ QUOTE ]
You can do that with these ranges:

10-10
9-9
8-8
...
2-2

[/ QUOTE ]

ssssick

[gieffe]

i dont think this was answered yet: will it be possible to import pahud layouts into version 3?

will iPoker miniviews be supported?

[PokerAce]

[ QUOTE ]
i dont think this was answered yet: will it be possible to import pahud layouts into version 3?

will iPoker miniviews be supported?

[/ QUOTE ]

Since the HUD is going through a complete design overhaul, existing PA Hud layouts may not be able to be converted (due to the HUD not functioning the same way).

Miniviews on all sites that have them will be supported.

[gieffe]

[ QUOTE ]

Miniviews on all sites that have them will be supported.

[/ QUOTE ]

that's good enough... creating a layout for ipoker miniview is a pita atm

[RobNottsUk]

[ QUOTE ]
Most of the actual processing is done on the database end, which is a different process anyway. So the nature of what PT3 is doing means the dual core processors will be taken advantage of.

[/ QUOTE ]
Hmmmmmmmm..... I have experience with SMP systems, running DataBases on servers and desktops, and I shouldn't expect great benefits for single user. Expect to be somewhat disappointed, with only a few % gain over single CPU (and possibly few % slowdown in certain cases).

Looking at the comments here, it seems that current PAHUD has some kind of busy waiting event loop, which starves other applications of CPU (as it rarely blocks). SMP does benefit this case greatly as the broken thread, can spin all it likes but never take more than 50% of CPU resources. So long as the OS scheduler does not, end up pinging the processes back and forth from one CPU to the other, dirtying the L1 caches.

The reality is, that a modern CPU is so fast internally, that memory access becomes a huge blocking factor, unless you're repetitively working over a small data set that can fit entirely in L1 cache.

Dual core, will tend to make interactive use better, when imports or report background tasks or running, or when some other OS CPU (or disk) intensive task is running.

One of the real keys to performance is to avoid blocking on slow syncbronous operations.

In practice that means avoiding lots of little statements that do a write, but bundle them up into transactions, and where possible do those in a background pipeline eg) HH import, avoids committing every individual action to disk, but commits a chunk of hands all together. It doesn't really matter to the player if all the stats are up to date with table action to the milli-second, they can accept a lag of a few minutes for new hands to be imported.

It also means having plenty of RAM so most queries are satisfied from pyshical memory, rather than involve fetching blocks from disk, which mean long seek times.

Because the DBMS and application are seperate processes, there's a significant RTT (round trip time) on queries, compared to in-process simple DB's backed by indexed files (mapped into VM pages held in RAM). It's important to lookup a decent chunk of data at once, rather than individual lookups, hence the use of SQL to structure higher level queries, and let the backend DBMS do better optimisation, as it processes larger tasks.

Perhaps the screen display, user input event processing, and fetching the data could take place in different threads; but if it's programmed simply, the reaction to user input, will generally result eventually in a DB lookup, which then blocks, and the screen display changes wait for the results to, meanwhile the DBMS may be blocking on disk transfers.

As most of the CPU processing is likely to be fairly simple calculations on largeish datasets, therefore memory bound, rather than CPU bound, it's very hard to get true parallelism.

There should be some advantage for Poker Site Client, PAHUD, PT3, PostGres and Operating System kernel, being spread over CPUs and L1 caches. But in general, I don't expect too much, more dual core adds resiliency in face virus scanners waking up, or indexing of folders and such like.

Unless you constantly think up some useful and intensive, data crunching that can be done, non-interactively you'll benefit from faster CPU, Memory & Disk access, rather than multiple-cores.

Hope that's technical enough to be useful to most, but not too hard to understand. I tink it shows why the developers like to restructe and use RDBMS, with carefully designed tables.