On Mar 16, 2010, at 3:16 PM, Greg Ewing wrote:
>
> Seems to me that this education would mostly consist of saying
> "don't compare floats and decimals", which is why I think that
> disallowing them in the first place would be better.
That makes sense.
I do worry that 2.x currently does make the
On Tue, Mar 16, 2010 at 5:36 PM, Raymond Hettinger
wrote:
>
>
>
> On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
>
>> I'd say if you're not going to forward-port this to Python 3, it
>> shouldn't go into Python 2 -- in that case it would make more sense to
>> me to back-port the exception-ra
On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
> I'd say if you're not going to forward-port this to Python 3, it
> shouldn't go into Python 2 -- in that case it would make more sense to
> me to back-port the exception-raising behavior.
Python 3 doesn't need it because it is possible to
Benjamin Peterson wrote:
> My plan is to tag 3.1.2 sometime on Thursday, so binaries can be built
> for the final release on Saturday. Agreeable?
Fine with me.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
Hi,
I posted a small patch to the GIL which demonstrates the scheduling policy
of pthreads conditions.
It seems that with pthreads a good policy is to allow (and help) the OS to
manage scheduling of threads via the condition queue without introducing
scheduling logic.
Some changes include removin
On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano wrote:
> But mixed arithmetic runs into the problem, what do you want the result
> type to be? Given (say) decimal+float, returning either a Decimal or a
> float will be the wrong thing to do some of the time, so better to
> prohibit mixed arithmeti
On Wed, 17 Mar 2010 09:16:11 am Greg Ewing wrote:
> Mark Dickinson wrote:
> > On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby
wrote:
> >>If not, it might be confusing if a number that prints as '.1'
> >> compares unequal to Decimal('.1').
> >
> > Agreed, but this is just your everyday floating-point co
Steven D'Aprano wrote:
> But no such problems arise with comparisons, which will always return a
> bool, and will avoid the current ... interesting ... behaviour. In 3.1:
>
Decimal(1) == 1 == 1.0
> True
Decimal(1) == 1.0
> False
Decimal.from_float(1.0) == 1 == 1.0
> True
Decim
> You can't. This isn't an example where I am personally bitten by the GIL.
> I may be, but there's plenty of other stuff in terms of tuning or
> optimisation in my particular app before I get anywhere near the GIL.
>
> My point is not that it's biting me right now but that earlier you
> said the
Le Tue, 16 Mar 2010 17:02:13 +, Kristján Valur Jónsson a écrit :
>>
>> Well, I don't think this has ever been by design, and it's not obvious
>> this is desirable either (see Dave Beazley's benchmark).
>>
> Did Dave benchmark a straight FIFO system?
Well, he presented benchmark figures with t
On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
> On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson
> wrote: [...]
>
> Decimal.from_float(1.1) == 1.1
> >
> > False
>
> Whoops. To clarify, this is the pre-patch behaviour; post-patch,
> this gives True.
Whew! You had me worried there for
> David explained that in the issue tracker - 2.x typically doesn't do
> that much work per bytecode instruction,
Oh, but that's wrong in general.
Dave's *spinning loop* doesn't do much work per bytecode instruction,
however ;)
> The current settings mean we have less GIL overhead in the normal
Brian Quinlan wrote:
> I take it that the thread/process pool should be unlimited in size.
> Should every thread/process exit when it finishes its job or should
> there be a smarter collection strategy?
I'd be inclined to do something slightly smarter, similar to what we do
with memory overallocat
Kristján Valur Jónsson wrote:
> We have never had high priority for IO threads in
> python (and its not-by-design round robin scheduler on single core
> cpus) and it is unclear why that should be required now as a fix.
David explained that in the issue tracker - 2.x typically doesn't do
that much
Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
If not, it might be confusing if a number that prints as '.1' compares
unequal to Decimal('.1').
Agreed, but this is just your everyday floating-point confusion, to be
dealt with by social means (e.g., educating the progr
Mark Dickinson wrote:
On the one hand there's something to be said for maintaining a clean
separation between the float and Decimal types, allowing only explicit
conversions from one to the other; mixed-type arithmetic between
floats and Decimals was very deliberately not permitted in the
origi
On Mar 16, 2010, at 03:51 PM, Benjamin Peterson wrote:
>My plan is to tag 3.1.2 sometime on Thursday, so binaries can be built
>for the final release on Saturday. Agreeable?
I might as well do the same for 2.6.5, though I plan on releasing it Friday.
-Barry
signature.asc
Description: PGP signa
Nick Coghlan wrote:
> You may want to consider providing global thread and process
executors
> in the futures module itself. Code which just wants to say "do this
in
> the background" without having to manage the lifecycle of its own
> executor instance is then free to do so. I've had a lot o
My plan is to tag 3.1.2 sometime on Thursday, so binaries can be built
for the final release on Saturday. Agreeable?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I just verified with our ActivePython build that 2.6.4rc2 builds fine on Linux,
Windows, Mac, HP-UX, AIX and Solaris. 3.1.2rc1 builds fine except on AIX[1] and
HP-UX[2] but those issues existed in 3.1.1 too, I believe.
-srid
[1] http://bugs.python.org/issue6645
[2] http://bugs.python.org/issue5
The Linux kernel scheduler deals with two types of ratings and has a
heuristic algorithm that rewards and penalizes on a rapid basis. To
determine the next thread it inspects the priority array to find the highest
priority task that is runnable and then selects the first task in that
priority. Th
Yes, having another thread wait with a timeout is not good. CPU cycles
waisted doing things that don¹t help the thread holding the GIL release it.
They just note that they are present and then the GIL-holding-thread should
be responsible for handling the rest. -peter
On 3/16/10 1:11 PM, "Nir Aide
Hello Dave,
The following documentation suggests ordering in Linux is not FIFO:
http://www.opengroup.org/onlinepubs/95399/functions/pthread_cond_timedwait.html#tag_03_518_08_06
"Threads waiting on mutexes and condition variables are selected to proceed
in an order dependent upon the scheduling
On Tue, Mar 16, 2010 at 9:07 AM, Mark Dickinson wrote:
> On Tue, Mar 16, 2010 at 4:41 PM, Guido van Rossum wrote:
>> I'd say if you're not going to forward-port this to Python 3, it
>> shouldn't go into Python 2 -- in that case it would make more sense to
>> me to back-port the exception-raising
On Tue, Mar 16, 2010 at 4:41 PM, Guido van Rossum wrote:
> I'd say if you're not going to forward-port this to Python 3, it
> shouldn't go into Python 2 -- in that case it would make more sense to
> me to back-port the exception-raising behavior.
That's also a possible solution, and the one that
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Antoine Pitrou
> > The key to this
> > is implementing your GIL in such a way that you (and not the system)
> > chooses which thre
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to back-port the exception-raising behavior.
Also supporting comparisons but not other mixed operations is going to
be confusing. If you are sticking to that b
On Tue, Mar 16, 2010 at 4:18 PM, Victor Stinner
wrote:
> If comparaison of Decimal and float can have "unpredictable" result, I would
> suggest the same behaviour (raise an error).
Well, it's not really `unpredictable': the new behaviour is perfectly
predictable and sane, provided only that you
On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson wrote:
[...]
Decimal.from_float(1.1) == 1.1
> False
Whoops. To clarify, this is the pre-patch behaviour; post-patch,
this gives True.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://
Le mardi 16 mars 2010 16:58:22, P.J. Eby a écrit :
> At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
> >I'm +0 to allow these comparisons, being "Decimal(1) < .3" the same as
> >"Decimal(1) < Decimal.from_float(.3)"
>
> Does Decimal.from_float() use the "shortest decimal representation"
> app
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
> At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
>>
>> I'm +0 to allow these comparisons, being "Decimal(1) < .3" the same as
>> "Decimal(1) < Decimal.from_float(.3)"
>
> Does Decimal.from_float() use the "shortest decimal representation"
> app
At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
I'm +0 to allow these comparisons, being "Decimal(1) < .3" the same as
"Decimal(1) < Decimal.from_float(.3)"
Does Decimal.from_float() use the "shortest decimal representation" approach?
If not, it might be confusing if a number that prints a
On Tue, Mar 16, 2010 at 2:58 PM, Facundo Batista
wrote:
> On Tue, Mar 16, 2010 at 9:41 AM, Mark Dickinson wrote:
>
>> On the one hand there's something to be said for maintaining a clean
>> separation between the float and Decimal types, allowing only explicit
>> conversions from one to the other
Martin v. Löwis wrote:
> > If it's lurking behind a filesystem interface or in its daemon mode
> > (remote archive store), multiple client processes can be using it at once,
> > and it will be processing multiple tasks somewhat in parallel. Here one
> > can get a compute bound thread answering on
On Tue, Mar 16, 2010 at 9:41 AM, Mark Dickinson wrote:
> On the one hand there's something to be said for maintaining a clean
> separation between the float and Decimal types, allowing only explicit
> conversions from one to the other; mixed-type arithmetic between
> floats and Decimals was very
Hello all,
Currently in Python 2.x, Decimal-to-float comparisons behave as follows:
>>> Decimal(1) < float(4)
False
>>> Decimal(4) < float(1)
False
That is, any Decimal sorts before any float (though this is arbitrary:
it's possible that on some implementations any float sorts before any
Decima
Le Tue, 16 Mar 2010 14:10:33 +,
Kristján Valur Jónsson a écrit :
>
> The key to this
> is implementing your GIL in such a way that you (and not the system)
> chooses which threads runs next. On Windows it works in a nice,
> determinitstic FIFO order becoause that's how the underlying Event
>
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Antoine Pitrou
> Sent: 16. mars 2010 12:00
> To: python-dev@python.org
> Subject: Re: [Python-Dev] "Fixing" the new GIL
>
>
> Hi
You are right, I was assuming a mutex. (why not then, use a semaphore?)
But the implementation isn't a simple binary semaphore.
It suffers from case 2) that I explained before: Greedy aquisition of the
"semaphore" even if someone is waiting.
Also, I should add, a condition variable doesn't specif
Hi Kristján,
> In the new GIL, there appear to be several problems:
> 1) There is no FIFO queue of threads wanting the queue, thus thread
> scheduling becomes non-deterministic
Thread scheduling has always been non-deterministic.
> 2) The "ticking" of the GIL is
> now controled by a condition v
Python doesn't use a pthreads mutex for the GIL.It has always used a binary
semaphore implemented with condition variables (or just a pthreads semaphore if
available).The reason the performance is so bad is precisely due to the
fact that it is using this implementation and the fact that
How about attacking the original problem, then?
The reason they thrash on pthreads implementation is that a pthreads mutex is
assumed to be a short-held resource. Therefore it will be optimized in the
following ways for multicore machines:
1) There is a certain amount of spinning done, to try t
Martin v. Löwis wrote:
> Cameron Simpson wrote:
>> The idea here is that one has a few threads receiving requests (eg a
>> daemon watching a socket or monitoring a db queue table) which then use
>> the FuncMultiQueue to manage how many actual requests are processed
>> in parallel (yes, a semaphore
Barry Warsaw wrote:
> On Mar 14, 2010, at 12:17 AM, Nick Coghlan wrote:
>> While it's probably OK if the import side-effects only create files
>> using the new scheme, the standard library modules will likely need to
>> support both schemes (although I'm not sure if "same as import system"
>> or "s
On 16Mar2010 09:02, "Martin v. Löwis" wrote:
| > If it's lurking behind a filesystem interface or in its daemon mode
| > (remote archive store), multiple client processes can be using it at once,
| > and it will be processing multiple tasks somewhat in parallel. Here one
| > can get a compute boun
On 16Mar2010 08:59, "Martin v. Löwis" wrote:
| Cameron Simpson wrote:
| > On 15Mar2010 09:28, Martin v. L�wis wrote:
| > | > As for the argument that an application with cpu intensive work being
| > | > driven by the IO itself will work itself out... No it won't, it can
| > | > get into beat pat
> If it's lurking behind a filesystem interface or in its daemon mode
> (remote archive store), multiple client processes can be using it at once,
> and it will be processing multiple tasks somewhat in parallel. Here one
> can get a compute bound thread answering one request, impacting quick
> resp
Cameron Simpson wrote:
> On 15Mar2010 09:28, Martin v. L�wis wrote:
> | > As for the argument that an application with cpu intensive work being
> | > driven by the IO itself will work itself out... No it won't, it can
> | > get into beat patterns where it is handling requests quite rapidly up
> |
48 matches
Mail list logo
