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

Groups > comp.programming > #5157

Re: compiling python

Show all headers | View raw

On 24/01/2015 23:54, Kaz Kylheku wrote:
> On 2015-01-24, Bartc <bc@freeuk.com> wrote:

>>>     (defun test ()
>>>       (do ((i 0 (1+ i)))
>>>           ((> i 100000000))
>>>         (declare
>>>           (type fixnum i)
>>>           (optimize (speed 3) (safety 0)))))

>> OK, let's say 2.1 seconds for a billion. That compares very well with
>> the above timings (ignoring the fact that your machine might be faster
>> or slower than mine).
>
> One billion doesn't fit into a fixnum on the 32 bit version of Clozure Common
> Lisp. On the 64 bit version I get more meaningful looking timings.
>
> ? (time (test))
> (TEST)
> took 1,329,000 microseconds (1.329000 seconds) to run.
>
> Now with the version with declarations, there is a difference:
>
> ? (time (test))
> (TEST)
> took 345,000 microseconds (0.345000 seconds) to run.

That suggests your machine is at least double the speed of mine, which 
takes a minimum of 0.7 seconds to perform the loop (and 0.0 to not 
execute the loop, but that is of no interest).

I suppose that for high performance dynamic languages with timings at 
this end of the scale, then static type information can be a useful 
extra tweaking method, once all the obvious optimisations have been 
taken care of.

But with un-accelerated Python, Ruby, Perl, etc, those are so 
inefficient that throwing type hints at them would make little 
difference. (Seed7, for example, had an even slower interpreter, despite 
being 100% statically typed. It relied on being compiled to C code to 
get up to speed.)

In my language, type hints could at most double the speed of simple 
benchmarks, but caused many problems with the interpreter because they 
really demanded that custom native code sequences were generated, and 
that data became unboxed, as well as making it harder to have 
auto-ranging numeric types. It would have turned it into a very 
different, less dynamic language.

It is usually much better, IMO, if you can write dynamic code /without/ 
having to be tied down by using hints.

-- 
Bartc

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

Thread

compiling python fir <profesor.fir@gmail.com> - 2015-01-09 15:36 -0800
  Re: compiling python BartC <bc@freeuk.com> - 2015-01-09 23:50 +0000
    Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-09 15:59 -0800
      Re: compiling python BartC <bc@freeuk.com> - 2015-01-10 11:45 +0000
        Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-10 07:09 -0800
    Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-10 19:19 +0000
      Re: compiling python BartC <bc@freeuk.com> - 2015-01-10 22:02 +0000
        Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-11 10:52 -0800
        Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-11 19:24 +0000
          Re: compiling python BartC <bc@freeuk.com> - 2015-01-11 20:23 +0000
          Re: compiling python BartC <bc@freeuk.com> - 2015-01-24 15:01 +0000
            Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-24 16:58 +0000
              Re: compiling python Bartc <bc@freeuk.com> - 2015-01-24 19:18 +0000
                Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-24 23:54 +0000
                Re: compiling python Bartc <bc@freeuk.com> - 2015-01-25 01:26 +0000
  Re: compiling python Robert Wessel <robertwessel2@yahoo.com> - 2015-01-09 18:13 -0600
    Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-09 16:27 -0800
  Re: compiling python Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-12 18:28 +0100

csiph-web