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

Groups > comp.lang.c > #102407 > unrolled thread

Why Python is slow

Back to article view | Back to comp.lang.c

Contents

  Why Python is slow thunderbirdmember@gmail.com - 2017-01-24 10:22 -0800
    Re: Why Python is slow Richard Heathfield <rjh@cpax.org.uk> - 2017-01-24 18:33 +0000
    Re: Why Python is slow Richard Heathfield <rjh@cpax.org.uk> - 2017-01-24 20:14 +0000
      Re: Why Python is slow luser droog <luser.droog@gmail.com> - 2017-01-26 10:13 -0800
      Re: Why Python is slow Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:50 -0800
    Re: Why Python is slow bart4858@gmail.com - 2017-01-24 13:21 -0800
    Re: Why Python is slow BartC <bc@freeuk.com> - 2017-01-24 22:23 +0000
    Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-24 17:11 -0800
      Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-24 19:26 -0800
      Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-25 12:50 -0800
        Re: Why Python is slow BartC <bc@freeuk.com> - 2017-01-25 21:52 +0000
          Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-25 14:30 -0800
            Re: Why Python is slow BartC <bc@freeuk.com> - 2017-01-25 22:59 +0000
              Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-27 13:20 -0800
        Re: Why Python is slow DFS <nospam@dfs.com> - 2017-01-25 19:22 -0500
          Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-26 13:40 -0800
    Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-25 10:29 +0100
      Re: Why Python is slow gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-25 10:38 +0000
      Re: Why Python is slow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-26 06:44 -0800
        Re: Why Python is slow Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 15:00 +0000
          Re: Why Python is slow Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-26 17:23 +0000
            Re: Why Python is slow supercat@casperkitty.com - 2017-01-26 09:42 -0800
              Re: Why Python is slow Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-26 18:24 +0000
        Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-26 16:14 +0100
          Re: Why Python is slow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-26 12:49 -0800
            Re: Why Python is slow Robert Wessel <robertwessel2@yahoo.com> - 2017-01-26 15:11 -0600
            Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-26 23:56 +0100
          Re: Why Python is slow Keith Thompson <kst-u@mib.org> - 2017-01-26 15:20 -0800
            Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-27 09:31 +0100
        Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 07:24 -0800
          Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 07:57 -0800
            Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 08:46 -0800
          Re: Why Python is slow supercat@casperkitty.com - 2017-01-27 08:06 -0800
            Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 08:39 -0800
              Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 13:29 -0800
    Re: 3**3**3**3 Noob <root@127.0.0.1> - 2017-01-27 14:33 +0100

Page 1 of 2  [1] 2  Next page →

#102407 — Why Python is slow

  Everyone saying that. And my neighbour is all upset
about something getting out of the house and complaining.
He doesn't like his car because he stuns it every time
he gets in or out. He don't realise that he stuns his mind too.
Obviously he wants a new car. But he is stuck here being a student.

  Python is easy to write but is slow executing things.
So how much slower Python is compared to C. Experiment
was done on a nested loop of the same features in both
languages with same number of iterations and same logic:

loop.py    0.219s
loop.pyc  0.314s
loop.c	 0.088s 

  For some reason pre-compiled python object ran slower 
than interpreted script.

[toc] | [next] | [standalone]

#102408

On 24/01/17 18:22, thunderbirdmember@gmail.com wrote:

>   Python is easy to write but is slow executing things.

Right. Isn't it nice to have choices?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102413

On 24/01/17 19:45, Stefan Ram wrote:
> thunderbirdmember@gmail.com writes:
>> Python is easy to write but is slow executing things.
>
>   Just a few days ago, I wrote my first Python expression
>   and fed it to an interpreter. It was
>
> 3**3**3**3
>
>   . Ok, it was not the very first Python expression I ever
>   entered, but one of the first ten.
>
>   How long does it take to evaluate it? (I don't know, because
>   I eventually aborted the interpreter while it was still
>   evaluating this expression.)

What did you expect? :-)

3**3**3**3 is

