On October 17, 2018 7:56:51 AM GMT+02:00, Marko Rauhamaa
wrote:
>I can't be positive about swapping. I don't remember hearing thrashing.
>However, I do admit running emacs for months on end and occasionally
>with huge buffers so the resident size can be a couple of gigabytes.
>
That's a pretty
Paul Rubin :
> Marko Rauhamaa writes:
>> Emacs occasionally hangs for about a minute to perform garbage
>> collection.
>
> I've never experienced that, especially with more recent versions that I
> think do a little bit of heap tidying in the background. Even in the
> era of much slower computer
Paul Rubin :
> But it's possible to do parallel GC with bounded latency. Perry
> Cheng's 2001 PhD thesis says how to do it and is fairly readable:
>
> http://reports-archive.adm.cs.cmu.edu/anon/2001/CMU-CS-01-174.pdf
Thanks. On a quick glance, it is difficult to judge what the worst-case
time and
Have seen this waning of python thread so many times. Hoping it would have
waned by now. Lol.
Sent from Mail for Windows 10
From: jfine2...@gmail.com
Sent: Tuesday, October 16, 2018 12:42 PM
To: python-list@python.org
Subject: Re: ESR "Waning of Python" post
On Tuesday, October 16,
On Tuesday, October 16, 2018 at 8:00:26 AM UTC+1, Marko Rauhamaa wrote:
>https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/>
I'm all in favour of collecting useful URLs. Here's some more suggestions:
https://stackoverflow.com/questions/4491260/explanation-of-azuls-pauseles
Paul Rubin :
> Marko Rauhamaa writes:
>>> Right, if I need near realtime behaviour and must live
>>> with [C]Python's garbage collector.
>> Or any other GC ever invented.
>
> There are realtime ones, like the Azul GC for Java, that have bounded
> delay in the milliseconds or lower. The total over
On Tue, Oct 16, 2018 at 4:18 PM dieter wrote:
>
> Marko Rauhamaa writes:
> > Or you could blame the parts of the software that create too many
> > long-term objects.
>
> I do not do that because I understand why in my application
> there are many long living objects.
>
> > You shouldn't blame the
Marko Rauhamaa writes:
> dieter :
>> Marko Rauhamaa writes:
>>> Keeping the number of long-term objects low is key.
>>
>> Right, if I need near realtime behaviour and must live
>> with [C]Python's garbage collector.
>
> Or any other GC ever invented.
There are "realtime garbage collection" algor
dieter :
> Marko Rauhamaa writes:
>> Keeping the number of long-term objects low is key.
>
> Right, if I need near realtime behaviour and must live
> with [C]Python's garbage collector.
Or any other GC ever invented.
> But, a web application does usually not need near realtime behaviour.
> An o
Marko Rauhamaa writes:
> dieter :
> ...
>> Definitely. The application concerned was a long running web application;
>> caching was an important feature to speed up its typical use cases.
>
> As an optimization technique, I suggest turning the cache into a "binary
> blob" opaque to GC, or using so
Paul Rubin :
> Note that Java has a lot of [GC] options to choose from:
> https://docs.oracle.com/javase/9/gctuning/available-collectors.htm
I'm all for GC, but Java's GC tuning options are the strongest
counter-argument against it. The options just shift the blame from the
programming language to
dieter :
> Marko Rauhamaa writes:
>> However, I challenge the notion that creating hundreds of thousands of
>> temporary objects is stupid. I suspect that the root cause of the
>> lengthy pauses is that the program maintains millions of *nongarbage*
>> objects in RAM (a cache, maybe?).
>
> Definit
On Friday, October 12, 2018 at 8:41:12 PM UTC+1, Paul Rubin wrote:
> 1) If you keep the existing refcount mechanism, you have to put locks
> around all the refcounts, which kills performance since refcounts are
> updated all the time.
I think BUFFERED multi-core reference count garbage collection
On 2018-10-12 14:07:56 -0500, Tim Daneliuk wrote:
> On 10/11/2018 12:15 AM, Gregory Ewing wrote:
> > But it's not like that at all. As far as I know, all the
> > attempts that have been made so far to remove the GIL have
> > led to performance that was less than satisfactory. It's a
> > hard proble
Marko Rauhamaa writes:
> dieter :
> ...
>> I work in the domain of web applications. And I made there a nasty
>> experience with garbage collection: occasionally, the web application
>> stopped to respond for about a minute. A (quite difficult) analysis
>> revealed that some (stupid) component cre
Paul Rubin wrote:
I even wonder what happens if you turn Py_INCREF etc. into no-ops,
install the Boehm garbage collector in a stop-the-world mode, and
disable the GIL.
I suspect you would run into problems with things that need
mutual exclusion but don't do any locking of their own, because
the
On 2018-10-12, Peter J. Holzer wrote:
> Neil Cerutti said:
>> I imagine that if I stuck with Go long enough I'd develop a
>> new coding style that didn't inolve creating useful data
>> types.
>
> I haven't used Go for any real project yet (that may change
> next year - we'll see whether I love it
On Sat, Oct 13, 2018 at 7:25 AM Vito De Tullio wrote:
>
> Chris Angelico wrote:
>
> >> Reference counting was likely a bad idea to begin with.
> >
> > Then prove CPython wrong by making a fantastically better
> > implementation that uses some other form of garbage collection.
>
> I'm not talking a
Chris Angelico wrote:
>> Reference counting was likely a bad idea to begin with.
>
> Then prove CPython wrong by making a fantastically better
> implementation that uses some other form of garbage collection.
I'm not talking about the "goodness" of the implemetations, but AFAIK jython
and ironp
On 10/12/2018 11:43 AM, Skip Montanaro wrote:
> I sort of skimmed ESR's post, and sort of skimmed this thread, so
> obviously I'm totally qualified to offer my observations on the post
> and follow ups. :-)
Skip -
In the 15-ish years I've been reading this group, this has NEVER been
an obstacle f
On 10/11/2018 12:15 AM, Gregory Ewing wrote:
> Paul Rubin wrote [concerning GIL removal]:
>> It's weird that Python's designers were willing to mess up the user
>> language in the 2-to-3 transition but felt that the C API had to be kept
>> sarcosanct. Huge opportunities were blown at multiple leve
On 2018-10-11 17:56:43 +, Neil Cerutti wrote:
> On 2018-10-10, Paul Rubin wrote:
> > Neil Cerutti writes:
> >>
> >>> the GIL (15/16th of his CPUs are unused..)
> >> Channels are a big selling point of Go, no argument there.
> >
> > The unused CPUs are not about channels (Python has Queue whic
I sort of skimmed ESR's post, and sort of skimmed this thread, so
obviously I'm totally qualified to offer my observations on the post
and follow ups. :-)
Eric makes a mistake, in my opinion, confusing his particular
application with the mainstream, when in fact it seems pretty
specialized to me.
On Fri, Oct 12, 2018 at 5:51 PM Marko Rauhamaa wrote:
> > Python uses the GIL mainly because it uses reference counting (with
> > almost constant changes to potentially concurrently used objects) for
> > memory management. Dropping the GIL would mean dropping reference
> > counting likely in favou
dieter :
> Every system you use has its advantages and its drawbacks.
> Depending on the specific context (problem, resources, knowledge, ...),
> you must choose an appropriate one.
Yep. I use Python for numerous tasks professionally and at home. Just
this past week I used it to plan a junior soc
Ben Finney writes:
> ...
> Is it your position that the described behaviour is not a problem? Do
> you hold that position because you think multi-core machines are not a
> sector that Python needs to be good at? Or that the described behaviour
> doesn't occur? Or something else?
Every system you
On 2018-10-10, Paul Rubin wrote:
> Neil Cerutti writes:
>> As Stephen said, it's sort of silly not to be aware of those
>> issues going in.
>
> If you're saying ESR messed up by using Python in the first
> place for that program, that's not a great advert for Python
> either.
I meant Stefan, by
On Thu, Oct 11, 2018 at 06:22:13PM +1100, Chris Angelico wrote:
[...]
>
> There's a huge difference between deciding on using some different
> language for a project, and going on a massive ire-filled rant.
I agree, in fact this is the kind of posture that I myself
implemented in my actions.
I
On Thu, Oct 11, 2018 at 6:43 PM Thomas Jollans wrote:
> The gist is that the GIL is a problem only for relatively few problems
> (e.g. games that need limited-scale low-latency parallelism). Most of
> the time, you either only need one process in the first place, or you
> can take full advantage o
On 11/10/2018 09:11, Ben Finney wrote:
Chris Angelico writes:
In actual fact, it's not a problem per-se. It's a design choice, and
every alternative choice tried so far has even worse problems. THAT is
why we still have it.
That reads to me like a rejection of the point made in the blog post
On Thu, Oct 11, 2018 at 6:12 PM Ben Finney wrote:
>
> Chris Angelico writes:
>
> > In actual fact, it's not a problem per-se. It's a design choice, and
> > every alternative choice tried so far has even worse problems. THAT is
> > why we still have it.
>
> That reads to me like a rejection of the
Chris Angelico writes:
> In actual fact, it's not a problem per-se. It's a design choice, and
> every alternative choice tried so far has even worse problems. THAT is
> why we still have it.
That reads to me like a rejection of the point made in the blog post:
that the GIL prevents Python from t
On Thu, Oct 11, 2018 at 4:21 PM Gregory Ewing
wrote:
>
> Paul Rubin wrote [concerning GIL removal]:
> > It's weird that Python's designers were willing to mess up the user
> > language in the 2-to-3 transition but felt that the C API had to be kept
> > sarcosanct. Huge opportunities were blown at
Paul Rubin wrote [concerning GIL removal]:
It's weird that Python's designers were willing to mess up the user
language in the 2-to-3 transition but felt that the C API had to be kept
sarcosanct. Huge opportunities were blown at multiple levels.
You say that as though we had a solution for GIL
On 2018-10-09, Paul Rubin wrote:
> If anyone cares, Eric Raymond posted a big rant saying
> basically he's giving up on Python and porting a big program
> he's working on to Go. Reasons he gives are
> performance (Go is 40x faster for his app)
> memory footprint (high overhead of simple Python ob
35 matches
Mail list logo
