By: FritzR (fritzr_gc.delete@this.yahoo.com), February 24, 2008 3:08 pm
Room: Moderated Discussions
There are definitely tradeoffs between ease of coding and speed of execution.
I started with Sinclair & Commodore Basics. Both very easy to code, both very slow comapred to the same programs coded in Z80 or 6502. The main difference was that a complex program written in 3 or 4 days in Basic might take 3 or 4 weeks to complete in assembly. An extreme example is an assembler intended for the unexpanded VIC-20. The basic version took a couple of weeks to complete, the final assembly version which offered symbolic assembly with module loading from tape or disk took a couple of years, but was 100x faster and used 1683 bytes of program code. A bloated version was completed in a couple of months but since that version used 3700+ bytes on a machine that had less than 3500 bytes available I did not consider it to be a usable application :D
Later when I managed a DEC MicroVAX I wrote a report generator. It was a very simple problem, generate 2 standard reports from the vendor supplied system and extract the information needed by production in the form of a third report. First version written in DCL took 15 minutes to digest the 2 reports, the second version written in C did the job in 10 secs. The first version was written in an afternoon. The second version took much longer as I needed to learn a new language to finish it. Still don't use C very much, perl is much easier and does an adequate job for my needs.
In general programs written in DCL take much less time to write, but much more time to execute. So for a one off that won't be used much write it in the slow easy to code language. For the program that won't be needed for a couple of years, but will be used hundreds of times a day assign a team of assembly programmers to code the program and pay for ongoing maintenance to make sure that the code is updated and ported to each new machine purchased. I still remember the mention of the retirement of the maintenance contract for last 2 DEC computers using TOPS-20 OS. One of them was being retired, so it was decided that since only 1 machine would still operate (legacy code :P ) It was in the best interests of DEC to transfer maintenance responsibility to the enduser. Someone earlier mentioned Boeing has this problem with solutions written in a manner that requires MS-DOS support. High level *slow* languages are usually much easier to port than are low level code highly optimized for that powerful machine purchased 30 yrs ago :D
Also beware of commercial off the shelf solutions. If you didn't buy the source code in a portable language, you'll be paying later to port all your data and procedures to the next "solution". Of course it is a 5 minute "programming" solution to most problems to check the software listings at NewEgg, but is a real headache when you find that the wonderful tool will no longer work with the new version of Windows/*nix/MacOS etc.
This problem is exacerbated by tweaking the source to run fastest on the hardware that was available at the time of creation. Get it running at an acceptable speed when written in a slower general purpose portable language and ongoing maintenance costs go through the floor. Get the source, train your coders to avoid fancy tricks and keep the optimizing compilers for your CURRENT hardware and OS up to date. No longer any need to rewrite the entire software library every few years. You won't have the fastest execution, but most businesses care more about the cost per transaction and are willing to buy more powerful hardware if the the total cost per transaction is lower than it would be if the money was invested in a programming team that would rewrite the code base and then tweak it every time the hardware changed.
JasonB (no@spam.com) on 2/20/08 wrote:
---------------------------
>Ray (a@b.c) on 2/20/08 wrote:
>---------------------------
>>I have no stake in the current thread, but I think it worth pointing out that the
>>"python is 50x slower than C" argument is somewhat misleading, as it is only true
>>for first-cut solutions to a problem.
>
>I actually quite like Python and I'm thinking of using it as an end-user macro language for our software.
>
>However, did say "an average of 50x slower", and not "python is 50x slower
>than C". If you look at the link I provided you can see cases where it was just
>as fast as C (regex-dna) and others where it is very close (pidigits, thread-ring).
>There are also others where it is nearly 300 times slower (recursive). You
>need to be careful with averages; my statement was intended to encourage the reader
>to look deeper and see the actual results. There is no question that it is less
>efficient in general, however, and as soon as programmers have to start putting
>in effort to improve the runtime efficiency, the purported "programmer productivity"
>benefits and the ease-of-use that David was talking about start to decline.
>
>>(Who has written more lines of C in his life than in any other language, regrettably)
>
>For me it's C++, but I think programmer productivity differences are overstated
>(probably a bit like the "50x slower than C" statement) -- either that, or I'm unusually
>fast at C++ or incredibly slow at Python. My main motive for wanting to use it for
>end users is that it is easier to teach them how to use it, since they aren't programmers,
>and I don't expect runtime efficiency to matter for the majority of their uses.
I started with Sinclair & Commodore Basics. Both very easy to code, both very slow comapred to the same programs coded in Z80 or 6502. The main difference was that a complex program written in 3 or 4 days in Basic might take 3 or 4 weeks to complete in assembly. An extreme example is an assembler intended for the unexpanded VIC-20. The basic version took a couple of weeks to complete, the final assembly version which offered symbolic assembly with module loading from tape or disk took a couple of years, but was 100x faster and used 1683 bytes of program code. A bloated version was completed in a couple of months but since that version used 3700+ bytes on a machine that had less than 3500 bytes available I did not consider it to be a usable application :D
Later when I managed a DEC MicroVAX I wrote a report generator. It was a very simple problem, generate 2 standard reports from the vendor supplied system and extract the information needed by production in the form of a third report. First version written in DCL took 15 minutes to digest the 2 reports, the second version written in C did the job in 10 secs. The first version was written in an afternoon. The second version took much longer as I needed to learn a new language to finish it. Still don't use C very much, perl is much easier and does an adequate job for my needs.
In general programs written in DCL take much less time to write, but much more time to execute. So for a one off that won't be used much write it in the slow easy to code language. For the program that won't be needed for a couple of years, but will be used hundreds of times a day assign a team of assembly programmers to code the program and pay for ongoing maintenance to make sure that the code is updated and ported to each new machine purchased. I still remember the mention of the retirement of the maintenance contract for last 2 DEC computers using TOPS-20 OS. One of them was being retired, so it was decided that since only 1 machine would still operate (legacy code :P ) It was in the best interests of DEC to transfer maintenance responsibility to the enduser. Someone earlier mentioned Boeing has this problem with solutions written in a manner that requires MS-DOS support. High level *slow* languages are usually much easier to port than are low level code highly optimized for that powerful machine purchased 30 yrs ago :D
Also beware of commercial off the shelf solutions. If you didn't buy the source code in a portable language, you'll be paying later to port all your data and procedures to the next "solution". Of course it is a 5 minute "programming" solution to most problems to check the software listings at NewEgg, but is a real headache when you find that the wonderful tool will no longer work with the new version of Windows/*nix/MacOS etc.
This problem is exacerbated by tweaking the source to run fastest on the hardware that was available at the time of creation. Get it running at an acceptable speed when written in a slower general purpose portable language and ongoing maintenance costs go through the floor. Get the source, train your coders to avoid fancy tricks and keep the optimizing compilers for your CURRENT hardware and OS up to date. No longer any need to rewrite the entire software library every few years. You won't have the fastest execution, but most businesses care more about the cost per transaction and are willing to buy more powerful hardware if the the total cost per transaction is lower than it would be if the money was invested in a programming team that would rewrite the code base and then tweak it every time the hardware changed.
JasonB (no@spam.com) on 2/20/08 wrote:
---------------------------
>Ray (a@b.c) on 2/20/08 wrote:
>---------------------------
>>I have no stake in the current thread, but I think it worth pointing out that the
>>"python is 50x slower than C" argument is somewhat misleading, as it is only true
>>for first-cut solutions to a problem.
>
>I actually quite like Python and I'm thinking of using it as an end-user macro language for our software.
>
>However, did say "an average of 50x slower", and not "python is 50x slower
>than C". If you look at the link I provided you can see cases where it was just
>as fast as C (regex-dna) and others where it is very close (pidigits, thread-ring).
>There are also others where it is nearly 300 times slower (recursive). You
>need to be careful with averages; my statement was intended to encourage the reader
>to look deeper and see the actual results. There is no question that it is less
>efficient in general, however, and as soon as programmers have to start putting
>in effort to improve the runtime efficiency, the purported "programmer productivity"
>benefits and the ease-of-use that David was talking about start to decline.
>
>>(Who has written more lines of C in his life than in any other language, regrettably)
>
>For me it's C++, but I think programmer productivity differences are overstated
>(probably a bit like the "50x slower than C" statement) -- either that, or I'm unusually
>fast at C++ or incredibly slow at Python. My main motive for wanting to use it for
>end users is that it is easier to teach them how to use it, since they aren't programmers,
>and I don't expect runtime efficiency to matter for the majority of their uses.
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 04:24 AM |
And the links.. | Anders Jensen | 2008/02/14 04:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 10:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 11:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 05:43 PM |
Disappointing.. | David Patterson | 2008/02/15 11:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 05:01 PM |
Disappointing.. | anon | 2008/02/15 08:54 PM |
Disappointing.. | JasonB | 2008/02/19 07:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 06:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 11:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 06:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 11:41 AM |
Disappointing.. | Zan | 2008/02/25 10:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 09:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 06:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 01:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 10:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 01:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 08:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 01:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 10:04 AM |
And the links.. | Howard Chu | 2008/02/14 12:58 PM |
I take some of that back | Howard Chu | 2008/02/14 01:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 02:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 02:24 PM |
And the links.. | iz | 2008/02/17 10:55 AM |
And the links.. | JasonB | 2008/02/17 07:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:54 PM |
And the links.. | JasonB | 2008/02/18 10:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 07:01 PM |
And the links.. | iz | 2008/02/20 10:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:37 PM |
And the links.. | JasonB | 2008/02/20 06:28 PM |
And the links.. | JasonB | 2008/02/17 06:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 02:27 PM |
And the links.. | JasonB | 2008/02/18 10:00 PM |
And the links.. | JasonB | 2008/02/19 03:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 04:29 PM |
And the links.. | JasonB | 2008/02/20 06:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 11:07 AM |
And the links.. | Howard Chu | 2008/02/14 01:16 PM |
And the links.. | Jukka Larja | 2008/02/15 03:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 11:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 12:49 PM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 03:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 05:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 09:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 04:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 10:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 01:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 12:44 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 03:25 PM |
Average programmers | anon | 2008/02/18 12:40 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 08:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 03:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 06:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 03:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 03:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 05:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 01:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 02:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 08:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 08:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 05:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 06:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 02:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 09:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 09:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 01:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 02:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 04:35 AM |
C++ for beginners | Michael S | 2008/03/10 05:16 AM |
C++ for beginners | JasonB | 2008/03/10 06:35 AM |
C++ | Michael S | 2008/03/10 04:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 11:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 02:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 03:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 08:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 01:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 08:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 08:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 11:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 02:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 04:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 03:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 09:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 01:23 AM |
efficient HLL's | Michael S | 2008/03/05 02:45 AM |
efficient HLL's | Wilco | 2008/03/05 05:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 07:11 PM |
efficient HLL's | Wilco | 2008/03/06 02:27 PM |
efficient HLL's | anon | 2008/03/05 08:20 AM |
And the links.. | Groo | 2008/02/17 04:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 02:33 AM |