3**3**27 is

3**7625597484987

which is going to tax the capabilities of most processors, no matter 
what language you use to write the code.

3 to the power 3 took 0.008 seconds on my system.

3 to the power 27 took 0.018 seconds.

I bottled out of the full monty, but:

3 to the power 81 took 0.029 seconds.
3 to the power 243 took 0.042 seconds.
3 to the power 729 took 0.111 seconds.
3 to the power 2187 took 0.740 seconds.
3 to the power 6561 took 6.427 seconds.
3 to the power 19683 took 56.875 seconds.

Multiplying the power term by 3, then, seems to multiply the run-time by 
about 9. So we can estimate the time it would take (machine resources 
permitting) to perform 3 to the power 7625597484987 as 56.875 * (9 to 
the power 22), which is roughly 1,774,861,793,744,000 years.

You can probably cut this time down a lot by using bigger bigits (my 
bigits are deliberately small, 0-255).

If we were to make the rather optimistic assumption that we could cut 
the time by a factor of 2^56 by using 64-bit bigits instead of 8-bit 
bigits, we could get the result in just over a Beatles week.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102480

On Tuesday, January 24, 2017 at 2:14:59 PM UTC-6, Richard Heathfield wrote:
> On 24/01/17 19:45, Stefan Ram wrote:
> > thunderbirdmember@gmail.com writes:
> >> Python is easy to write but is slow executing things.
> >
> >   Just a few days ago, I wrote my first Python expression
> >   and fed it to an interpreter. It was
> >
> > 3**3**3**3
> >
> >   . Ok, it was not the very first Python expression I ever
> >   entered, but one of the first ten.
> >
> >   How long does it take to evaluate it? (I don't know, because
> >   I eventually aborted the interpreter while it was still
> >   evaluating this expression.)
> 
> What did you expect? :-)
> 
> 3**3**3**3 is
> 
> 3**3**27 is
> 
> 3**7625597484987
> 
> which is going to tax the capabilities of most processors, no matter 
> what language you use to write the code.
> 
> 3 to the power 3 took 0.008 seconds on my system.
> 
> 3 to the power 27 took 0.018 seconds.
> 
> I bottled out of the full monty, but:
> 
> 3 to the power 81 took 0.029 seconds.
> 3 to the power 243 took 0.042 seconds.
> 3 to the power 729 took 0.111 seconds.
> 3 to the power 2187 took 0.740 seconds.
> 3 to the power 6561 took 6.427 seconds.
> 3 to the power 19683 took 56.875 seconds.
> 
> Multiplying the power term by 3, then, seems to multiply the run-time by 
> about 9. So we can estimate the time it would take (machine resources 
> permitting) to perform 3 to the power 7625597484987 as 56.875 * (9 to 
> the power 22), which is roughly 1,774,861,793,744,000 years.
> 
> You can probably cut this time down a lot by using bigger bigits (my 
> bigits are deliberately small, 0-255).
> 
> If we were to make the rather optimistic assumption that we could cut 
> the time by a factor of 2^56 by using 64-bit bigits instead of 8-bit 
> bigits, we could get the result in just over a Beatles week.
> 

Fwiw, my interpreter with GMP bignums just gives up, too:

proj/olmec$ ./olmec
        3⋆3
 27
        3⋆3⋆3
 7625597484987
        3⋆3⋆3⋆3
 inf

[toc] | [prev] | [next] | [standalone]

#102756

Richard Heathfield <rjh@cpax.org.uk> writes:

> [.. evaluating 3 ** 3 ** 3 ** 3 ..]
>
> 3 to the power 3 took 0.008 seconds on my system.
>
> 3 to the power 27 took 0.018 seconds.
>
> I bottled out of the full monty, but:
>
> 3 to the power 81 took 0.029 seconds.
> 3 to the power 243 took 0.042 seconds.
> 3 to the power 729 took 0.111 seconds.
> 3 to the power 2187 took 0.740 seconds.
> 3 to the power 6561 took 6.427 seconds.
> 3 to the power 19683 took 56.875 seconds.
>
> Multiplying the power term by 3, then, seems to multiply the
> run-time by about 9.  So we can estimate the time it would take
> (machine resources permitting) to perform 3 to the power
> 7625597484987 as 56.875 * (9 to the power 22), which is roughly
> 1,774,861,793,744,000 years.

