Re: NEC-LIST: Computer speed, was Imperfect ground.

At 03:54 PM 11/27/2002 -0600, you wrote:
>Hi Rob,
>
>You have said several times that computers are so fast now that almost
>anything can be tolerated in software. Last week I ran a 101-point
>impedance vs. frequency loop on a 1222-segment model using nec2dxs. It took
>my 500 MHz celeron 5 hrs. Granted a 2 GHz processor would do it in a little
>over an hour if memory bandwidth is not an issue, but that's still
>significant time. Faster hardware just means we can run bigger problems, it
>doesn't mean we can give up coding efficiency.
>
>Doug Miron
>--
>The NEC-List mailing list <nec-list_at_gweep.ca>
>http://www.gweep.ca/mailman/listinfo.cgi/nec-list

To which I'd add that it's really an issue of the number of users of the
code and the "incidence" of the cost.

Compare two alternatives:

Inexpensive, but inefficient code. Consumes twice as much computer
resources as a
Expensive, efficient code.

The former reduces the capital investment for the code, but increases the
cost for ALL the users (whether you figure capital to buy a faster
computer, or just the cost of the extra time to run slower).

The latter costs the developer more, but saves lots of money for the users.

"the market" sets where the equilibrium point is. Of course, as a
practical matter, for codes that are likely to be of interest to the
readers of this list, there are several general classes of users:

A) Cash poor, free time rich, tinkering with a problem, the solution of
which has little direct economic value (i.e. optimizing the spacing of the
inverted V wires in my backyard, or a scientist investigating something to
get it to a point where you can ask for real funding)

B) Cash rich, free time poor, tinkering with a problem of little direct
economic value

C) Cash rich, with a problem that the solution has real economic value
(commercial antenna designers, PWB layout to reduce EMI)

D) Cash poor, with a "real" problem.

For cases A, B, and D, the cheap code approach is probably the best. A and
D don't have resources for either code development or better computers,
and, so, just have to tolerate it (or reformulate the problem). B can just
go out and buy a faster computer (or more computers in a cluster).

Case C is the commercially viable one that supports the folks selling
modeling software. If you need it (in a business sense) then you're
willing (or should be willing) to pay for higher performance (or, buying a
faster computer.. the choice is yours).

Consider though... say it takes a year's work to produce a decent product
(and I'll wager that there's a lot more than a year's work in, say, NEC2,
or any of the commercially available products). That year's work costs,
conservatively, $200K (if you had to pay for it). How many customers are
there for a "better antenna modeling program" and "how much are they
willing to pay"? If you charge $1K a pop, there better be 200 customers,
who would rather spend 1K on better software than 1K on a faster computer.
There ARE people who can make the business case, and are willing to spend
the bucks for the slick, high performance, software. MATLAB isn't cheap,
but my professional life is measureably better because it's available, and
it really, truly does save money.

Fortunately for the As, and really fortunately for the D's, is that what
also happens, is that some folks are altruistic, and develop this kind of
software as a "labor of love" to meet some personal requirement, and then
decide to release it to the big wide world. Or, the "government" (or
researcher) decides that it's worth spending money to solve the problem for
one case, and then, since it's done, they might as well release it (since
the "government" generally isn't interested in a continuing income stream).

-- 
The NEC-List mailing list <nec-list_at_gweep.ca>
http://www.gweep.ca/mailman/listinfo.cgi/nec-list