On Thu, Mar 08, 2018 at 08:44:16AM +1100, Chris Angelico wrote:
> On Thu, Mar 8, 2018 at 8:36 AM, Python wrote:
> > On Mon, Mar 05, 2018 at 04:09:48PM -0800, Dan Stromberg wrote:
> >> On Mon, Mar 5, 2018 at 3:53 PM, Python wrote:
> >> > On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wro
On Thu, Mar 8, 2018 at 8:36 AM, Python wrote:
> On Mon, Mar 05, 2018 at 04:09:48PM -0800, Dan Stromberg wrote:
>> On Mon, Mar 5, 2018 at 3:53 PM, Python wrote:
>> > On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote:
>> >> > Python is often a preferred solution because it is often fan
On Mon, Mar 05, 2018 at 04:09:48PM -0800, Dan Stromberg wrote:
> On Mon, Mar 5, 2018 at 3:53 PM, Python wrote:
> > On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote:
> >> > Python is often a preferred solution because it is often fantastic for
> >> > rapid implementation and maintaina
On Mon, Mar 5, 2018 at 3:53 PM, Python wrote:
> On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote:
>> > Python is often a preferred solution because it is often fantastic for
>> > rapid implementation and maintainability. The GIL's interference
>> > with threaded code performance has
On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote:
> > Python is often a preferred solution because it is often fantastic for
> > rapid implementation and maintainability. The GIL's interference
> > with threaded code performance has, for me at least, on several
> > occasions been...
On Fri, 02 Mar 2018 14:45:55 -0600, Python wrote:
> On Mon, Feb 26, 2018 at 09:57:06AM +, Steven D'Aprano wrote:
>> Besides, if you want Python with no GIL so you can run threaded code,
>> why aren't you using IronPython or Jython?
>
> But this is just another oversimplified argument. In the
On Sat, Mar 3, 2018 at 7:45 AM, Python wrote:
> On Mon, Feb 26, 2018 at 09:57:06AM +, Steven D'Aprano wrote:
>> Besides, if you want Python with no GIL so you can run threaded code, why
>> aren't you using IronPython or Jython?
>
> But this is just another oversimplified argument. In the real
On Mon, Feb 26, 2018 at 09:57:06AM +, Steven D'Aprano wrote:
> Besides, if you want Python with no GIL so you can run threaded code, why
> aren't you using IronPython or Jython?
But this is just another oversimplified argument. In the real world
there rather often exist constraints which hav
On Tue, 27 Feb 2018 11:27:21 +, bartc wrote:
[...]
>> The built-in generator is using a completely different algorithm
>> though, so rate of generation isn't the entire story. How long is the
>> period of the one you're using? (How long before it loops?)
>
> I believe it's 5*2**1320480*(2**64
On 27/02/2018 02:27, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 12:57 PM, bartc wrote:
On 27/02/2018 00:35, Chris Angelico wrote:
Anyway, even this pure Python version can deliver pseudo random numbers at
some 200,000 per second, while the built-in generator does 450,000 per
second, so it
Christian Gollwitzer writes:
> George Marsaglia is a researcher who invented a couple of PRNGs which
> are both simple (one of the first was called KISS) yet surprisingly
> good.
s/is/was/
Sadly, he died a few years ago (2011).
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Am 27.02.18 um 03:27 schrieb Chris Angelico:
On Tue, Feb 27, 2018 at 12:57 PM, bartc wrote:
Anyway, even this pure Python version can deliver pseudo random numbers at
some 200,000 per second, while the built-in generator does 450,000 per
second, so it's not bad going.
The built-in generator
On Tue, Feb 27, 2018 at 12:57 PM, bartc wrote:
> On 27/02/2018 00:35, Chris Angelico wrote:
>>
>> On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
>> wrote:
>>>
>>> On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
>>>
You're still reimplementing the C code in Python, which is ineff
On 27/02/2018 00:35, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
wrote:
On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
You're still reimplementing the C code in Python, which is inefficient.
Have you considered going back to the *actual algorithm* and
im
On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
wrote:
> On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
>
>> You're still reimplementing the C code in Python, which is inefficient.
>> Have you considered going back to the *actual algorithm* and
>> implementing that idiomatically in Py
On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
> You're still reimplementing the C code in Python, which is inefficient.
> Have you considered going back to the *actual algorithm* and
> implementing that idiomatically in Python? I think you'll find that (a)
> the code is more readable,
On 26/02/2018 20:27, bartc wrote:
On 26/02/2018 19:50, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson
So what? Latency is latency. And whether it occurs over the
course of one heavily recursive algorithm that constitutes
the depth and breadth of an entire program (a la fi
On 26/02/2018 19:50, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson
So what? Latency is latency. And whether it occurs over the
course of one heavily recursive algorithm that constitutes
the depth and breadth of an entire program (a la fib()), or
it is the incremental cumu
On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson
wrote:
> On Monday, February 26, 2018 at 4:39:22 AM UTC-6, Steven D'Aprano wrote:
>> On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote:
>>
>> > On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
>> > [...]
>> > > Take the Fib
On Monday, February 26, 2018 at 4:39:22 AM UTC-6, Steven D'Aprano wrote:
> On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote:
>
> > On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
> > [...]
> > > Take the Fibonacci double-recursion benchmark. Okay, it
> > > tests how w
On 26/02/2018 17:05, Ben Bacarisse wrote:
bartc writes:
A C version is given below. (One I may have messed around with, which
I'm not sure works properly. For an original, google for Marsaglia and
KISS64 or SUPRKISS64.)
The version I know uses unsigned integers. Did you change then to signe
On Monday, February 26, 2018 at 3:59:40 AM UTC-6, Steven D'Aprano wrote:
> On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote:
> (We tried painting Go Faster stripes on the server, and it
> didn't work.)
Well of course the server won't work after you drip water-
based paint all over the circu
bartc writes:
> A C version is given below. (One I may have messed around with, which
> I'm not sure works properly. For an original, google for Marsaglia and
> KISS64 or SUPRKISS64.)
The version I know uses unsigned integers. Did you change then to signed?
For a Python version, go back to the
On 26/02/2018 15:09, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 2:02 AM, bartc wrote:
On 26/02/2018 14:04, bartc wrote:
On 26/02/2018 13:42, Ned Batchelder wrote:
Well, once you notice that the
Python code had N=1e5, and the C code had N=1e9 :) If you want to
experiment, with N=
On 2/26/18 10:09 AM, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 2:02 AM, bartc wrote:
On 26/02/2018 14:04, bartc wrote:
On 26/02/2018 13:42, Ned Batchelder wrote:
Well, once you notice that the
Python code had N=1e5, and the C code had N=1e9 :) If you want to
experiment, with N=1e5
On Tue, Feb 27, 2018 at 2:02 AM, bartc wrote:
> On 26/02/2018 14:04, bartc wrote:
>>
>> On 26/02/2018 13:42, Ned Batchelder wrote:
>
>
>> Well, once you notice that the
>>>
>>> Python code had N=1e5, and the C code had N=1e9 :) If you want to
>>> experiment, with N=1e5, the final number should
On 26/02/2018 14:04, bartc wrote:
On 26/02/2018 13:42, Ned Batchelder wrote:
Well, once you notice that the
Python code had N=1e5, and the C code had N=1e9 :) If you want to
experiment, with N=1e5, the final number should be 5255210926702073855.
OK, I'll try that.
I have that Python v
On 26/02/2018 14:34, Chris Angelico wrote:
I'm glad _someone_ funded PyPy, anyhow. It's a great demonstration of
what can be done.
And it's good that /someone/ at least understands how PyPy works, as I
don't think many people do.
Apparently it doesn't optimise 'hot paths' within a Python pr
On Tue, Feb 27, 2018 at 12:03 AM, Steven D'Aprano
wrote:
> On Mon, 26 Feb 2018 22:34:00 +1100, Chris Angelico wrote:
>> Removing the GIL from CPython is not about "speeding up" the language or
>> the interpreter, but about improving parallelism.
>
> It is about speeding up threaded code which is C
On 26/02/2018 13:42, Ned Batchelder wrote:
On 2/26/18 7:13 AM, bartc wrote:
A C version is given below. (One I may have messed around with, which
I'm not sure works properly. For an original, google for Marsaglia and
KISS64 or SUPRKISS64.)
Most integers are unsigned, which have well-defined
On 26/02/18 13:42, Ned Batchelder wrote:
Also, I note that you said, "Most integers are unsigned", but the C code
has them all declared as signed? It doesn't seem to have mattered to
your result, but I'm not an expert on C portability guarantees.
C explicitly leaves the behaviour of signed ar
On 2/26/18 7:13 AM, bartc wrote:
On 26/02/2018 11:40, Chris Angelico wrote:
On Mon, Feb 26, 2018 at 10:13 PM, bartc wrote:
Below is the first draft of a Python port of a program to do with
random
numbers. (Ported from my language, which in turned ported it from a C
program by George Marsaglia
On Mon, 26 Feb 2018 22:34:00 +1100, Chris Angelico wrote:
[...]
>> (We tried painting Go Faster stripes on the server, and it didn't
>> work.)
>
> Steven Middlename D'Aprano! You should know better than that. "It didn't
> work" is not good enough. What actually happened?
A truck crashed into the
On 26/02/2018 12:06, Antoon Pardon wrote:
On 23-02-18 02:27, Steven D'Aprano wrote:
Why do you care about the 50 million calls? That's crazy -- the important
thing is *calculating the Fibonacci numbers as efficiently as possible*.
No necessarily.
David Beazley in his talks sometimes uses an i
On 24-02-18 06:18, Terry Reedy wrote:
> On 2/23/2018 11:32 AM, Python wrote:
>>
>> Doing that would completely fail to accomplish the task of comparing
>> the performance of recursive function calls in the two languages,
>> which is what the benchmark was designed to do.
>
> That is an non goal bec
On 26/02/2018 11:40, Chris Angelico wrote:
On Mon, Feb 26, 2018 at 10:13 PM, bartc wrote:
Below is the first draft of a Python port of a program to do with random
numbers. (Ported from my language, which in turned ported it from a C
program by George Marsaglia, the random number guy.)
However,
On 23-02-18 02:27, Steven D'Aprano wrote:
> Why do you care about the 50 million calls? That's crazy -- the important
> thing is *calculating the Fibonacci numbers as efficiently as possible*.
No necessarily.
David Beazley in his talks sometimes uses an ineffecient algorithm for
calculating
fib
On Mon, Feb 26, 2018 at 10:13 PM, bartc wrote:
> Below is the first draft of a Python port of a program to do with random
> numbers. (Ported from my language, which in turned ported it from a C
> program by George Marsaglia, the random number guy.)
>
> However, running it quickly exhausts the memo
On Mon, Feb 26, 2018 at 8:57 PM, Steven D'Aprano
wrote:
> On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote:
>
>> So of course, speed is not and should not be the
>> primary concern, but to say that execution speed is of _no_ concern is
>> quite absurd indeed.
>
> I'm pretty sure that nobody
On 26/02/2018 09:22, Steven D'Aprano wrote:
On Sun, 25 Feb 2018 21:19:19 -0800, Rick Johnson wrote:
I agree with your sarcasm. And that's why these types of auto
conversions should be optional. I agree that most times it's more
practical to let python handle the dirty details. But in some case
On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote:
> On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
> [...]
>> Take the Fibonacci double-recursion benchmark. Okay, it tests how well
>> your language does at making millions of function calls. Why?
>
> Because making
On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote:
> So of course, speed is not and should not be the
> primary concern, but to say that execution speed is of _no_ concern is
> quite absurd indeed.
I'm pretty sure that nobody here has said that speed is of no concern.
Rather, I would argue
On Sun, 25 Feb 2018 21:19:19 -0800, Rick Johnson wrote:
> I agree with your sarcasm. And that's why these types of auto
> conversions should be optional. I agree that most times it's more
> practical to let python handle the dirty details. But in some cases,
> where you need to squeeze out a few
On Sunday, February 25, 2018 at 10:35:29 PM UTC-6, Steven D'Aprano wrote:
[...]
> Ah, you mean just like the way things were in Python 1.0
> through 2.1? Hands up anyone who has seen an integer
> OverflowError in the last 10 years? Anyone?
I think Python2.1 is much older than 10 years, so yeah, of
On Sun, 25 Feb 2018 18:33:47 -0800, Rick Johnson wrote:
> On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano
> wrote: [...]
>> There are dozens of languages that have made the design choice to limit
>> their default integers to 16- 32- or 64-bit fixed size, and let the
>> user worr
On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote:
> On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson
> wrote:
[...]
> > A default "integer-diversity-and-inclusivity-doctrine" is
> > all fine and dandy by me, (Hey, even integers need safe spaces),
>
> In Python 3.6+, integers ha
On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote:
> On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson
[...]
> > but i do wish we pythonistas had a method to turn off this
> > (and other) cycle burning "features" -- you know -- in the
> > 99.9 percent of time that we don'
On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
[...]
> Take the Fibonacci double-recursion benchmark. Okay, it
> tests how well your language does at making millions of
> function calls. Why?
Because making "millons of function calls" is what software
*DOES*!
Granted, an
On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson
wrote:
> On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano wrote:
> [...]
>> There are dozens of languages that have made the design
>> choice to limit their default integers to 16- 32- or 64-bit
>> fixed size, and let the user worry a
On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano wrote:
[...]
> There are dozens of languages that have made the design
> choice to limit their default integers to 16- 32- or 64-bit
> fixed size, and let the user worry about overflow. Bart,
> why does it upset you so that Python m
On 24/02/2018 02:05, Steven D'Aprano wrote:
On Fri, 23 Feb 2018 19:25:35 +, bartc wrote:
Python is 10 times slower than a competitor = doesn't matter
My language is 1.5 times slower than the big boys' = matters
a great deal
As for Python's order-of-magnitude speed difference, thank you
On 24/02/2018 02:46, Steven D'Aprano wrote:
Take the Fibonacci double-recursion benchmark. Okay, it tests how well
your language does at making millions of function calls. Why? How often
do you make millions of function calls?
Very often. Unless you are writing code 1970s style with everything
On Fri, Feb 23, 2018 at 1:16 PM, Chris Angelico wrote:
> On Sat, Feb 24, 2018 at 6:09 AM, Python wrote:
>> On Sat, Feb 24, 2018 at 05:56:25AM +1100, Chris Angelico wrote:
>>> No, not satisfied. Everything you've said would still be satisfied if
>>> all versions of the benchmark used the same non-
On 2/23/2018 11:32 AM, Python wrote:
On Fri, Feb 23, 2018 at 03:11:36AM -0500, Terry Reedy wrote:
Why do you care about the 50 million calls? That's crazy -- the important
thing is *calculating the Fibonacci numbers as efficiently as possible*.
If you are writing practical programs, that's tr
On Fri, 23 Feb 2018 12:43:06 -0600, Python wrote:
> Even if testing optimized
> code is the point, as the article claims, it utterly fails to do that.
> Bad science.
You've used that statement two or three times now.
*This isn't science*.
There's nothing scientific about writing benchmarks, or
On Fri, Feb 23, 2018 at 6:06 PM, bartc wrote:
> On 24/02/2018 00:45, Dan Stromberg wrote:
>> But again, those techniques are only infrequently relevant, and pretty
>> much never relevant to an entire application.
> That your page lists 23 different approaches to making Python faster
> suggests tha
On 24/02/2018 00:45, Dan Stromberg wrote:
On Fri, Feb 23, 2018 at 1:32 PM, bartc wrote:
But the difference in runtime speed between Python and other dynamic
languages, if you look at benchmarks doing actual work in the language, can
be much greater than two times, yet that doesn't appear to m
On Fri, 23 Feb 2018 19:25:35 +, bartc wrote:
> On 23/02/2018 18:05, Steven D'Aprano wrote:
>> On Fri, 23 Feb 2018 13:51:33 +, Ben Bacarisse wrote:
>
>> Stop writing crap code and then complaining that the language is "too
>> slow". Write better code, and then we'll take your complaints
>>
On Fri, Feb 23, 2018 at 1:32 PM, bartc wrote:
> On 23/02/2018 20:12, Chris Angelico wrote:
> So I'll keep it generic. Let's say the Tiny C compiler is not taken
> seriously because it might be a couple of times slower than gcc-O3, even
> thought it's 1% of the size and compiles 1000% as fast.
Wha
On Sat, Feb 24, 2018 at 8:32 AM, bartc wrote:
> So I'll keep it generic. Let's say the Tiny C compiler is not taken
> seriously because it might be a couple of times slower than gcc-O3, even
> thought it's 1% of the size and compiles 1000% as fast.
Except that nobody has said that. You're doing a
On 23/02/2018 20:12, Chris Angelico wrote:
On Sat, Feb 24, 2018 at 7:02 AM, bartc wrote:
I don't know what point you're making here. Unless it's that no software is
worth writing unless it's done on a big scale with a huge team of people,
and is very well known.
My own point should be clear:
On 2/23/18 3:02 PM, bartc wrote:
On 23/02/2018 19:47, Chris Angelico wrote:
On Sat, Feb 24, 2018 at 6:25 AM, bartc wrote:
The difference between Python and another dynamic language might be a
magnitude, yet you say it doesn't matter.
Thanks, that makes me feel much better about my own work!
On Sat, Feb 24, 2018 at 7:02 AM, bartc wrote:
> On 23/02/2018 19:47, Chris Angelico wrote:
>>
>> On Sat, Feb 24, 2018 at 6:25 AM, bartc wrote:
>
>
>>> The difference between Python and another dynamic language might be a
>>> magnitude, yet you say it doesn't matter.
>>>
>>> Thanks, that makes me
On 23/02/2018 19:47, Chris Angelico wrote:
On Sat, Feb 24, 2018 at 6:25 AM, bartc wrote:
The difference between Python and another dynamic language might be a
magnitude, yet you say it doesn't matter.
Thanks, that makes me feel much better about my own work! If a magnitude
difference in perf
On Fri, Feb 23, 2018 at 01:41:17PM -0600, Python wrote:
> On Sat, Feb 24, 2018 at 06:16:38AM +1100, Chris Angelico wrote:
> > > It seems abundantly clear to me that testing recursion is the point of
> > > writing a benchmark implementing recursion (and very little of
> > > anything else). Again, y
On Thu, 22 Feb 2018 17:13:02 -0800, Rick Johnson wrote:
> On Thursday, February 22, 2018 at 1:55:35 PM UTC-6, Jack Fearnley wrote:
> [...]
>> I realize that this thread is about benchmarking and not really about
>> generating fibonacci numbers, but I hope nobody is using this code to
>> generate t
On Sat, Feb 24, 2018 at 6:25 AM, bartc wrote:
> On 23/02/2018 18:05, Steven D'Aprano wrote:
>>
>> On Fri, 23 Feb 2018 13:51:33 +, Ben Bacarisse wrote:
>
>
>> Stop writing crap code and then complaining that the language is "too
>> slow". Write better code, and then we'll take your complaints s
On Sat, Feb 24, 2018 at 06:16:38AM +1100, Chris Angelico wrote:
> > It seems abundantly clear to me that testing recursion is the point of
> > writing a benchmark implementing recursion (and very little of
> > anything else). Again, you can decide for yourself the suitability of
> > the benchmark,
On 23/02/2018 18:56, Chris Angelico wrote:
On Sat, Feb 24, 2018 at 5:43 AM, Python wrote:
Satisfied?
No, not satisfied. Everything you've said would still be satisfied if
all versions of the benchmark used the same non-recursive algorithm.
Why? Does it matter?
There's nothing here that
On 23/02/2018 18:05, Steven D'Aprano wrote:
On Fri, 23 Feb 2018 13:51:33 +, Ben Bacarisse wrote:
Stop writing crap code and then complaining that the language is "too
slow". Write better code, and then we'll take your complaints seriously.
I write compilers for static languages, which ar
On Sat, Feb 24, 2018 at 6:09 AM, Python wrote:
> On Sat, Feb 24, 2018 at 05:56:25AM +1100, Chris Angelico wrote:
>> No, not satisfied. Everything you've said would still be satisfied if
>> all versions of the benchmark used the same non-recursive algorithm.
>> There's nothing here that says it's t
On Sat, Feb 24, 2018 at 05:56:25AM +1100, Chris Angelico wrote:
> No, not satisfied. Everything you've said would still be satisfied if
> all versions of the benchmark used the same non-recursive algorithm.
> There's nothing here that says it's testing recursion, just that (for
> consistency) it's
On Fri, Feb 23, 2018 at 06:14:22PM +, Steven D'Aprano wrote:
> > I never said the benchmarks chosen were awesome... :-) What I'm saying
> > is this:
> >
> > 1. Insistence that the most efficient python implementation of Fib
> >completely misses the point (and defeats the purpose) of the
On Sat, Feb 24, 2018 at 5:43 AM, Python wrote:
> On Sat, Feb 24, 2018 at 03:42:43AM +1100, Chris Angelico wrote:
>> >> If that were so, then the comparison should use the fastest *Python*
>> >> implementation.
>> >
>> > Doing that would completely fail to accomplish the task of comparing
>> > the
On Sat, Feb 24, 2018 at 03:42:43AM +1100, Chris Angelico wrote:
> >> If that were so, then the comparison should use the fastest *Python*
> >> implementation.
> >
> > Doing that would completely fail to accomplish the task of comparing
> > the performance of recursive function calls in the two lang
On Sat, Feb 24, 2018 at 5:05 AM, Steven D'Aprano
wrote:
> But guess what? The benchmarks are flawed. The performance of real-world
> Julia code doesn't match the performance of the benchmarks.
>
> "What’s disappointing is the striking difference between
> the claimed performance and the ob
On Sat, Feb 24, 2018 at 4:49 AM, Steven D'Aprano
wrote:
> On Sat, 24 Feb 2018 00:03:06 +1100, Chris Angelico wrote:
>
>>> Is numpy a general purpose C library that can also be called from any
>>> language that can use a C API? Or is it specific to Python?
>>>
>>>
>> No, it's a general purpose FORT
On Fri, 23 Feb 2018 10:50:50 -0600, Python wrote:
> On Fri, Feb 23, 2018 at 01:38:01AM -0500, Terry Reedy wrote:
>> It is no secret that Python's interpreted function calls are slower
>> than function calls compiled to machine code and that Python's infinite
>> precision integer arithmetic is slow
On Fri, 23 Feb 2018 13:51:33 +, Ben Bacarisse wrote:
[...]
>> I don't know why the Julia programmers chose to use such a poor
>> algorithm:
>
> It's odd indeed, but given that they did, what you take to be the point
> of the article -- to write a good Python algorithm as fast as the
> terribl
On Fri, 23 Feb 2018 12:17:50 +, bartc wrote:
> On 23/02/2018 01:27, Steven D'Aprano wrote:
>> On Thu, 22 Feb 2018 17:53:30 +, bartc wrote:
>
>>> The actual result is irrelevant, so long as its correct. The important
>>> thing is those 50 million calls.
>>
>> Why do you care about the 50
On Sat, 24 Feb 2018 00:03:06 +1100, Chris Angelico wrote:
>> Is numpy a general purpose C library that can also be called from any
>> language that can use a C API? Or is it specific to Python?
>>
>>
> No, it's a general purpose FORTRAN library that can also be called from
> any language that can
On Fri, Feb 23, 2018 at 01:38:01AM -0500, Terry Reedy wrote:
> It is no secret that Python's interpreted function calls are slower
> than function calls compiled to machine code and that Python's
> infinite precision integer arithmetic is slower that machine int
> arithmetic. So there is almost n
On Sat, Feb 24, 2018 at 3:39 AM, Steven D'Aprano
wrote:
> On Fri, 23 Feb 2018 23:41:44 +1100, Chris Angelico wrote:
>
> [...]
>>> Integer pixel values
>>
>> Maybe in 64 bits for the time being, but 32 certainly won't be enough.
>> As soon as you do any sort of high DPI image manipulation, you wil
On Sat, Feb 24, 2018 at 3:32 AM, Python wrote:
> On Fri, Feb 23, 2018 at 03:11:36AM -0500, Terry Reedy wrote:
>> >>Why do you care about the 50 million calls? That's crazy -- the important
>> >>thing is *calculating the Fibonacci numbers as efficiently as possible*.
>>
>> >If you are writing pract
On Fri, 23 Feb 2018 23:41:44 +1100, Chris Angelico wrote:
[...]
>> Integer pixel values
>
> Maybe in 64 bits for the time being, but 32 certainly won't be enough.
> As soon as you do any sort of high DPI image manipulation, you will
> exceed 2**32 total pixels in an image (that's just 65536x6553
On Fri, Feb 23, 2018 at 03:11:36AM -0500, Terry Reedy wrote:
> >>Why do you care about the 50 million calls? That's crazy -- the important
> >>thing is *calculating the Fibonacci numbers as efficiently as possible*.
>
> >If you are writing practical programs, that's true. But the Julia
> >benchma
Steven D'Aprano writes:
> On Fri, 23 Feb 2018 00:26:33 +, bartc wrote:
>
>> The point of the article was Julia vs. Python. You can't make Python
>> faster by switching to a faster algorithm; you have to use the same one
>> on both.
>
> No, the point of the article was to write Python code tha
On 23/02/2018 12:41, Chris Angelico wrote:
On Fri, Feb 23, 2018 at 11:17 PM, bartc wrote:
Integer pixel values
Maybe in 64 bits for the time being, but 32 certainly won't be enough.
Why, people's eyes will evolve to see quintillions of colours?
As soon as you do any sort of high DPI i
On Fri, Feb 23, 2018 at 11:57 PM, bartc wrote:
> On 23/02/2018 08:11, Terry Reedy wrote:
>
>> * Python has an import statement. But 'comparisons' disallow 'import
>> numpy', a quite legal Python statement, and similar others.
>
>
> If I'm duplicating a benchmark [in another language] then the las
On 23/02/2018 08:11, Terry Reedy wrote:
* Python has an import statement. But 'comparisons' disallow 'import
numpy', a quite legal Python statement, and similar others.
If I'm duplicating a benchmark [in another language] then the last thing
I want to see is something like 'import numpy', or
On Fri, Feb 23, 2018 at 11:17 PM, bartc wrote:
>>> The fact is that the vast majority of integer calculations don't need to
>>> use big integers (pretty much 100% of mine). Probably most don't even
>>> need 64 bits, but 32 bits.
>>
>>
>> And here we have the World According To Bart again: "since *
On 23/02/2018 01:27, Steven D'Aprano wrote:
On Thu, 22 Feb 2018 17:53:30 +, bartc wrote:
The actual result is irrelevant, so long as its correct. The important
thing is those 50 million calls.
Why do you care about the 50 million calls?
Because we are interested in comparing call-effic
On Fri, 23 Feb 2018 11:00:28 +0100, Stefan Behnel wrote:
> I've even seen proper Cython benchmark code that a C compiler can fully
> analyse as static and replaces by a constant, and then get wonder
> speedups from it that would never translate to any real-world gains.
This is one of the reasons
On Fri, 23 Feb 2018 11:00:28 +0100, Stefan Behnel wrote:
> I've even seen proper Cython benchmark code that a C compiler can fully
> analyse as static and replaces by a constant, and then get wonder
> speedups from it that would never translate to any real-world gains.
This is one of the reasons
Steven D'Aprano schrieb am 22.02.2018 um 11:59:
> https://www.ibm.com/developerworks/community/blogs/jfp/entry/Python_Meets_Julia_Micro_Performance?lang=en
Thanks for sharing, Steven.
While it was already suggested between the lines in some of the replies,
I'd like to emphasise that the combinati
On Fri, 23 Feb 2018 03:11:36 -0500, Terry Reedy wrote:
> On 2/22/2018 10:31 PM, Python wrote:
>
>>> Why do you care about the 50 million calls? That's crazy -- the
>>> important thing is *calculating the Fibonacci numbers as efficiently
>>> as possible*.
>
>> If you are writing practical program
On Fri, Feb 23, 2018 at 5:38 PM, Terry Reedy wrote:
> As to the vague 'class of problems implemented in a similar manner': Any
> function f of count N that depends of values of f for counts < N can be
> memoized the same way in Python as fibonacci. Everything said about P vs J
> for fib applies t
On 2/22/2018 10:31 PM, Python wrote:
Why do you care about the 50 million calls? That's crazy -- the important
thing is *calculating the Fibonacci numbers as efficiently as possible*.
If you are writing practical programs, that's true. But the Julia
benchmarks are not practical programs; the
On 2/22/2018 8:36 PM, Python wrote:
On Thu, Feb 22, 2018 at 11:29:53PM +1100, Chris Angelico wrote:
The idea of the Fibonacci benchmark is to test how effectively an
implementation manages large numbers of recursive function calls. Then,
fib(36) would normally involve 48,315,633 calls.
This ver
On Fri, 23 Feb 2018 00:26:33 +, bartc wrote:
> The point of the article was Julia vs. Python. You can't make Python
> faster by switching to a faster algorithm; you have to use the same one
> on both.
No, the point of the article was to write Python code that is as fast as
the Julia code.
I
1 - 100 of 126 matches
Mail list logo