The timings given suggest an algorithm that is O( n**2 ).  There
are faster (and also still practical) algorithms.

> You can probably cut this time down a lot by using bigger bigits
> (my bigits are deliberately small, 0-255).

For results of this size, a better way is to use an algorithm
that is O( n ** (log2 3) ) or O( n * log n * log log n ).  I
believe python uses an O( n ** (log2 3) ) algorithm.  It looks
like an O( n * log n * log log n ) algorithm could complete (if
running on a system with several terabytes of ram) in one or two
digits of CPU months.

[toc] | [prev] | [next] | [standalone]

#102414

On Tuesday, 24 January 2017 18:22:35 UTC, thunderb...@gmail.com  wrote:

>   Python is easy to write but is slow executing things.
> So how much slower Python is compared to C. Experiment
> was done on a nested loop of the same features in both
> languages with same number of iterations and same logic:
> 
> loop.py    0.219s
> loop.pyc  0.314s
> loop.c	 0.088s 

You're fortunate if Python is only two and a half times slower than C. Usually the differences are much greater. But then you haven't shown the task you're looping over. I suspect what is being executed isn't so much Python as the internal implementation of some high level features that are probably written in C anyway.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#102415

On 24/01/2017 19:45, Stefan Ram wrote:
> thunderbirdmember@gmail.com writes:
>> Python is easy to write but is slow executing things.
>
>   Just a few days ago, I wrote my first Python expression
>   and fed it to an interpreter. It was
>
> 3**3**3**3
>
>   . Ok, it was not the very first Python expression I ever
>   entered, but one of the first ten.
>
>   How long does it take to evaluate it?

Python will try and evaluate it as an integer. I think the answer has 
around a trillion (decimal) digits, so it will likely run out of memory 
first.

C won't have much luck either, not even using doubles, as the answer is 
outside the exponent range.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102416

On 1/24/2017 10:22 AM, thunderbirdmember@gmail.com wrote:
>   Everyone saying that. And my neighbour is all upset
> about something getting out of the house and complaining.
> He doesn't like his car because he stuns it every time
> he gets in or out. He don't realise that he stuns his mind too.
> Obviously he wants a new car. But he is stuck here being a student.
>
>   Python is easy to write but is slow executing things.
> So how much slower Python is compared to C. Experiment
> was done on a nested loop of the same features in both
> languages with same number of iterations and same logic:
>
> loop.py    0.219s
> loop.pyc  0.314s
> loop.c	 0.088s
>
>   For some reason pre-compiled python object ran slower
> than interpreted script.
>

Python is slow? Na. Its really slow, check this encryption technique out:

http://pastebin.com/raw/QarNLfn3

the code can be run online here:

https://repl.it/languages/python3

Here is output I get:
_____________________________
Chris M. Thomasson 8/20/2016
Reverse Iteration Fractal Cipher (RIFC)
Pre-Alpha Version: 0.0.0
In-Memory Byte Level Version
File based version is on its way
=======================================================



rifc:(fskey:(z:(-0.74543+0.11301j), c:[(0.677+0.2j), (-0.21-0.751j), 
(-0.0505+0.64j)], p:[4, 3, 5], r_n:2, n_n:3, hmack:hmac_skey_123))


original_plaintext, length: 80
______________________________________________
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
______________________________________________


