Perl is too slow - A statement

[Charlton Wilbur]

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.

It's not all about hero programming. 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. I'd be pretty disgusted with a manager who didn't realize
that.

Charlton

 

[sln]

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

 

[Charlton Wilbur]

[a great deal of rubbish]

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

 

[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

 

[Nathan Keel]

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.

It what was the situation, that's different and I'd agree with you.

It's not all about hero programming.

No, of course not.

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.

Yes, sometimes. As I said, just not every time and people that
sometimes opt for a more workable more efficient design and even
language, if it is cheaper, there's no debating. Sometimes companies
don't want to spend more on hardware and insist it should run better on
what they have, and sometimes they are right. Sometimes, no matter
what, you simply need to upgrade the hardware because there's going to
be a need for it anyway.

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. I'd be pretty disgusted with a manager who didn't
realize that.

Charlton

I really believe that they go hand in hand anyway, since good
development and the right designs and choices are vital regardless,
else you won't be getting much more bang for your buck anyway, as I'm
sure you agree. Every situation can be different, and I actually never
disagreed with this, but I do disagree when people say it is always
better.

 

[Nathan Keel]

Lanauges are not fast or slow enough. Applications arn't fast
enought.

I don't know what "Lanauges" are, so I'll take your word for it.

I am not familiar with the quantifier "arn't", so I'll take your word
for it.

I don't know what the word "enought" means, so I'll take your word for
it and say this nonsense has gone on long enough.

Regardless, some applications can be coded in different languages to run
faster or not, though it usually comes down to how good of a coder the
developer is, so it's all relevant to too many variables.

At some point, you might need to upgrade systems, and sometimes other or
better designs and in other languages can also offer a remedy, it's
impossible to say in a general term (in my opinion, but I care about my
code).

 

[sln]

I don't know what "Lanauges" are, so I'll take your word for it.

I am not familiar with the quantifier "arn't", so I'll take your word
for it.

I don't know what the word "enought" means, so I'll take your word for
it and say this nonsense has gone on long enough.

Regardless, some applications can be coded in different languages to run
faster or not, though it usually comes down to how good of a coder the
developer is, so it's all relevant to too many variables.

At some point, you might need to upgrade systems, and sometimes other or
better designs and in other languages can also offer a remedy, it's
impossible to say in a general term (in my opinion, but I care about my
code).

Shut the **** up you dick head mother fucker jackof asshole !!!

-sln

 

[Nathan Keel]

[...]

What happens when you find that the language isn't fast enough?

Lanauges are not fast or slow enough. Applications arn't fast
enought.

I don't know what "Lanauges" are, so I'll take your word for it.

Real classy a spelling flame. Like I haven't seen one of thouse
before.

http://quollified.com/~platypus/index.html

I resorted to picking on the typos because the response you made didn't
make sense, even when the spelling was corrected. I didn't take the
reply seriously, it looked like you were just posting nonsense for the
sake of it, so I poked fun. If you were genuine, then please elaborate
and accept my apologies for my assumption.

 

[Jürgen Exner]

Damn that provisioning system doesn't exist at all.

You know robic0 aka sln and the BS he is writing. Where I worked before
to a major part the build system was Perl-driven. And we are not talking
about some obscure tiny dot-com but a very major software company and
several products that are the most widely used SW products on this
planet. Sorry, can't get more specific because of NDA.

jue

 

[Nathan Keel]

No but writing code to be fast, before one knows if the code isn't
fast enough leads to no end of problems.

I suppose that depends on a few variables. It depends if the energy and
time in writing code known to be the fastest, in whatever language is
most appropriate, if it'll really take that much longer. Hopefully,
the developer(s) will be aware and have that experience to not guess or
just do rough code that they work off of, if it's not already fast
code. I suppose I always code to make the most efficient and faster
running code, no matter what, regardless of the scale of the project.
I do agree that I might not always code in the faster language at first
and sometimes I regret that when it's necessary to benefit from it,
instead of upgrading systems.

But, as we all know and as I had agreed, a system upgrade might be
needed regardless. Decisions can be made at design time and as the
initial code is being written. No one will ever fault you for writing
code that's too good, so unless it takes an unreasonable amount of time
to do it right the first time, one should be able to make the decision
before they start and with the design stages, if some languages are
better suited. For the record, I code most of my programs in Perl and
not C, so keep that in mind when you read what I said. I must not be
explaining myself well.

 

[Nathan Keel]

David Formosa (aka ? the Platypus) wrote:

[...]

What happens when you find that the language isn't fast enough?

Lanauges are not fast or slow enough. Applications arn't fast
enought.

I don't know what "Lanauges" are, so I'll take your word for it.

Real classy a spelling flame. Like I haven't seen one of thouse
before.

http://quollified.com/~platypus/index.html

I resorted to picking on the typos because the response you made
didn't
make sense, even when the spelling was corrected. I didn't take the
reply seriously, it looked like you were just posting nonsense for
the
sake of it, so I poked fun. If you were genuine, then please
elaborate and accept my apologies for my assumption.

Ok your claim was "What happens when you find that the language isn't
fast enough?". My responce was that this question didn't make sence.
Because languages are not what is fast or slow, applications are fast
and slow.

Certain languages will run faster than others. Precompiled languages,
for example, and thus C will run faster than Perl. So, if the slowness
of Perl could be remedied and be more efficient if re-worked in quality
C code, it could solve the problem. Additionally, this is something
that can be decided in the pre development stage, is what I was saying.
In other words, if Perl is causing too much overhead, you might not
need to only have the option of getting a faster system to resolve the
problem.

"What happens when you find that application" isn't fast enought is a
far more fruitful question.

The design of the application is important, and the language selection
might be, too, it all depends. An application built using a very slow
language that's not well designed for the function, would show it was a
language choice, where it could be developed in another language and
you'd not have that problem. Of course there are many variables that
play a role in that and the system still matters, how you utilize the
processing, the platform, etc., but language choice is still valid in
some scenarios.

 

[Nathan Keel]

David Formosa (aka ? the Platypus) wrote: [...]

Ok your claim was "What happens when you find that the language
isn't
fast enough?". My responce was that this question didn't make
sence. Because languages are not what is fast or slow, applications
are fast and slow.

Certain languages will run faster than others.

Languages are not run, programs are run.

You're really going out of your way to be sarcastic and petty here. The
"program" is build/coded in the particular language, and this some run
faster than others. You know what I meant. It's unfortunate that I
have to spell it out so literally.

Your at the wrong leval of abstraction. Languages are syntax and
semantics, programs running under language implimentations may run
faster or slower but that doesn't mean the language is faster or
slower.

Ugh. See the above, or are you going to base your whole argument on
such a foolish semantic so you can try and appear witty?

Most of the time slow code can be remedied by profiling the perl and
improving the algorithm. You get far larger speed improvements from
shifting down a class of big-O behavour then any language port.

Of course you can improve different areas of different code in different
languages, but some programs are faster, coded to do the same things in
different languages (choices).

Optimizing in predevelopement is the very definition of premature.

I didn't ever say "optimizing" in predevelopment. I said that you can
plan what language would be best to create an application in, before
you start. That was speaking directly in response to the mention of
that aspect, so don't make more out of what was said. Also, don't
reach so far to try and make your point. If you comprehend what I
said, then you've got nothing to disagree with, so enough with the
petty remarks.

 

[Peter J. Holzer]

David Formosa (aka ? the Platypus) wrote:

[...]

What happens when you find that the language isn't fast enough?

Lanauges are not fast or slow enough. Applications arn't fast
enought.

I don't know what "Lanauges" are, so I'll take your word for it.

Real classy a spelling flame. Like I haven't seen one of thouse
before.

http://quollified.com/~platypus/index.html

I resorted to picking on the typos because the response you made didn't
make sense, even when the spelling was corrected. I didn't take the
reply seriously, it looked like you were just posting nonsense for the
sake of it, so I poked fun. If you were genuine, then please elaborate
and accept my apologies for my assumption.

Ok your claim was "What happens when you find that the language isn't
fast enough?". My responce was that this question didn't make sence.
Because languages are not what is fast or slow, applications are fast
and slow.

I disagree. While a language per se is neither slow nor fast, all
computer languages (which can actually be used) have at least one
implementation (compiler, interpreter, run time system, etc.). For some
languages (like Perl5) there is only implementation, so the speed of
this implementation is also the speed the language (Yes, somebody could
write an alternate Perl5 implementation which was vastly faster or
slower, but nobody did - if you want to run Perl5 programs you need to
use perl). Even for languages with hundreds or thousands
of different implementations (like C or Fortran) some feature of the
language makes certain optimizations simple or difficult, so it makes
sense to say that for a certain class of problems Fortran is faster than
C: That doesn't mean that all Fortran programs for this class of
problems run faster that all C programs: But if you have a C programmer
and a Fortran programmer of roughly equivalent skill and a C compiler
and a Fortran compiler of roughly comparable sophistication, the chances
are good that the Fortran program will run faster than the C program on
the same hardware.

For an interpreted language like Perl, the class of problems which
simply cannot be solved efficiently in this language is relatively
large. Fortunately, such languages can usually call subroutines written
in other languages. So the answer for the question "What happens when
you find that perl isn't fast enough?" may sometimes be: You identify
the bottleneck and rewrite that part of the code as an XS module.

hp