Code designed to work a on a single thread bmax compilation is usually slower on threaded mode. when the diference of time is this big, it usually means the code has to be redesigned, or optimized. Obviously if you're writing a threaded application from the begining, you would not be getting this issues.
As instance, a decent multi-threaded parser would implement a string stream (instead of working with 10000 strings!!!) to make the tokening. This string stream could be used to read from the same base string, from different threads, at the same time without any problems. This could make the parsing go faster than a single brute-force thread reading byte by byte.
I mean, making a threaded application is not just putting a parameter on the compiler, it is designing the application to be fast using multithread-based algorithms. If you're not going to use this kind of algorithms, I'm sure you can expect all kind of drawbacks and performance lost.
As instance, a decent multi-threaded parser would implement a string stream (instead of working with 10000 strings!!!) to make the tokening. This string stream could be used to read from the same base string, from different threads, at the same time without any problems. This could make the parsing go faster than a single brute-force thread reading byte by byte.
I mean, making a threaded application is not just putting a parameter on the compiler, it is designing the application to be fast using multithread-based algorithms. If you're not going to use this kind of algorithms, I'm sure you can expect all kind of drawbacks and performance lost.