ciphertext, length 42
______________________________________________
(649570f4addd71f8465a1aae6bc069ad)
(-0.11375803457697138-1.0685502316737907j)
(-0.1271064825318161+0.8348680631162264j)
(-0.9465802124429011-0.021669884533826154j)
(-0.7683793642809116+0.6958660388088035j)
(0.5937917954594152-0.6008683998579958j)
(-0.7533194789312488+0.39279573375297633j)
(0.9810984207110482-0.43839063971027215j)
(-1.039143097151175-0.15115901672983173j)
(0.7552941655462698+0.7042558870593708j)
(0.5938010468211017-0.6008231139526502j)
(0.2126122046980469-1.0146096378069278j)
(0.37856866737404404-0.7605684110457657j)
(0.9295372961578942-0.4885019921643779j)
(-0.9640543176348764-0.4816314805474917j)
(-0.19708500547902755-1.0137109728834568j)
(0.4243656694906026+0.9458066919042333j)
(0.052185152554679315-1.098221625269841j)
(0.9810985036408469-0.43839057374342194j)
(-1.0391430971506979-0.15115901672972512j)
(-0.031309836473818055-1.1021924436646868j)
(-0.7808135227088581+0.5722218415520595j)
(0.29551062115523563-0.9218862187288588j)
(1.0385789703812078-0.3703169644273795j)
(-1.0579145569213564-0.31092049409975675j)
(-1.0579219374236202-0.3108226222073398j)
(-0.6063592901243277-0.5950686377316392j)
(-0.7433921825449539+0.7896292737442576j)
(0.9680828314689215-0.0038328827487418113j)
(-0.17735283400653407-1.0349925564489764j)
(0.6579656932503363+0.8904258084005204j)
(-0.7819581804746235+0.531538345099241j)
(-1.0579769955329617-0.31092166521569914j)
(-0.3553756068743595-0.8030576853535909j)
(0.5212491869064347+0.9510148875045729j)
(-0.9806923348335188-0.4631155061539714j)
(1.0630282214859044-0.17700286890207792j)
(0.9450504847946626+0.02960360510159556j)
(-0.271900126007064-0.9069476993246169j)
(1.0306518161405818-0.11132538948998363j)
(-0.1773525590460382-1.0349930792622632j)
(-1.0250025736043362-0.12585144749250654j)
(0.16015441483333054-1.0656960691185335j)

______________________________________________


decrypted_plaintext, length: 80
______________________________________________
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
______________________________________________

_____________________________

Try to encrypt a couple of hundred gigs with that!

[toc] | [prev] | [next] | [standalone]

#102421

On 1/24/2017 5:11 PM, Chris M. Thomasson wrote:
> On 1/24/2017 10:22 AM, thunderbirdmember@gmail.com wrote:
>>   Everyone saying that. And my neighbour is all upset
>> about something getting out of the house and complaining.
>> He doesn't like his car because he stuns it every time
>> he gets in or out. He don't realise that he stuns his mind too.
>> Obviously he wants a new car. But he is stuck here being a student.
>>
>>   Python is easy to write but is slow executing things.
>> So how much slower Python is compared to C. Experiment
>> was done on a nested loop of the same features in both
>> languages with same number of iterations and same logic:
>>
>> loop.py    0.219s
>> loop.pyc  0.314s
>> loop.c     0.088s
>>
>>   For some reason pre-compiled python object ran slower
>> than interpreted script.
>>
>
> Python is slow? Na. Its really slow, check this encryption technique out:
>
> http://pastebin.com/raw/QarNLfn3
>
> the code can be run online here:
>
> https://repl.it/languages/python3
>
> Here is output I get:
> _____________________________
> Chris M. Thomasson 8/20/2016
> Reverse Iteration Fractal Cipher (RIFC)
> Pre-Alpha Version: 0.0.0
> In-Memory Byte Level Version
> File based version is on its way
> =======================================================
>
>
>
> rifc:(fskey:(z:(-0.74543+0.11301j), c:[(0.677+0.2j), (-0.21-0.751j),
> (-0.0505+0.64j)], p:[4, 3, 5], r_n:2, n_n:3, hmack:hmac_skey_123))
>
>
> original_plaintext, length: 80
> ______________________________________________
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>
> ______________________________________________
>
>
> ciphertext, length 42

