Re: Perl is too slow - A statement

On Fri, 01 May 2009 14:17:17 -0400, Charlton Wilbur <cwilbur@xxxxxxxxxxxxxx> wrote:

"sln" == sln <sln@xxxxxxxxxxxxxxx> writes:
On Fri, 01 May 2009 10:54:16 -0400, Charlton Wilbur <cwilbur@xxxxxxxxxxxxxx> wrote:

"NK" == Nathan Keel <nat.k@xxxxx> writes:

NK> In the end, if I ever told someone that I was contracted to
NK> program for them, or my employer that, "if you want it to run
NK> better or faster, get faster systems", I'd have been quickly
NK> ripped a "new one" or fired, and definitely lost the respect of
NK> the people I was on the same programming team with.

Whereas I have said as a consultant, "Look, I can spend a week tuning
this code and get *maybe* a 5% increase in speed overall. Or you can
spend the same $2K you'd spend paying me for that week and get a new
system to run it on, and get a 50% increase in speed across the board."
Oddly enough, this seemed to win me more respect.

Do you assume a one-off simple in-house utility program that one person
in a no person staff could tweek? In that case, they wouldn't spend any
money at all for speed enhancement, hardware or software.

On the other hand, a sophisticated in-house system would have a support
staff. And as the requirements are constantly changing, software modifications,
be it bug fixes or enhancements are done/being worked on constantly.
Why hire a support staff to tell you to update your hardware as a bug fix?

As for a hardware update to get that %50 speed increase.
I assume you mean adding another cpu core as in 'dual-core cpu', as
opposed to adding another parallel machine in a distributed processing.

The fact is, unless your adding a Cray, this won't help a bit. The big
reason is that until languages can take single code path sourse and
convert and compile into threaded code to take advantage of the extra
core, the speed will actually decrease from the original.

The limiting factor of all hardware speed is the heat of the cpu.
When doubling the core of the cpu you double the heat. Reducing the
wattage consumption in multiple cores via the wafer process, has resulted
in reducing each cores speed (Ghz) compared to a single core. All this to
maintain a maximum level of heat dissipation (wattage) when all the
cores are firing (stressed) on all cylinders.

Each new rev of a cpu has actual pipelining/instruction enhancements,
however, some apps may benefit and some won't as app benchmarks tell us.

The bottom line is that apps are always evolving to take advantage of new
cpu technology, NOT the other way around. Enhancements, re-writes, re-factor,
bug fixes, etc.. for all common sense reasons, are the rule, NOT the exception.


It's not all about hero programming.

Ah, the *GLORY*, the hero. Do it for the glory of it. Plunging into one
large app enhancement after another. Yeah, if you live through the stress
I guess you would be a hero... when you bring home the paycheck to support
your wife and kids.

It's about getting the job done
right while using as few resources as possible, and development time and
powerful hardware can sometimes be exchanged for each other. There
usually comes a point where spending more money on hardware gives you a
better bang for the buck than spending more money on development and
optimization.

This is NOT mutually exclusive as you portend, far from it.

I'd be pretty disgusted with a manager who didn't realize
that.

Charlton

I didn't know that supervisors give you a choice to be disgusted.
Hardware is a procurement item, budgeted, and out of the control
of development teams. In other words, in the corp world, the
solution to speed up a one-off utility app by purchacing a new
machine would have to be approved by the business department.
A complete procuremnt and justification array of paper work and
departmental approvals would be needed, taking several weeks or
months for the process, costing more than the machine itself.

So I see no argument that a simple machine upgrade alone will solve
speed problems.

-sln

Someone who whines about not being able to find work, alternating it
with really bad advice and really shoddy code, really has no business
lecturing other people about how businesses work or about sane
development practices.

Charlton

Nice defence and comeback. It sounds like the "hero programmer/manager"
made you have another disgusting day. Enjoy your job while you have it.

-sln
.

Relevant Pages

  • Re: Perl is too slow - A statement
    ... Why hire a support staff to tell you to update your hardware as a bug fix? ... I assume you mean adding another cpu core as in 'dual-core cpu', ... some apps may benefit and some won't as app benchmarks tell us. ...
    (comp.lang.perl.misc)
  • Re: [opensuse] Multithreading?
    ... core, and the other three are just there to consume power. ... A threaded app is one where a single app can possibly run in different ... more than one thing at the same time, it would involve libpthread. ... the presence of libpthread does not indicate how busy your CPU cores ...
    (SuSE)
  • Re: Intel comming out with a 16 core Nehalem family.
    ... "part of the OS embedded into the app" doesn't make any sense. ... all a core does, then there is a vague line between the app and the OS, ... since the app has exclusive access to the cpu, ... would have it's own i/o scheduler running in its own space. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: Intel comming out with a 16 core Nehalem family.
    ... "part of the OS embedded into the app" doesn't make any sense. ... all a core does, then there is a vague line between the app and the OS, ... since the app has exclusive access to the cpu, ... would have it's own i/o scheduler running in its own space. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: Intel comming out with a 16 core Nehalem family.
    ... "part of the OS embedded into the app" doesn't make any sense. ... exclusive access to the cpu, it could utilize it's own cpu scheduler running ... If the job of a certain core is to exclusively ...
    (alt.comp.periphs.mainboard.asus)