[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Re: When will Python go mainstream like Java?

Ishwor Gurung

2/23/2010 9:01:00 AM

On 23 February 2010 08:56, AON LAZIO <aonlazio@gmail.com> wrote:
> That will be superb
Yes it would - but I'll just add in few words.

Java - Monstrous language that was Sun's flagship language. Now, it's Oracles.
Python - Hobby-ish hacking language that we all love so much (that we
wish everything was written using Python).

Java - The JVM code been hacked to death by Sun engineers (optimised)
Python - The PVM code has seen speed-ups in Unladen or via Pyrex..
ad-infinitum but nowhere as near to JVM

I like both Python and Java but given the amount of resources put into
JVM and Java (JEE is _huge_ in Enterprise if you didn't know that
already and there are universities that speak Java fluently), it's
kind of sad that Python till the day hasn't seen speedup in mainline
releases.

I see Python more as a hacker's language which will gradually evolve
and support SMEs and alike in the long run than Java (and of course we
write our weekend-only hacking projects in it :-) but for a
market-uptake like Java requires universities, colleges and students
to learn this wonderful little language and requests energetic hackers
to fix lock-contention issues and the like in the core implementation.

Perhaps I see a light, perhaps I see nothing.. but I feel the day is
coming nearer when Python would run as fast as Java/C. Only time can
tell - I hope the time is right about this.
--
Regards
Ishwor Gurung
Key id:0xa98db35e
Key fingerprint:FBEF 0D69 6DE1 C72B A5A8 35FE 5A9B F3BB 4E5E 17B5
23 Answers

Lawrence D'Oliveiro

2/23/2010 11:22:00 PM

0

In message <mailman.99.1266915651.4577.python-list@python.org>, Ishwor
Gurung wrote:

> Java - The JVM code been hacked to death by Sun engineers (optimised)
> Python - The PVM code has seen speed-ups in Unladen or via Pyrex..
> ad-infinitum but nowhere as near to JVM

Python is still faster, though. I think a key reason is that its VM supports
reference-counting, which the Java folks never quite got the grasp of.

So you see, itâ??s all about working smarter, not harder.

John Doe

2/24/2010 1:08:00 AM

0

On Wed, 24 Feb 2010 12:22:05 +1300, Lawrence D'Oliveiro wrote:

>> Java - The JVM code been hacked to death by Sun engineers (optimised)
>> Python - The PVM code has seen speed-ups in Unladen or via Pyrex..
>> ad-infinitum but nowhere as near to JVM
>
> Python is still faster, though. I think a key reason is that its VM supports
> reference-counting, which the Java folks never quite got the grasp of.

So how does Python handle circular references?

Lie Ryan

2/24/2010 1:31:00 AM

0

On 02/24/10 12:08, Nobody wrote:
> On Wed, 24 Feb 2010 12:22:05 +1300, Lawrence D'Oliveiro wrote:
>
>>> Java - The JVM code been hacked to death by Sun engineers (optimised)
>>> Python - The PVM code has seen speed-ups in Unladen or via Pyrex..
>>> ad-infinitum but nowhere as near to JVM
>>
>> Python is still faster, though. I think a key reason is that its VM supports
>> reference-counting, which the Java folks never quite got the grasp of.
>
> So how does Python handle circular references?

There is an optional garbage collector built into the interpreter. Look
at here on how it works: http://python.ca/nas/...

Wanja Gayk

2/24/2010 8:40:00 PM

0

Am 24.02.2010, 00:22 Uhr, schrieb Lawrence D'Oliveiro =

<ldo@geek-central.gen.new_zealand>:

>> Java - The JVM code been hacked to death by Sun engineers (optimised)=

>> Python - The PVM code has seen speed-ups in Unladen or via Pyrex..
>> ad-infinitum but nowhere as near to JVM
>
> Python is still faster, though.

In synthetic microbenchmarks without any practical importance - possibly=
.

> I think a key reason is that its VM supports
> reference-counting, which the Java folks never quite got the grasp of.=


Reference counting is about the worst technique for garbage collection.
Modern Java VM won't count references. They will just trace the active =

references from the rootand mark all objects it finds as active and save=
=

these. The remaining ones are garbage. The reason why this is faster is =
=

that there are usually less live objects than dead ones and there are le=
ss =

refereces to look at.

kind regards

W

-- =

Erstellt mit Operas revolution=C3=A4rem E-Mail-Modul: http://ww...
om/mail/

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Lawrence D'Oliveiro

2/25/2010 1:06:00 AM

0

In message <op.u8nfpex8y5e8ok@laptopwanja>, Wanja Gayk wrote:

> Reference counting is about the worst technique for garbage collection.

It avoids the need for garbage collection. It means I can write things like

contents = open(filename, "r").read()

and know the file object will be immediately closed after its contents are
returned.

It also means I donâ??t have to predefine how much memory my program will use.
A garbage collector will only kick in when the app runs low on memory. On a
system with dynamic memory allocation, that will not happen until the entire
system runs low on memory, unless you limit the app to some fixed amount.
Which is an antiquated way of doing things.

And then thereâ??s caching. Modern CPUs owe most of their speed to assumptions
that programs will obey locality of reference. Pointer-chasing is a cache-
hostile activity. Garbage collection involves a lot of pointer-chasing,
particularly of dead objects that have long since been flushed from the
cache, compared with reference counting of recently-accessed objects.
Therefore garbage collection loses performance.

Ben Finney

2/25/2010 1:32:00 AM

0

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:

> [Reference counting] avoids the need for garbage collection. It means
> I can write things like
>
> contents = open(filename, "r").read()
>
> and know the file object will be immediately closed after its contents
> are returned.

Not quite; it means you know that the object *becomes a candidate* for
cleanup immediately after its contents are returned.

When, or whether, that cleanup actually happens is not something that is
necessarily promised by a reference-counting implementation.

--
\ â??I tell you the truth: some standing here will not taste death |
`\ before they see the Son of Man coming in his kingdom.â? â??Jesus |
_o__) Christ, c. 30 CE, as quoted in Matthew 16:28 |
Ben Finney

sjdevnull@yahoo.com

2/25/2010 7:04:00 AM

0

On Feb 24, 8:05 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message <op.u8nfpex8y5e8ok@laptopwanja>, Wanja Gayk wrote:
>
> > Reference counting is about the worst technique for garbage collection.
>
> It avoids the need for garbage collection.

That's like saying that driving a VW Beetle avoids the need for an
automobile. Reference counting is a form of garbage collection (like
mark-sweep, copy-collect, and others), not a way of avoiding it.

You're right that ref counting in many implementations is more
deterministic than other common forms of garbage collection; IMO,
Python would be well-served by making the ref-counting semantics it
currently has a guaranteed part of the language spec--or at least
guaranteeing that when a function returns, any otherwise unreferenced
locals are immediately collected.

I could be convinced otherwise, but I _think_ that that change would
offer an alternative to all of the interesting cases of where the
"with" statement is "useful".

Paul Rubin

2/25/2010 7:56:00 AM

0

"sjdevnull@yahoo.com" <sjdevnull@yahoo.com> writes:
> IMO, Python would be well-served by making the ref-counting semantics it
> currently has a guaranteed part of the language spec...
> I could be convinced otherwise, but I _think_ that that change would
> offer an alternative to all of the interesting cases of where the
> "with" statement is "useful".

The whole point of introducing the "with" statement was help cleanly get
rid of the ugly and unsound reliance on refcounting semantics found in
so much python code. Your proposal is aimed in the wrong direction.

Paul Rubin

2/25/2010 7:59:00 AM

0

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:
> Pointer-chasing is a cache- hostile activity. Garbage collection
> involves a lot of pointer-chasing, particularly of dead objects that
> have long since been flushed from the cache, compared with reference
> counting of recently-accessed objects. Therefore garbage collection
> loses performance.

Serious gc's these days only touch live data, not garbage; and they work
on small enough regions of memory most of the time (generational
scavenging) to not have too many cache misses. Also, hyperthreading
seems to be coming back, allowing cpu cores to multitask in the presence
of cache misses.

Alf P. Steinbach

2/25/2010 8:35:00 AM

0

* sjdevnull@yahoo.com:
> On Feb 24, 8:05 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>> In message <op.u8nfpex8y5e8ok@laptopwanja>, Wanja Gayk wrote:
>>
>>> Reference counting is about the worst technique for garbage collection.
>> It avoids the need for garbage collection.
>
> That's like saying that driving a VW Beetle avoids the need for an
> automobile. Reference counting is a form of garbage collection (like
> mark-sweep, copy-collect, and others), not a way of avoiding it.
>
> You're right that ref counting in many implementations is more
> deterministic than other common forms of garbage collection; IMO,
> Python would be well-served by making the ref-counting semantics it
> currently has a guaranteed part of the language spec--or at least
> guaranteeing that when a function returns, any otherwise unreferenced
> locals are immediately collected.
>
> I could be convinced otherwise, but I _think_ that that change would
> offer an alternative to all of the interesting cases of where the
> "with" statement is "useful".

Well, relying on ref-counted garbage collection for cleanup actions (other than
reclaiming memory) is pretty brittle in a language based on general garbage
collection. As soon as a reference to X sneaks away somewhere, X doesn't clean
up at scope's end, which is not a catastrophe in itself but means there's no
telling when it happens or indeed whether it happens at all.

I'm not sure but as I recall the D language has a solution to this, sort of
declaring X so that no references to it can be retained anywhere, but it's a
very different language. And Eiffel has the "expanded type" thing for "no
references", but does it use that to support deterministic cleanup? I don't know
whether the Eiffel 'dispose' is called for an expanded object.

C# has a 'using' like Python 'with'. It works, sort of, but adds a lot of
complexity. C++ has the notion of optional garbage collection (formalized in
C++0x) with cleanup actions not tied to memory reclamation but to
deterministically invoked destructors and I think that as an /idea/ that is
clean and good, but in practice almost no-one uses garbage collection with C++,
and reportedly the least unpopular implementation (the Boehm collector) imposes
some very stiff requirements on the code.

So I think there's no really good solution: the price for simplicity in one
dimension is some complexity in another dimension, here deterministic cleanup
and the problem of zombie objects (garbage collection simplifies a lot of things
while zombie objects, objects that have had explicit cleanup performed and thus
are invalid in a sense, compensate by adding back in a lot of complexity).


Cheers,

- Alf