Length 42 here means 42 complex numbers in the ciphertext, NOT 42 bytes. 
There is also HMAC key.


> ______________________________________________
> (649570f4addd71f8465a1aae6bc069ad)
> (-0.11375803457697138-1.0685502316737907j)
> (-0.1271064825318161+0.8348680631162264j)
> (-0.9465802124429011-0.021669884533826154j)
> (-0.7683793642809116+0.6958660388088035j)
> (0.5937917954594152-0.6008683998579958j)
[....]

[toc] | [prev] | [next] | [standalone]

#102449

On 1/24/2017 5:11 PM, Chris M. Thomasson wrote:
> On 1/24/2017 10:22 AM, thunderbirdmember@gmail.com wrote:
>>   Everyone saying that. And my neighbour is all upset
>> about something getting out of the house and complaining.
>> He doesn't like his car because he stuns it every time
>> he gets in or out. He don't realise that he stuns his mind too.
>> Obviously he wants a new car. But he is stuck here being a student.
>>
>>   Python is easy to write but is slow executing things.
>> So how much slower Python is compared to C. Experiment
>> was done on a nested loop of the same features in both
>> languages with same number of iterations and same logic:
>>
>> loop.py    0.219s
>> loop.pyc  0.314s
>> loop.c     0.088s
>>
>>   For some reason pre-compiled python object ran slower
>> than interpreted script.
>>
>
> Python is slow? Na. Its really slow, check this encryption technique out:
>
> http://pastebin.com/raw/QarNLfn3

Fwiw, Python is great wrt being able to quickly mock up a quick 
prototype of a "system". Imvvho, C is there to really implement that 
prototype, at a lower, and faster level.



Also, here is the most recent version of my Python crypto code, it goes 
even slower than the original:

http://pastebin.com/raw/Ms2wuvfq

I need to put this up on github. lol.

[toc] | [prev] | [next] | [standalone]

#102450

On 25/01/2017 20:50, Chris M. Thomasson wrote:
> On 1/24/2017 5:11 PM, Chris M. Thomasson wrote:

>> Python is slow? Na. Its really slow, check this encryption technique out:
>>
>> http://pastebin.com/raw/QarNLfn3
>
> Fwiw, Python is great wrt being able to quickly mock up a quick
> prototype of a "system". Imvvho, C is there to really implement that
> prototype, at a lower, and faster level.
>
>
>
> Also, here is the most recent version of my Python crypto code, it goes
> even slower than the original:
>
> http://pastebin.com/raw/Ms2wuvfq
>
> I need to put this up on github. lol.

You haven't told us how much faster the C version is.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102452

On 1/25/2017 1:52 PM, BartC wrote:
> On 25/01/2017 20:50, Chris M. Thomasson wrote:
>> On 1/24/2017 5:11 PM, Chris M. Thomasson wrote:
>
>>> Python is slow? Na. Its really slow, check this encryption technique
>>> out:
>>>
>>> http://pastebin.com/raw/QarNLfn3
>>
>> Fwiw, Python is great wrt being able to quickly mock up a quick
>> prototype of a "system". Imvvho, C is there to really implement that
>> prototype, at a lower, and faster level.
>>
>>
>>
>> Also, here is the most recent version of my Python crypto code, it goes
>> even slower than the original:
>>
>> http://pastebin.com/raw/Ms2wuvfq
>>
>> I need to put this up on github. lol.
>
> You haven't told us how much faster the C version is.

IIRC, about twice as fast. The code uses a lot of slow trig functions. 
Fwiw, here is a little prototype wrt the original along with all of the 
string operations:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/RIFC/cpp/ct_rifc_sample.cpp

The c++ version can be made to be much faster.

[toc] | [prev] | [next] | [standalone]

#102453

