Dennis Lee Bieber wrote:
> On Wed, 1 Feb 2012 23:25:36 -0800 (PST), oleg korenevich
> wrote:
>
>
>>Thanks for help. In first case all vars is python integers, maybe
>>math.floor is redundant, but i'm afraid that same error with math
>>module call will occur in other places of app, where math is
On Feb 1, 6:07 pm, Dennis Lee Bieber wrote:
> On Wed, 1 Feb 2012 06:15:22 -0800 (PST), oleg korenevich
>
>
>
>
>
>
>
>
>
> wrote:
> >I have linux board on samsung SoC s3c6410 (ARM11). I build rootfs with
> >buildroot: Python 2.7.1, uClibc-0.9.31. Linux kernel: Linux buildroot
> >2.6.28.6 #177 Mon
Paul Rubin wrote:
> I haven't been keeping up with this stuff in recent years so I have a
> worse concern. I don't know whether it's founded or not. Basically
> in the past decade or so, memory has gotten 100x larger and cpu's have
> gotten 100x faster, but memory is less than 10x faster once yo
Paul Rubin wrote:
> This correctly describes difficulties of using a copying GC in
> CPython. Note that the Boehm GC is mark-and-sweep. As Alex mentions,
> that usually means there's a pause every so often while the GC scans
> the entire heap, touching all data both live and dead (maybe the Boehm
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> And regarding the "zero exceptions" - I know for sure that quite a few
> programs were crashing when the transition in 68K from 24 bit
> addresses to real 32 bit was done on popular systems like the ATARI ST
> - as some smart-asses back then used the
> Yeah, I noticed that, I could have been pedantic about it but chose to
> just describe how these language implementations work in the real
> world with zero exceptions that I know of. I guess I should have
> spelled it out.
You talked about CPU architectures:
"""
>And this presumes an archite
[EMAIL PROTECTED] writes:
> Folks, most common GC schemes have been tried as experiments over
> the years. None have succeeeded, for various reasons. I think one
> of the main reasons is that Python has to "play nice" with external
> libraries, many of which weren't written with GC beyond malloc
Steve Holden <[EMAIL PROTECTED]> writes:
> >>And this presumes an architecture which byte-addresses and only
> >> uses "aligned" addresses.
>
> He was talking about the arachiteecture, for Pete's sake, not a compiler.
Yeah, I noticed that, I could have been pedantic about it but chose to
just d
Paul Rubin wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
>
>>>Yes, that would describe just about every cpu for the past 30 years
>>>that's a plausible Python target.
>>
>>No. The later 68K (>68020) could address on odd adresses. And AFAIK
>>all x86 can because of their 8080 stemming.
>
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> > Yes, that would describe just about every cpu for the past 30 years
> > that's a plausible Python target.
>
> No. The later 68K (>68020) could address on odd adresses. And AFAIK
> all x86 can because of their 8080 stemming.
Yes, "could" but not "
> Yes, that would describe just about every cpu for the past 30 years
> that's a plausible Python target.
No. The later 68K (>68020) could address on odd adresses. And AFAIK all
x86 can because of their 8080 stemming.
Don't confuse this with 16Bit aligned addressing - _that_ is the minimum
for
Scott David Daniels <[EMAIL PROTECTED]> writes:
> > I think most of the time, branch prediction will prevent the cache
> > flush.
> But, branch prediction is usually a compiler thing, based on code
> that is, in this case, a spot in the interpreter that is actually
> taking both sides of the branch
Paul Rubin wrote:
> Scott David Daniels <[EMAIL PROTECTED]> writes:
>
>>Current speeds are due to deep pipelines, and a conditional in the
>>INCREF code would blow a pipeline.
>
>
> I think most of the time, branch prediction will prevent the cache
> flush.
But, branch prediction is usually a co
Diez> AFAIK some LISPs do a similar trick to carry int values on
Diez> cons-cells. And by this tehy reduce integer precision to 28 bit
Diez> or something. Surely _not_ going to pass a regression test suite
Diez> :)
I'm pretty sure this was tried a few years ago w/ Python. I don'
Scott David Daniels <[EMAIL PROTECTED]> writes:
> Current speeds are due to deep pipelines, and a conditional in the
> INCREF code would blow a pipeline.
I think most of the time, branch prediction will prevent the cache
flush. Anyway, with consed integers, there's still going to be a
conditional
Paul Rubin wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
(about tag bits)
>>... Basically I think that trying to come up with all sorts of
>> optimizations for rather marginal problems (number crunching
>> should be - if a python domain at all - done using Numarray)
> I don't think
Tom Anderson <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Oct 2005, Alex Martelli wrote:
>
> > Tom Anderson <[EMAIL PROTECTED]> wrote:
> > ...
> >> Has anyone looked into using a real GC for python? I realise it would be a
> >
> > If you mean mark-and-sweep, with generational twists,
>
> Yes, more
Steve Holden <[EMAIL PROTECTED]> writes:
> Until someone does the experiment this stuff is bound to be
> speculation (what's that saying about "premature optimization"?).
40 years of practical Lisp implementation efforts and around the globe
and hundreds of published papers on the subject might n
Paul Rubin wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
>
>>That particular implementation used 3 or 4 tag-bits. Of course you are
>>right that nowadays python won't notice the difference, as larger nums
>>get implicitely converted to a suitable representation. But then the
>>efficiency
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> (fwiw, switching to tagging in CPython would break most about
> everything. might as well start over, and nobody's likely to do
> that to speed up integer- dominated programs a little...)
Yeah, a change of that magnitude in CPython would be madness, b
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> That particular implementation used 3 or 4 tag-bits. Of course you are
> right that nowadays python won't notice the difference, as larger nums
> get implicitely converted to a suitable representation. But then the
> efficiency goes away... Basically
Tom Anderson wrote:
> In both smalltalk and python, every single variable contains a reference
> to an object - there isn't the object/primitive distinction you find in
> less advanced languages like java.
>
> Except that in smalltalk, this isn't true: in ST, every variable *appears*
> to contain
Paul Rubin wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
>
>>AFAIK some LISPs do a similar trick to carry int values on
>>cons-cells. And by this tehy reduce integer precision to 28 bit or
>>something. Surely _not_ going to pass a regression test suite :)
>
>
> Lisps often use just one
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> AFAIK some LISPs do a similar trick to carry int values on
> cons-cells. And by this tehy reduce integer precision to 28 bit or
> something. Surely _not_ going to pass a regression test suite :)
Lisps often use just one tag bit, to distinguish betwe
Delaney, Timothy (Tim) wrote:
> Tom Anderson wrote:
>
>
>>Except that in smalltalk, this isn't true: in ST, every variable
>>*appears* to contain a reference to an object, but implementations
>>may not actually work like that. In particular, SmallTalk 80 (and
>>some earlier smalltalks, and all su
On Tue, 11 Oct 2005, Alex Martelli wrote:
> Tom Anderson <[EMAIL PROTECTED]> wrote:
> ...
>> Has anyone looked into using a real GC for python? I realise it would be a
>
> If you mean mark-and-sweep, with generational twists,
Yes, more or less.
> that's what gc uses for cyclic garbage.
Do you
On Mon, Oct 10, 2005 at 08:37:03PM +0100, Tom Anderson wrote:
> So python doesn't use the old SmallTalk 80 SmallInteger hack, or similar?
> Fair enough - the performance gain is nice, but the extra complexity would
> be a huge pain, i imagine.
I tried to implement this once. There was not a per
Tom Anderson wrote:
> Except that in smalltalk, this isn't true: in ST, every variable
> *appears* to contain a reference to an object, but implementations
> may not actually work like that. In particular, SmallTalk 80 (and
> some earlier smalltalks, and all subsequent smalltalks, i think)
> handl
On Mon, 10 Oct 2005, it was written:
> Tom Anderson <[EMAIL PROTECTED]> writes:
>
>> Has anyone looked into using a real GC for python? I realise it would
>> be a lot more complexity in the interpreter itself, but it would be
>> faster, more reliable, and would reduce the complexity of extension
On Wed, 12 Oct 2005, Jorgen Grahn wrote:
> On Mon, 10 Oct 2005 20:37:03 +0100, Tom Anderson <[EMAIL PROTECTED]> wrote:
>> On Mon, 10 Oct 2005, it was written:
> ...
>>> There is no way you can avoid making garbage. Python conses everything,
>>> even integers (small positive ones are cached).
>>
>
John Waycott wrote:
> I wrote a simple Python program that acts as a buffer between a
> transaction network and a database server, writing the transaction logs
> to a file that the database reads the next day for billing. The simple
> design decoupled the database from network so it wasn't stres
On Mon, 10 Oct 2005 20:37:03 +0100, Tom Anderson <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Oct 2005, it was written:
...
>> There is no way you can avoid making garbage. Python conses everything,
>> even integers (small positive ones are cached).
>
> So python doesn't use the old SmallTalk 80 Small
[EMAIL PROTECTED] (Alex Martelli) writes:
> > Has anyone looked into using a real GC for python? ...
> > lot more complexity in the interpreter itself, but it would be faster,
> > more reliable, and would reduce the complexity of extensions.
>
> ??? It adds no complexity (it's already there), it'
Tom Anderson <[EMAIL PROTECTED]> wrote:
...
> Has anyone looked into using a real GC for python? I realise it would be a
If you mean mark-and-sweep, with generational twists, that's what gc
uses for cyclic garbage.
> lot more complexity in the interpreter itself, but it would be faster,
> more
Ville Voipio wrote:
> In article <[EMAIL PROTECTED]>, Thomas Bartkus wrote:
>
>>All in all, it would seem that the reliability of the Python run time is the
>>least of your worries.
I agree - design of the application, keeping it simple and testing it
thoroughly is more important for reliabili
In article <[EMAIL PROTECTED]>, Peter Hansen wrote:
> Other than that, we had no real issues and definitely felt the choice of
> Python was completely justified. I have no hesitation recommending it,
> other than to caution (as I believe Paul R did) that use of new features
> is "dangerous" in
In article <[EMAIL PROTECTED]>, Thomas Bartkus wrote:
>
> All in all, it would seem that the reliability of the Python run time is the
> least of your worries. The best multi-tasking operating systems do a good
> job of segragating different processes BUT what multitasking operating
> system meet
Ville Voipio wrote:
> I am not building a redundant system with independent
> instruments voting. At this point I am trying to minimize
> the false alarms. This is why I want to know if Python
> is reliable enough to be used in this application.
>
> By the postings I have seen in this thread it se
Tom Anderson <[EMAIL PROTECTED]> writes:
> Has anyone looked into using a real GC for python? I realise it would
> be a lot more complexity in the interpreter itself, but it would be
> faster, more reliable, and would reduce the complexity of extensions.
The next PyPy sprint (this week I think) is
"Ville Voipio" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
> I would need to make some high-reliability software
> running on Linux in an embedded system. Performance
> (or lack of it) is not an issue, reliability is.
> The soft
Tom Anderson <[EMAIL PROTECTED]> writes:
> Has anyone looked into using a real GC for python? I realise it would
> be a lot more complexity in the interpreter itself, but it would be
> faster, more reliable, and would reduce the complexity of extensions.
>
> Hmm. Maybe it wouldn't make extensions e
In article <[EMAIL PROTECTED]>,
Tom Anderson <[EMAIL PROTECTED]> wrote:
>
>Has anyone looked into using a real GC for python? I realise it would be a
>lot more complexity in the interpreter itself, but it would be faster,
>more reliable, and would reduce the complexity of extensions.
>
>Hmm. May
On Mon, 10 Oct 2005, it was written:
> Ville Voipio <[EMAIL PROTECTED]> writes:
>
>> Just one thing: how reliable is the garbage collecting system? Should I
>> try to either not produce any garbage or try to clean up manually?
>
> The GC is a simple, manually-updated reference counting system aug
You might try a "take over" mode -- starting another copy gets to the
point it looks to listen for UDP, the (if the listening fails), tells
the other process to die over UDP, taking over then. This scheme would
would reduce your "time-to-switch" to a much shorter window. Whenever
given the shutdo
Ville Voipio wrote:
> In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
>
>>I would say give the app the heaviest stress testing that you can
>>before deploying it, checking carefully for leaks and crashes. I'd
>>say that regardless of the implementation language.
>
> Goes without saying. But I
Ville Voipio <[EMAIL PROTECTED]> writes:
> Just one thing: how reliable is the garbage collecting system?
> Should I try to either not produce any garbage or try to clean
> up manually?
The GC is a simple, manually-updated reference counting system
augmented with some extra contraption to resolve
In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
> You might be better off with a 2.6 series kernel. If you use Python
> conservatively (be careful with the most advanced features, and don't
> stress anything too hard) you should be ok. Python works pretty well
> if you use it the way the imple
In article <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
> If you have enough hardware grunt, you could think
> about having three independent processes working in
> parallel. They vote on their output, and best out of
> three gets reported back to the user. In other words,
> only if all three r
Ville Voipio wrote:
> There are a gazillion things which may go wrong. A stray cosmic
> ray may change the state of one bit in the wrong place of memory,
> and that's it, etc. So, the system has to be able to recover from
> pretty much everything. I will in any case build an independent
> process
Ville Voipio <[EMAIL PROTECTED]> writes:
> Goes without saying. But I would like to be confident (or as
> confident as possible) that all bugs are mine. If I use plain
> C, I think this is the case. Of course, bad memory management
> in the underlying platform will wreak havoc. I am planning to
> u
In article <[EMAIL PROTECTED]>,
Steven D'Aprano wrote:
> If performance is really not such an issue, would it really matter if you
> periodically restarted Python? Starting Python takes a tiny amount of time:
Uhhh. Sounds like playing with Microsoft :) I know of a mission-
critical system which
In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
> I would say give the app the heaviest stress testing that you can
> before deploying it, checking carefully for leaks and crashes. I'd
> say that regardless of the implementation language.
Goes without saying. But I would like to be confident (
On Mon, 10 Oct 2005 12:18:42 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>George Sakkis wrote:
>
>> Steven D'Aprano wrote:
>>
>>
>>>On Sun, 09 Oct 2005 23:00:04 +0300, Ville Voipio wrote:
>>>
>>>
I would need to make some high-reliability software
running on Linux in an embedded syste
George Sakkis wrote:
> Steven D'Aprano wrote:
>
>
>>On Sun, 09 Oct 2005 23:00:04 +0300, Ville Voipio wrote:
>>
>>
>>>I would need to make some high-reliability software
>>>running on Linux in an embedded system. Performance
>>>(or lack of it) is not an issue, reliability is.
>>
>>[snip]
>>
>>
>>
Ville Voipio wrote:
>
> The software should be running continously for
> practically forever (at least a year without a reboot).
> Is the Python interpreter (on Linux) stable and
> leak-free enough to achieve this?
Jp gave you the answer that he has done this.
I've spent quite a bit of time since
Steven D'Aprano wrote:
> On Sun, 09 Oct 2005 23:00:04 +0300, Ville Voipio wrote:
>
> > I would need to make some high-reliability software
> > running on Linux in an embedded system. Performance
> > (or lack of it) is not an issue, reliability is.
>
> [snip]
>
> > The software should be running co
On Sun, 9 Oct 2005 23:00:04 +0300 (EEST), Ville Voipio <[EMAIL PROTECTED]>
wrote:
>I would need to make some high-reliability software
>running on Linux in an embedded system. Performance
>(or lack of it) is not an issue, reliability is.
>
>The piece of software is rather simple, probably a
>few h
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> If performance is really not such an issue, would it really matter if you
> periodically restarted Python? Starting Python takes a tiny amount of time:
If you have to restart an application, every network peer connected to
it loses its connection. Thi
On Sun, 09 Oct 2005 23:00:04 +0300, Ville Voipio wrote:
> I would need to make some high-reliability software
> running on Linux in an embedded system. Performance
> (or lack of it) is not an issue, reliability is.
[snip]
> The software should be running continously for
> practically forever (a
Ville Voipio <[EMAIL PROTECTED]> writes:
> The software should be running continously for
> practically forever (at least a year without a reboot).
> Is the Python interpreter (on Linux) stable and
> leak-free enough to achieve this?
I would say give the app the heaviest stress testing that you c
60 matches
Mail list logo
