Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5150

Re: python..

Show all headers | View raw

On 2015-01-22, malcolm.mclean5@btinternet.com <malcolm.mclean5@btinternet.com> wrote:
> On Tuesday, January 20, 2015 at 7:25:16 PM UTC, Kaz Kylheku wrote:
>>
>> Even when efficiency is critical, it is rarely (almost never)
>> critical in such a way that nearly every line of an application 
>> has to be rewritten in something else.
>> 
> Though that's not true for code size efficiency or memory efficiency.

Yes it is, because high level languages like Python have excellent size
efficiency compared to low-level languages. You need a page of C to do the
equivalent of one line of something like Python.

So if what you care about is size efficiency, you'd be crazy to even think
about rewriting anything in C from a high level language.

Python will impose some minimum footprint, however, due to its run-time
support: the cruft you need just to do hello, world.

Whether or not you can beat that footprint (python kernel, libs plus python
program) with a C program depends on what the Python program does.  Also, on
whether you can completely eliminate the python materials from the target
system (what if there are numerous other Python applications? They all
have to be rewritten if the run-time support stuff is to be removed.)

Hosted C also has fairly sizeable minimum footprints. A hello executable
may be small, but the library it is linked to isn't all that small.
Making small images in C means using a freestanding implementation.

Converting a Python program which does something moderately complicated to a
freestanding C implementation in which you have to write your own strcpy if you
want it ... haha, have fun!

> Very commonly, an application that uses 4095 bytes is fine, one
> that uses 4097 completely unusable. Also, commonly, designers 

I would say, not very commonly. Today it is false economy to use
such a microcontroller when for pennies more you can have one that
supports a bigger, better, more future-proof application.

If you have to fit code into 4095 bytes, issues like readability and
maintainability pretty much go the window anyway. All that matters is that some
fraction of a dollar is saved per circuit board by not using the higher model
chip that provides 32767 bytes for the program, and over the projected units
sold, that saving more than exceeds the extra salary paid to someone to figure
out how to cram it all into 4095. (If not, it was false economy.)

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

python.. fir <profesor.fir@gmail.com> - 2015-01-06 06:20 -0800
  Re: python.. malcolm.mclean5@btinternet.com - 2015-01-06 11:24 -0800
    Re: python.. fir <profesor.fir@gmail.com> - 2015-01-06 16:32 -0800
    Re: python.. BartC <bc@freeuk.com> - 2015-01-09 13:02 +0000
  Re: python.. Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-12 18:22 +0100
    Re: python.. Mark Carroll <mtbc@bcs.org> - 2015-01-12 17:49 +0000
      Re: python.. malcolm.mclean5@btinternet.com - 2015-01-13 16:09 -0800
        Re: python.. Robert Wessel <robertwessel2@yahoo.com> - 2015-01-15 02:43 -0600
        Re: python.. Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-20 13:02 +0100
          Re: python.. Kaz Kylheku <kaz@kylheku.com> - 2015-01-20 19:25 +0000
            Re: python.. Kaz Kylheku <kaz@kylheku.com> - 2015-01-20 19:26 +0000
            Re: python.. malcolm.mclean5@btinternet.com - 2015-01-21 17:39 -0800
              Re: python.. Kaz Kylheku <kaz@kylheku.com> - 2015-01-22 02:29 +0000
    Re: python.. fir <profesor.fir@gmail.com> - 2015-01-12 10:53 -0800
      Re: python.. Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-13 18:29 +0100
        Re: python.. BartC <bc@freeuk.com> - 2015-01-13 18:15 +0000
        Re: python.. fir <profesor.fir@gmail.com> - 2015-01-13 15:16 -0800
          Re: python.. Philip Shaw <jnufcvyvuc@tznvy.pbz> - 2015-01-23 04:46 +0000

csiph-web