Could you post the SQL you use? There are many good reasons to do so.
One reason is to enable your colleagues in this forum to offer advice on what might be missed opportunities to write faster SQL. The query engine does what you order it to do, after all, and we all from time to time tell such engines to do their work in ways that might be significantly slower than other approaches.
The second is that the Engineering plan for optimizing the query engine tries first to visit those happy places where people and queries go all the time. The optimizer as it is now is pretty good, but it is not remotely close to how good it can be given steady background work, a bit more with every build, to tune how it reckons the best way to approach the particular decomposition of a given query. The more Engineering knows about those cases where the optimizer misses a chance to speed up a well-written query, the higher such cases can bubble up in priority for improvements.
Keep in mind, also, that parallelism is not a magic bullet. Some things just don't go any faster but instead will go slower if you parallelize them. As a thought experiment, consider whatever is the internal processing required to open a standard Windows File - Open dialog, a totally trivial thing. You're not going to get that any faster by trying to parallelize it so 16 CPU cores and 4000 GPU cores help open the dialog and then all work together to draw an Open button and a Cancel button. Trying to do that will only go slower.
Likewise, if a task is totally disk bound, like doing nothing but copying a file from one disk to another, you're not going to get significant performance gains by tossing a hundred cores at it.
The optimizer has to reckon such issues, and to do so in cases that are far more complex than deciding whether it makes sense to throw a thousand cores at drawing an Open button and a Cancel button. Like I say, it's pretty good now, the measure of "good" being whether a human could do better by hand-coding, but there is always room for improvement.
Radian is usually significantly faster than MapInfo, but the guys at MapInfo have very good skills and they tend to do a very good job of implementation. Because of that, MapInfo is a useful reference to measure performance, either of the core system or of the optimizer, against a well-implemented standard. So it is very helpful to know detailed comparisons, exactly what is being done in MapInfo and likewise exactly what is being done in Radian, with numbers on the results.
So... post that SQL, let the SQL wizards in this forum comment and then the result of all that joint thought will indeed be great input for tuning the system.