On 25/01/2017 22:30, Chris M. Thomasson wrote:
> On 1/25/2017 1:52 PM, BartC wrote:
>> On 25/01/2017 20:50, Chris M. Thomasson wrote:
>>> On 1/24/2017 5:11 PM, Chris M. Thomasson wrote:
>>
>>>> Python is slow? Na. Its really slow, check this encryption technique
>>>> out:
>>>>
>>>> http://pastebin.com/raw/QarNLfn3
>>>
>>> Fwiw, Python is great wrt being able to quickly mock up a quick
>>> prototype of a "system". Imvvho, C is there to really implement that
>>> prototype, at a lower, and faster level.
>>>
>>>
>>>
>>> Also, here is the most recent version of my Python crypto code, it goes
>>> even slower than the original:
>>>
>>> http://pastebin.com/raw/Ms2wuvfq
>>>
>>> I need to put this up on github. lol.
>>
>> You haven't told us how much faster the C version is.
>
> IIRC, about twice as fast. The code uses a lot of slow trig functions.

That's what I expected when I looked at your Python code. So there's not 
much in it really, as you can get double or half the speed just by 
switching C compilers.

It's not really about Python being slower, not on this test anyway. My 
experience is that when both languages execute the /same/ algorithm, 
with the steps being in the language itself rather than buried in a 
library, then CPython can easily be 100 times slower than gcc-O3.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102604

On 1/25/2017 2:59 PM, BartC wrote:
> On 25/01/2017 22:30, Chris M. Thomasson wrote:
>> On 1/25/2017 1:52 PM, BartC wrote:
>>> On 25/01/2017 20:50, Chris M. Thomasson wrote:
>>>> On 1/24/2017 5:11 PM, Chris M. Thomasson wrote:
>>>
>>>>> Python is slow? Na. Its really slow, check this encryption technique
>>>>> out:
>>>>>
>>>>> http://pastebin.com/raw/QarNLfn3
>>>>
>>>> Fwiw, Python is great wrt being able to quickly mock up a quick
>>>> prototype of a "system". Imvvho, C is there to really implement that
>>>> prototype, at a lower, and faster level.
>>>>
>>>>
>>>>
>>>> Also, here is the most recent version of my Python crypto code, it goes
>>>> even slower than the original:
>>>>
>>>> http://pastebin.com/raw/Ms2wuvfq
>>>>
>>>> I need to put this up on github. lol.
>>>
>>> You haven't told us how much faster the C version is.
>>
>> IIRC, about twice as fast. The code uses a lot of slow trig functions.
>
> That's what I expected when I looked at your Python code. So there's not
> much in it really, as you can get double or half the speed just by
> switching C compilers.
>
> It's not really about Python being slower, not on this test anyway. My
> experience is that when both languages execute the /same/ algorithm,
> with the steps being in the language itself rather than buried in a
> library, then CPython can easily be 100 times slower than gcc-O3.
>

I agree with all of that. Thank you.

:^)

[toc] | [prev] | [next] | [standalone]

#102454

On 1/25/2017 3:50 PM, Chris M. Thomasson wrote:

> Also, here is the most recent version of my Python crypto code, it goes
> even slower than the original:
>
> http://pastebin.com/raw/Ms2wuvfq
>
> I need to put this up on github. lol.


Nice.  How long did you work on that code, from beginning to current 
version?

[toc] | [prev] | [next] | [standalone]

#102499

On 1/25/2017 4:22 PM, DFS wrote:
> On 1/25/2017 3:50 PM, Chris M. Thomasson wrote:
>
>> Also, here is the most recent version of my Python crypto code, it goes
>> even slower than the original:
>>
>> http://pastebin.com/raw/Ms2wuvfq
>>
>> I need to put this up on github. lol.
>
>
> Nice.  How long did you work on that code, from beginning to current
> version?

IIRC, around 6-8 hours. I am not all that great with Python, and needed 
to look up some reference material on string handling and other things 
along the way. This version is still not at all up to par yet. Also, 
your question brings up other thoughts. I have spent many hours working 
on fractal encryption. This Python version is basically a crude mock up 
of the concept, that I am still trying to concretely nail down. The 
problem is that there is a shi%load of entropy sources generated by 
fractals, and trying to separate out the good from bad is difficult.

