I'll confirm, and guarentee, that Perl threads are scheduled by the system scheduler and are eligible to run on all available cores unless you takes specific steps to prevent them from doing so. But then I guess you'd expect me to say that :)

I am doing something wrong?

On the basis of your description of your observations: yes. But without some idea of what you are doing, it's pretty much impossible to suggest what that might be.

If, for example, your process is cpu-bound and spends most of it's time interacting with your 1GB of shared data, and your threaded version is applying indiscriminate locks to that shared data, then you could effectively be serialising access to it and 7 of your threads spend their time waiting for the 8th thread to release the lock. That conceivably might produce the symptoms you are seeing.

By way of demonstration. The following code will show almost no benefit from the threading or multiple cores:

#! perl -slw
use strict;
use threads;
use threads::shared;

my %bighash :shared = map{
    $_ => 1;
} 'aaa' .. 'zzz';

sub thread {
     while( 1 ) {
        lock %bighash;
        1 while each %bighash;
     }
}

my @threads = map{
    threads->create( \&thread );
} 1 .. 8;

$_->join for @threads;
[download]

Because all the threads are competing for a lock on the same single data structure, so only one thread will ever doing anything useful at any given time.

There are simple ways of avoiding this problem, but which is applicable depends upon what you are doing in your program.