Hyperthreading (assuming your talking about Intel's Hyperthreading technology) 'just happens' (or not). If the code in the program is condusive to being hyperthreaded it will be, otherwise it won't. You do not control it.

You might derive some extra benefit from hyperthreading if you compiled Perl using Intel's C compiler (which is huge and very expensive), as they may well have added optimisations to their compiler that will make the compiled code more condusive to hyperthreading, but the differences are likely to be small due to the 'data is code' nature of Perl (and other interpreters).

As Zaxo pointed out, most file crunching programs are IO-bound not CPU-bound, so multi-tasking them is often of little benefit. If your task is IO-bound, then you are better of buying a faster disk, or perhaps splitting your files across multiple (real, physical not virtual) disks.

In the rare event that your processing is CPU-intensive. Eg. Each file is small but requires a large amount of processing--some gene work might fit this category. Then, you probably could benefit from multi-tasking the overall load across several processors. If each read-process-write cyle is entirely independant of each other, then simply splitting the input files into one group per processor (eg. [a-f]*, [g-m]*, [n-t]*, [u-z]* for 4-processors) and starting one copy of the program to handle each group is probably as simple as it gets and reasonably effective.

If your task requires each processing cycle to have some knowledge of other processing cycles, then running one thread per processor may be easier.

As you can see, determining what if any benefit can be derived from multi-tasking a process, and how best to achieve it, requires fairly detailed knowledge of both the processing required and the system on which it is going to run.