[toc] | [prev] | [next] | [standalone]

#102429

On 24/01/17 20:45, Stefan Ram wrote:
> thunderbirdmember@gmail.com writes:
>> Python is easy to write but is slow executing things.
> 
>   Just a few days ago, I wrote my first Python expression
>   and fed it to an interpreter. It was
> 
> 3**3**3**3
> 
>   . Ok, it was not the very first Python expression I ever
>   entered, but one of the first ten.
> 
>   How long does it take to evaluate it? (I don't know, because
>   I eventually aborted the interpreter while it was still
>   evaluating this expression.)
> 
>   But, if I would implement a program in C to do the same
>   calculation (with the same output precision), it might not
>   be much faster. In any case, it would take much more of my
>   development time.
> 

As you say, doing this sort of thing in C is a lot more work, even if
you use a ready made arbitrary precision arithmetic library.

But for a quick comparison, we can use "bc" on Linux - it is implemented
in C and can handle integers of any size (given unlimited processor time
and memory).  As as been pointed out, 3**3**3**3 is infeasible to
calculate.  But we can test this:

[david@davidquad ~]$ time (echo "3 ^ 100000" | bc > /dev/null )

real	0m0.302s
user	0m0.297s
sys	0m0.004s
[david@davidquad ~]$ time (echo "print 3 ** 100000" | python > /dev/null )

real	0m0.134s
user	0m0.119s
sys	0m0.013s


The time to interpret the commands is negligible.  Python is over twice
as fast as C here.

Of course, Python is not /really/ twice as fast as C - the run-time
python libraries that do the integer calculations are written in C (for
normal Python).  But it shows that for some purposes, Python is faster
than C in practice - because "in practice" covers the effort involved in
writing the code.  With good enough algorithms and good enough
implementations, C will be faster than Python - but you would have to
spend an inordinate effort to write C code that is faster than the
highly optimised C code in the Python runtime libraries.

[toc] | [prev] | [next] | [standalone]

#102430

In article <o69r1u$s39$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
...
>Of course, Python is not /really/ twice as fast as C - the run-time
>python libraries that do the integer calculations are written in C (for
>normal Python).  But it shows that for some purposes, Python is faster
>than C in practice ...

It shows no such thing.  It shows that, in some circumstances, Python is
faster than /bc/.  Both Python and bc are language implementations, thus
comparable.  Both are, as you noted, implemented in C, so comparing Python
with bc is an apples-to-apples comparison.

-- 
Religion is what keeps the poor from murdering the rich.

	- Napoleon Bonaparte -

[toc] | [prev] | [next] | [standalone]

#102464

On Wednesday, January 25, 2017 at 9:29:15 AM UTC, David Brown wrote:
> 
> Of course, Python is not /really/ twice as fast as C - the run-time
> python libraries that do the integer calculations are written in C (for
> normal Python).  But it shows that for some purposes, Python is faster
> than C in practice - because "in practice" covers the effort involved in
> writing the code.  With good enough algorithms and good enough
> implementations, C will be faster than Python - but you would have to
> spend an inordinate effort to write C code that is faster than the
> highly optimised C code in the Python runtime libraries.
>
The Python source code has generally been stolen from reference
implementations which have been floating around in cyberspace for
ages. Then they add a Python interface layer. So you don't work from
scratch, you nick the Python C sources and peel off the interface layer,
it's some effort but not equivalent to reinventing the FFT.

The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
in under just-noticeable time on my machine.

[toc] | [prev] | [next] | [standalone]

#102467

On 26/01/17 14:44, Malcolm McLean wrote:

<snip>

> The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> in under just-noticeable time on my machine.

That's actually quite a reasonable answer. I suppose it's the C way of 
telling us not to be so stupid.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web