Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

What does "efficient" mean?!?

by dragonchild (Archbishop)
on Jan 15, 2002 at 19:31 UTC ( #138919=perlmeditation: print w/ replies, xml ) Need Help??

Over the past month, there've been at least two separate meditations on whether Perl is more (or less) efficient than other languages. C/C++ seem to be the most common comparison, with Java a close second. Yet, I'm noticing that very few people are talking about what "efficient" means. I see that there is more than one "efficiency" measure.
  1. CPU-efficient: executing statements faster
  2. RAM-efficient: taking less RAM for the same stuff
  3. development-efficient: taking less programmer time to write a program to accomplish the same task
  4. maintainence-efficient: given a program that is already written, modify it to accomplish a new task
Having my primary experience with C/C++, Perl, and BASIC (especially Excel's VBA), I'll only speak to those three languages. Also, I'm going to assume a decent professional programmer, but not a guru-level expert.

C/C++ is faster in terms of CPU. Why? Because C is Perl's machine language. Perl is tokenized to some assembler (soon-to-be Parrot), then each token is converted to some "machine language" which is implemented in (extremely optimized) C. If equally-optimized C is used without the Perl tokenization, it will necessarily be faster. Plus, C's data structures aren't stuffed with Perl's information-tracking additions.

So, C/C++ is more efficient in terms of the computer.

Writing a program in Perl, however, is generally quicker - in terms of programmer time - than in C/C++. I have a richer set of nouns (primitives) and verbs (operations) than in C/C++. More complex operations are supported in the language and there are operations in Perl than would require hundreds of lines in C/C++ to accomplish. This is especially true in string processing.

In addition, because C programs tend to be more complex than Perl programs, maintenance on them is more complex and error-prone. A 500 line Perl program is often equivalent to a 2500 line C/C++ program. That's five times the places an error can be hiding and five times the places you can inadvertantly add an error. I'm not keen on working with that kind of situation.

So, Perl is more efficient in terms of the developer.

Unless you need the computer efficiencies, I'd go with Perl.

(The astute observer notes that I didn't mention VBA. That's cause it's more of a fungus and not a computer language.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on What does "efficient" mean?!?
Re: What does "efficient" mean?!?
by redsquirrel (Hermit) on Jan 15, 2002 at 20:25 UTC
    I'm relatively new to programming, but one of the things that has been pounded into my head during my short career is that as hardware cheapens, human time is becoming more precious than computer time.

    In every piece of code I write, I am continually conscious of writing in a way that will make the code easy to maintain and extend in the future. It seems that for the majority of applications being written today, efficiency should be defined in terms of development and maintenance (3 & 4 above).

    It would be interesting, though, to work on a project where CPU time was the highest priority. Maybe someday... :-)

    --Dave

Re: What does "efficient" mean?!?
by ignatz (Vicar) on Jan 15, 2002 at 20:35 UTC
    The only thing that I would add would be community. The languages support in terms of people and code. This has always been Perl's trump card. Perl's core open source values mean that instead of having to swim through seas of commercial hype to find a solution, you just go the CPAN and get the job done.
Re: What does "efficient" mean?!?
by Albannach (Prior) on Jan 15, 2002 at 20:39 UTC
    To me efficiency means the ratio of output resources to input resources, and the problem as you noted is how best to measure the input and output. You've come up with several specific ones that apply to IT development, but a problem of bias arises when measures are taken individually. One solution to this is to estimate economic efficiency. In my line of work we often use a concept known as generalized cost in which we estimate and/or calculate dollar values for just about anything you can imagine - it's the only way to do some of the modelling and simulation in transportation planning (for interest, the other most common generalized cost unit is time, but it is often much more difficult for people to convert things into units of time). Though I hasten to add that it is just as simplistic a view as any other, it has the benefit of combining normally disparate measures.

    In your examples then, one could use generalized cost to calculate the values of different approaches to a specific project (subject of course to one's ability to reliably estimate things like development time and maintenance costs) and come up with different ways to satisfy the same set of project goals. In the extreme it could end up with a choice between hand-coded assembler running on a 80386 (high development and maintenance cost but low CPU and RAM cost) and perhaps Perl on a present-day off-the-shelf system. While the choice may be a no-brainer to most readers, it still may be an interesting exercise and could reveal something surprising about the project specifications, and how they may be altered, remembering that efficiency depends on both the input and output, and it may be a mistake to fix either side of the ratio too early.

    After the best analysis however, one is still dealing with the real world, where a project honestly intended to be a temporary fix ends up in use for years. For this reason, any planning exercise based solely on calulating efficiency and effectiveness will be doomed to fail, unless a good effort is expended on examining the sensitivity of each assumption to unexpected changes ("what happens to our maintenance cost assumption if ...", or "what if our compiler vendor ..."). The project may still fail, but at least there will be a better chance of anticipating the failure and mitigating the losses.

    --
    I'd like to be able to assign to an luser

      "After the best analysis however, one is still dealing with the real world, where a project honestly intended to be a temporary fix ends up in use for years.

      Well this statement hits the nail on the head, doesn't it?

      No matter how many places I've worked -- and we're nearly into the 30's now, in terms of how many -- having been a consultant for eighteen years), I've learned: there is no such thing as a "temporary fix." All but two of such things that I've personally worked on are (AFAIK) still in use today. And the two that aren't are currently in my care for rewrites.

      ++Albannach. If I had any votes left today I'd use one for this.

      dmm

Re (tilly) 1: What does "efficient" mean?!?
by tilly (Archbishop) on Jan 15, 2002 at 22:38 UTC
    As I like to say, Every good thing you can do, has a corresponding cost. What efficient in any domain means is that the trade-offs have been chosen to optimize for your problem space.

    But there are four important observations that come up again and again.

    The first is that there is a sharp division between things that tend to be hard barriers and things that tend to be soft. Things like raw performance and memory use tend to be hard barriers. If it won't run on your average machine in an acceptable time, your solution isn't acceptable. No arguing. But once you pass this threshold you quickly get into a region where people won't care if you cut memory use in half and doubled performance. While there is a grey area, most programs tend to be pretty squarely be on one side or the other. But things like programmer time are much softer barriers. In that situation you want to do the best that you can on the soft barriers while hitting your minimums on the hard.

    The second observation is that few people will be able to predict, before starting a problem, what kinds of requirements and issues you will have. The cases where people do know that tend to be ones where said people have solved that problem (or very similar ones) several times, and so can judge from experience. Therefore up front designs done in a vacuum almost always solve the wrong problems. With rigid development environments, you have to suffer. With more flexible and dynamic ones, it is more appropriate to follow the old machine-gunner's maxim of Ready! Fire! Aim! (ie Constantly adjust your aim based on feedback after you start - in the case of a machine gun you get feedback from where your tracer bullets go.)

    The third basic observation is that thanks to Moore's law, the ease of making all of your hard limits is constantly improving. That means that the relative importance of soft versus hard limits changes with each generation of technology. (Which is why it is now feasible to do serious software development in slow bloated languages like Perl.)

    And the final observation is that optimizing for maintainability first generally gets good results on all criteria of interest. First of all your code is maintainable. Since most of the cost is in maintainance, that cuts overall cost. Since debugging is a large fraction of initial development time and cost, making that easier cuts initial development time and cost. Since maintainable code is well-modularized, should you run into performance or memory problems, it is generally fairly easy to profile and then optimize a relatively small section of code to improve that. And if all else fails, well you have an easy to read prototype for your rewrite. (All else generally doesn't fail though.)

    So efficiency means a lot of things. But whatever it means for you, the odds are pretty good that you can get away with optimizing for maintainability first, and everything else second.

Re: What does "efficient" mean?!?
by dws (Chancellor) on Jan 15, 2002 at 23:45 UTC
    For performance tuning, nothing beats having your hands on a working system. A tool/language that is more effective for development can get you to a working system faster, leaving you more time to study and profile. And often times that's enough to win out over a more CPU/RAM efficient language that takes longer to develop with.

    In my career I've seen Smalltalk systems win out over C++ systems, either by outperforming them or by actually finishing ("We could never have build this with C++"); and I've seen a 100KLOC Perl application server win out over Java.

    Getting there first can give you a big advantage.

Re: What does "efficient" mean?!?
by mstone (Deacon) on Jan 16, 2002 at 04:57 UTC

    While tilly's post above is excellent, I'd like to approach the problem from a different angle.

    The word 'efficient' is an adjective. It modifies a noun.

    'Efficient' means nothing by itself. You can be 'space efficient', 'cost efficient', 'time efficient', or any number of other things, but you're always using the word 'efficient' relative to some other standard. When people start talking about raw 'efficiency', they're using undefined terms, and may as well be arguing about how 'blue' Perl is.

    Now I know that people often use 'efficient' to mean 'aggregate efficiency across N different criteria', but if you don't actually have a weighted list of criteria, you're talking cow pies. That's especially true in programming, where we have so many standards working in opposition to each other. You can make something more space efficient by compressing it, or you can make it more processing efficient by expanding it to its final form. And given various hardware latencies, neither pure solution may be particularly efficient with regard to time (unpacking can be slow, but so is stalling the CPU because your data structures keep clobbering the L2 cache). The solution with the best aggregate efficiency depends entirely on how you choose to weigh the options.

    When people start talking about efficiency, my first question is always "why should I care?" That makes some people testy, because they put 'Efficiency' right up there with 'God', 'Mom', 'Apple Pie', and other totems of indisputable good. When they say, "because it's Efficient," you can usually substitute, "because God is on my side," without changing their argument much. But efficiency is a measurement, not an end unto itself. If you can't state a good reason to care about a particular efficiency, the effort of creating it won't produce any usable output, therefore pursuing that efficiency is itself inefficient.. so there, checkmate, nyah-nyah-nyah. ;-)

    People usually start talking about efficiency when they want to justify their decision to use a particular language. They don't care about numbers, which is good, because the numbers tend to show that one high level language is just about as good as another, and that productivity varies from programmer to programmer with at least a 1000:1 spread in any given language (one minute of typing something you know -v- two days of reading manuals and experimenting).

    Me, I use Perl becuase I like it.

Re: What does "efficient" mean?!?
by Necos (Friar) on Jan 16, 2002 at 16:10 UTC
    My job requires that certain things be done in a certain time with a certain budget. That means (obviously), that I have to work with whatever tools I have at my disposal to get the job done. That would be simple if I was as much of a Perl hacker as japhy. However, I'm still far away from that level of Perl knowledge, nor do I have a problem with not being as skilled a Perl hacker as the rest of the monks. I'll achieve the skill one of the days (maybe years...).

    I only have experience with Assembler (theoretical experience mostly, very little code...), FORTRAN (lots of experience since I'm a physics major), VB (I thought I'd learn some VB for fun...), and C (again, theoretical mostly, some actual code). The language I know the most about (even with my limited knowledge) is Perl. However, since Perl is very closely tied to C/C++, it's no surprise that I'm coming to understand C/C++ a little more. Of course, now it's time to get back to the subject at hand.

    Since most inputs are fixed for most projects, effieciency is what you make it out to be. The only thing your project manager/boss/whatever will care about is that the project gets done. It does not matter how you get to the end of the road, only that you get there. If you can use Perl to do it in one day, and still meet all of the requirements, use Perl (even if it is bloated). If you can do it in 15 minutes in C/C++ with astonishing speed, then do it.

    I don't think the question is whether or not a programming language is efficient. The question should be whether or not the language is suited for the task (every so often, machine speed will rule certain languages out). In most cases, any language will do (most of the time, the machines running the code are fairly strong. e.g., P133 or better). It then becomes a case of preference, as well as knowledge of that language. One person might say "Java is my sword!" and decide to code every application in Java. That's all fine and dandy. If someone can code the same thing in C/C++, then that's just the old TMTOWTDI motto so common in the Perl community.

    With all else beind held equal (the infamous Economics line), use what you know best and chances are you will be "efficient." If you always have to spend 80% of the time trying to figure out which language to pick from the 15 you know, then you definitely are approaching problem solving from the wrong angle. I guess the fact that I only know Perl makes picking languages quite easy for me. ^_~

    "Never ask what you can do for a language. Only ask why the language was made for you."

    Theodore Charles III
    Network Administrator
    Los Angeles Senior High
    4650 W. Olympic Blvd.
    Los Angeles, CA 90019
    323-937-3210 ext. 224
    email->secon_kun@hotmail.com
Re: What does "efficient" mean?!?
by dmmiller2k (Chaplain) on Jan 20, 2002 at 06:04 UTC
    "(The astute observer notes that I didn't mention VBA. That's cause it's more of a fungus and not a computer language.

    It's a fungus that grows on you (that is, if you're not a professional programmer.:-)

    dmm

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://138919]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (12)
As of 2014-09-30 19:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (381 votes), past polls