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 12:41 AM, Larry Martell wrote:
> On Fri, Feb 23, 2018 at 8:34 AM, Chris Angelico wrote:
>> On Sat, Feb 24, 2018 at 12:08 AM, Larry Martell
>> wrote:
>>> On Fri, Feb 23, 2018 at 2:01 AM, dieter wrote:
Larry Martell writes:
> ...
> I had 2.2.1. I updated req
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 Fri, Feb 23, 2018 at 8:34 AM, Chris Angelico wrote:
> On Sat, Feb 24, 2018 at 12:08 AM, Larry Martell
> wrote:
>> On Fri, Feb 23, 2018 at 2:01 AM, dieter wrote:
>>> Larry Martell writes:
...
I had 2.2.1. I updated requests to 2.18.4 and now when I import atws I get:
No h
On Sat, Feb 24, 2018 at 12:08 AM, Larry Martell wrote:
> On Fri, Feb 23, 2018 at 2:01 AM, dieter wrote:
>> Larry Martell writes:
>>> ...
>>> I had 2.2.1. I updated requests to 2.18.4 and now when I import atws I get:
>>>
>>> No handlers could be found for logger "atws.connection"
>>
>> This is a
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
How can i fix this error?
I'm using gevent/uwsgi and python 2.7.13...
Looks like ssl.py really needs monkey-patching to work with
gevent/uwsgi, but i'm not sure exactly where/what triggers this error.
Any thoughts?
Etienne
File "/home/www/isotoperesearch.ca/trunk/www-bin/dispatch-django.uw
On Fri, Feb 23, 2018 at 2:01 AM, dieter wrote:
> Larry Martell writes:
>> ...
>> I had 2.2.1. I updated requests to 2.18.4 and now when I import atws I get:
>>
>> No handlers could be found for logger "atws.connection"
>
> This is a warning (only), telling you that the "atws" package wants
> to l
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
51 matches
Mail list logo
