One cannot help but think that at this point your best strategy would be to actually start writing some code.

In the time since you first asked this question, you could have written prototypes of both a forking and a threaded solution and now be in a position to do some empirical tests to determine which works best on your particular setup.

With a little care, the subroutines for issuing the queries, and comparing the results, should be reusable by both prototypes without change. You have already written code for the threading infrastructure. Knocking up a forking equivalent using Parallel::ForkManager should be relatively simple. Once you have both, you will be in a position to make some real progress on deciding which is going to work best in your environment as well as deciding if moving to a Perl solution is really going to produce any benefit over your exists C++ solution.

On the basis of the accumulation of the sparse information you've provided spread across your 3 threads on this subject, my gut feel is that a threaded solution will be most flexible and efficient, as your comparisons seem to be consuming the bulk of the time, using a reusable pool of workers will have less startup overhead and cause least memory thrashing. It will also require the least amount of infrastructural overhead to control the asynchronicity.

But, given your lack of information regarding the performance of the hardware setup--network bandwidth and latency--along with the spread of inherent hardware parallelism available--from 4 to 12 cpus--and the only measure of where the bottlenecks of the existing system lie, being hearsay that "the comparison is where most of the time is spent", attempting to draw any conclusions is only ever going to be speculation.

The only ways you are going to come up with any definitive answers is

  1. perform some deep analysis of the existing system and attempt to extrapolate that to your two alternative implementations;
  2. knock up some prototypes and perform some measurements.

And the latter approach will be quicker to do; require less in-depth knowledge; and provide the most accurate results.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

In reply to Re: best strategy by BrowserUk
in thread best strategy by libvenus

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.