[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.