Adam wrote:

> In theory, yes a multi-threaded application can use multiple cores but
> Superserver does not.
>
>> Sigh. Multiple processors - NO. It's the one thing that people
> love to hate about SS.
>>
>> Dual-core single processor: *I* don't know, so wait for someone who
> does.
>
> Don't know for sure, but I have never seen fbserver.exe use more than
> one core at a time if that counts for anything.

From an operating system's point of view, there's no different between a
processor and core -- a "dual-core" processor is basically two physical
processors on one chip.

Hyper-threading is a bit different, but let's not go there (from
Firebird's point of view, though, two Hyper-threading "cores" look like
two physical CPUs as well).

>> > And
>> >you said that the classic model creates a new PROCESS for each
>> >connection, which sounds like the less efficient model for a
>> >multi-core since threads are more lightweight than processes.
>>
>
> Yes, a thread is more lightweight than a process, but as classic
> creates a process for each connection, the OS can put the particular
> fb_inet_server.exe process on whatever core it so chooses at any given
> time.

A thread on Windows is more lightweight than a separate process, but on
Linux (and, I presume, other POSIX systems) a process and thread are
about the same in terms of "weight".

The advantage that multi-threading gives you (over spawning multiple
processes) is the shared cache. Processes have, by definition, their own
address space and so cannot (easily) share memory. Threads all share the
same address space and so memory is basically shared "by default".

I don't know the architecture of SuperServer, or why it cannot use more
than one CPU, but from what I understand, the one-CPU-only limitation
will be removed when the "SuperClassic" architecture is released in v3.0
(is it 3.0?)

Dean.