I will be using Bowtie2 to trim and map paired-end reads from FASTQ files stored on a USB drive. I noticed Bowtie is equipped with the '-p' option which will launch N parallel search threads (default = 1).
In general you're best off just using the number of cores present, so "-p 12". In practice, you need to run a simulation to find out the optimal number. One example of that was done here (they used up to 32 threads and ended up modifying bowtie for a bit better performance). There are other examples out there if you look for them. I should note that doing timing as in that example is only useful if you have >>12 threads.
Edit: Actually, Xeon's have hyperthreading, so you might do some benchmarking with up to 24 or so threads. See an example of using/disabling hyperthreading in this PDF, which seems to jive with my own experience that you might as well use the number of hyperthreads.
I use Bowtie2 on a Xeon workstation (nehalem architecture) and do notice a speed increase (not double though) between using -p (the number of cores) or -p (number of hyperthreads), but with -p (number of hyperthreads) it tends to make my computer quite unusable (coffee time!).
So much like @dpryan79 said, experiment between 12 and 24.
In my testing I've found that you start losing the benefit of more threads when you go above 8 threads with bowtie2. Plus, hyperthreading only helps when a cpu has low load. If you're running on all cores, hyperthreading slows things down. This is both on 12 (24 with HT) core AMDs or 32 (64 with HT) core Intel Xeons.
Of course, this could be dependent on our set-up here.
