Borland Delphi >> total number of cpu core

function AvailableProcessorCount: DWORD;
//returns total number of processors available to system including
//logical hyperthreaded processors
var
i: Integer;
ProcessAffinityMask, SystemAffinityMask: DWORD;
Mask: DWORD;
begin
if GetProcessAffinityMask(GetCurrentProcess, ProcessAffinityMask,
SystemAffinityMask) then begin
Result := 0;
for i := 0 to 31 do begin
Mask := 1 shl i;
if (ProcessAffinityMask and Mask)<>0 then begin
inc(Result);
end;
end;
end else begin
//can't get the affinity mask so we just report the total number of
//processors
Result := OperatingSystemInfo.ProcessorCount;
end;
end; (* AvailableProcessorCount *)

In a recent thread "AMD X2 4800+ CPU", Eric Grange states
"FWIW Delphi 7 compile times suffer on dual-core, I'm running it with
affinity adjusted to single-core, but this requires in turn adjusting
the affinity of debugged applications (as by default, they inherit the
affinity of the debugger)."
I'm in the process of ordering a new development system here at the ab.
I've been OK'd to get a nice X2 4800+ system, but now I'm not sure if that's
the way to go. I use a single core AMD 64 at home, and that's pretty nice.
I'm moving all of my development into virtual machines, so I thought a nice
fast dual core with a couple of gigs of RAM would work well.
Anubody have any comments on this? And how will compiled apps perform under
dal core? Will they potentially run slower too?
--
Dave White
SpectraChrom Software
www.spectrachrom.com

A few thoughts on the programming implementations of the move toward multiple CPU
cores and hyperthreading in cores:
1) One of the advantages of hyperthreading is that when one thread blocks on, say, a
cache miss another thread can run immediately in the same core without OS task
switching. The second thread is expected to not be similarly blocked blocked on the
same resource.
But if the parcelling out of work to threads is very finely grained (e.g. to
perform operations on N items in an array at the extreme do it in N threads) then the
data that each thread will access will quite often be quite close to the data that
other threads want. A cache miss on one thread will therefore often be a cache miss
on all the other threads which a finely grained job was handed out to.
2) The more hyperthreads in a core the more cache thrashing that can take place. Each
thread can go asking for some chunk of data and that gets brought in to cache
displacing some cache page another thread wants.
3) A hyperthreading model could assign a cache section per hyperthread to prevent
cache thrashing. This ends up being similar to having multiple cores. Do any real
hyperthreading implementations do this?
4) The ability of a language to support parallel syntax (e.g. do operation X to all
the items in this vector) seems like it is better suited to a vector processing CPU
than to a multi-core or hyperthreaded processor. Though sometimes this won't be the
case. Sometimes what is described to be done to a set of entries in a vector could be
fairly lengthy for each item and require different logical branches for each item.
5) Should a programming language optimizing compiler or an OS make the decision on
how many threads to use to execute some section of code? I can see why a program
would know in advance it is approaching some section of code where it will need N
threads and to ask in one thread for the OS to create those threads while another
thread of execution approaches the point where the group of threads will be needed.
6) What language enhancements will provide a better gain in performance for most apps?
A) The ability to specify parallel vector operations
B) The ability for threads to be natively supported in languages
C) Bringing in relational database idioms like transactions so that assorted and
very different in-parallel operations on in-memory data structures get officiated
like relational database table operations do.