This may be a dumb thing to ask, but besides the penalty for dynamic
typing, is there any other real reasons that Python is slower than Java?
maurice
Jul 18 '05
114  9673 
On Saturday 06 November 2004 05:44 pm, Maurice LING wrote: There is a Chinese saying "waves do not happen without wind." If my
impression of Python and Java is flawed, I am seriously wondering where
it came from? Is it all due to benchmark data from years ago?
Not really. It's an impression you could easily get from several
books about Python (e.g. O'Reilly's "Learning Python"), which
make a rather big deal about Python being slow to execute, but
fast to develop in.
The reality is that it isn't really all *that* slow to execute,
and later versions have gotten quite a bit faster.
But it remains really fast to develop in. ;-)
The resistence to the idea really stems from a sense of rivalry
with Java. Which is really interesting actually, because it
wasn't all that long ago that Python was "just a scripting
language" and Java programmers wouldn't feel threatened by it.
Now they do, I guess. ;-)
It's quite possible that Java programmers console themselves
for all the low-level programming work by thinking the result
will be faster, without really testing to find out. Certainly
Java is going to be faster than Jython (Python running on a
Java platform).
And I have certainly written some extremely poorly optimized
Python programs that positively *crawled*.
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Terry Hancock wrote: The reality is that [Python] isn't really all *that* slow to execute,
and later versions have gotten quite a bit faster.
But it remains really fast to develop in. ;-)
Certainly
Java is going to be faster than Jython (Python running on a
Java platform).
This is sort of like saying that C is faster than Python. To the Java
programmer, it's an excuse to avoid looking at Jython. To the Jython
programmer, it's "Yes, and your point is...?"
The reality is that Jython isn't really all *that" slow to execute.
But it remains really fast to develop in. ;-)
And you can always recode critical sections in Java for speed.
OK, you can probably guess what language I use in my day job now...
Kent
Terry Hancock <ha*****@anansispaceworks.com> wrote: And I have certainly written some extremely poorly optimized
Python programs that positively *crawled*.
My guess is the poor performance had nothing to do with the language you
wrote it in, and everything to do with the algorithms you used.
Local optimizations rarely gets you more than a factor of 2 improvement.
Choice of language (at least within the same general catagory such as
comparing one native compiled language to another, or one virtual
machine language to another) probably has a somewhat broader range, but
still a factor of 10 would be quite surprising.
To get really bad performance, you need to pick the wrong algorithm. A
project I worked on a while ago had a bit of quadratic behavior in it
when dealing with files in a directory. Most of our customers dealt
with file sets in the 100's. One customer had 50,000 files. Going
from, say, 500 to 50,000 is a 100-fold increase in N, and gave a
10,000-fold increase in execution time.
Alex Martelli wrote: Roger Binns <ro****@rogerbinns.com> wrote: Incidentally, that Java code copies one character at a time.
Yep, I noticed -- pretty silly, but if that's how the Java designers
decided the read method should behave by default, who am I to argue?
Just an example I grabbed off the net, first google hit for (if I
recall correctly) java file reading that had the source of a complete
example.
I/O is one area where Java is *very* different than other environments.
Java emphasises the ability to select at runtime (typically from
properties files) how to do things. This is usually done by
having layers of interfaces, and many implementations of factories
and sometimes factories of factories. That ultimately means
the code will work the same for almost any source and destination,
including doing buffering (an interface), byte to character
conversion (an interface), the actual source (an interface),
output (another interface).
Consequently I/O is one of the hardest things for a newbie Java
programmer to do since it appears so complex due to the flexibility
offered. It is also why bad examples exist, because people
find what works for them and post it.
Note how in Python, files do read/write whereas sockets do
send/recv.
But you are comparing Apples to Oranges. Java programs are written
in certain ways with various emphases (flexibility, interfaces and
factories). Python programs emphasise other things (generators,
typing). Exceptions are expensive in Java and not used much. They
are "cheap" in Python and used frequently.
The Python code is reading the entire string into memory and
then writing it.
Right, _Python_'s default.
Arguably Python's default is reading a line at a time, and it
is a bad default in some circumstances (large files), just
as the Java code was a bad way of doing anything but small
files.
The claim posted to this newsgroup, without any support nor examples
being given, was that Python's I/O was far slower than Java's in
_disk-intensive_ operations. I'm still waiting to see any small,
verifiable examples of that posted on this thead.
If the language code is the same, then that claim boils down to
the Java Native Interface vs the Python C API. In the case of
Java, I can see the claim having some relevance in multi-threaded
code since Java doesn't have the GIL.
defaults are tuned, making Python much faster. Great, then let those
who claim Java's I/O is much faster in disk intensive operation post
suitable examples, and we'll see.
Your timing included the overhead of starting up and shutting down
both environments, making the rest of the measure less than
interesting. Perhaps it is also worth linking to the projects done in
Python on SourceForge and elsewhere?
http://sf.net/softwaremap/trove_list.php?form_cat=178
If the message you're keen to send is "Python is great for
open-source", yes. If you're focusing on "Python is great for your
_business_" (as the python *business* forum does, for example), then
emphasizing open-source projects can reasonably be considered
secondary to emphasizing projects that make or save money for the
businesses which developed them.
The idea isn't to emphasise the open source side, but rather so
that anyone can see for themselves how it was all put together.
If I have a business critical app, and claim it is written in
Python but noone can see the insides then they can't really
know too much. The biggest thing is that they can't tell
if they could write code like that (or even how much was written)
to produce an app of similar functionality and complexity.
Roger Not really. It's an impression you could easily get from several
books about Python (e.g. O'Reilly's "Learning Python"), which
make a rather big deal about Python being slow to execute, but
fast to develop in.
Come to think of it, yes, "Python, The Complete Reference", "Programming
Python" and "Learning Python" all seems to have that "speed warning" tag
in the beginning chapters.
If this seems to be the wrong impression, should the authors do something?
The reality is that it isn't really all *that* slow to execute,
and later versions have gotten quite a bit faster.
But it remains really fast to develop in. ;-)
I attest to that, at least for the development speed.
It's quite possible that Java programmers console themselves
for all the low-level programming work by thinking the result
will be faster, without really testing to find out. Certainly
Java is going to be faster than Jython (Python running on a
Java platform).
Jython, as I know, wraps each Python objects in a Java class. For
example, each variable is a class of it own. I suppose this overhead
does have speed penalities on it, simply because "every dash of cheese
is calories, even for low fat cheese."
At the same time, Jython FAQ question 1.6 (how fast is jython?) suggests
that Jython may run 10 times slower than CPython. Personally, I hadn't
seen this kind of performance in my programs yet. On the other hand,
"Jython Essentials" suggest that Jython is about 1.5 times the speed of
CPython (CPython takes about 75% of the time compared to Jython). To
this, I've also not seen this fast in Jython codes myself. I will say
that 2-5 times seems to be a reasonable range.
Cheers
Maurice
Em Sáb, 2004-11-06 Ã*s 22:07 -0500, Roy Smith escreveu: Terry Hancock <ha*****@anansispaceworks.com> wrote: And I have certainly written some extremely poorly optimized
Python programs that positively *crawled*.
My guess is the poor performance had nothing to do with the language you
wrote it in, and everything to do with the algorithms you used.
Well, try to write a Linear Algebra algorithm in pure python... Then
you'll see that pyrex, scipy or the C API are your friends. Of course
algorithmis matters, but for some intensive CPU applications python can
be as slow as 1/100 C using the same algorith. This, of course, matters.
At least if your program is running this kind of operation most of the
time.
Local optimizations rarely gets you more than a factor of 2 improvement.
Choice of language (at least within the same general catagory such as
comparing one native compiled language to another, or one virtual
machine language to another) probably has a somewhat broader range, but
still a factor of 10 would be quite surprising.
10x or 20x difference is likely to hurt you. If you have a 20x slower
computer were you be using the same apps as you use now? For scientific
simulations (which interest me most), it's the difference between get
your results after 1day calculation of one month...
To get really bad performance, you need to pick the wrong algorithm. A
project I worked on a while ago had a bit of quadratic behavior in it
when dealing with files in a directory. Most of our customers dealt
with file sets in the 100's. One customer had 50,000 files. Going
from, say, 500 to 50,000 is a 100-fold increase in N, and gave a
10,000-fold increase in execution time.
This is an extreme case, but is a typical behaviour of how a good
algorithm can modify the execution times of your program: scaling up
neatly. The language matters indeed, but python is well served in a
broad range of libs. For the most CPU intensive tasks there are usually
python bindings for C/C++/Fortran libraries, so it's usually possible to
execute python code at native speeds. This is why I use python in my
(simple) physics applications: scipy gives me a very good interface for
evaluating heavy numeric stuff. When I program in C++ I'm usually
tempted to write a lot of code from the scratch, for I'm lazy to search
for the write libs and learn how they work. I'm a physicist, not a real
programer, so this end up with C++ code slower than python's (which uses
scipy magic).
The point I want to make here is that library programmers usually makes
much better (in the sense it's faster) code than an application
programmer. So, in any language, if you want to write a big project from
the scratch, you'll probably end up with a buggy, slow and cumbersome
library for the 'low level' stuff, and the high level interface will
never move on. If you pick up the existing libs and extend them to
tailor your needs, you have better chances of success. Python seems to
be better than java in this point (at least in the OSS arena), for there
is an enourmously bigger set of libraries you can start with, and is
easier to wrap C/C++/Fortran code to it. So the likely 10% or so runtime
penalty I get for running a C lib through python is more than paid in
application development time. To me, what matters is: can a __python
program__ run as fast as a __c program__? In lots of cases: yes, just
use the right lib.
All this 'java interpreter is faster than python interpreter' nonsense
doesn't appeal to me. For intensive CPU operations, neither interpreters
are good, or even decent, so there is no subistitute for a good o' low
level implementation. Can java use those implementations as easyly as
python? --No-- Does java have a comparable set of low level (fast!) libs
wrapped to it? --Not as rich as python--. So forget the language
shootout contest! Those are not real world examples, they're complete
crap. Python has a richer set of faster libs than java. Use them, so
when it matters, python usually can be faster than java. This is enough
for me for saying that python IS faster than java.
If you care much, a python program can be almost as fast as a C one,
just use a python wrapper to a C lib or use pyrex! This is not saying
that language doesn't matter. Not all so called scripting languages have
the same facilities as python. For instance perl is very optimized to
regex substitution, but lacks more broad biddings for, for example
numeric libraries. We're lucky to use python, we're lucky that it has so
many facilities. Other scripting languages have nice syntax, powerful
builtin objects and other gizmos that make them much more expressive and
productive than the low level counterparts. IMHO python is unique in the
fact that it also provides very nice set of wrapped low level libraries
to run runtime critical pieces of code, so in a lot of cases we can get
the best of both worlds. Java is too much a in between for me: execution
not so fast, but not so slow; development not so fast, but not so slow;
builtins not so expressive, but not so low level either; it is not that
good, neither that bad, etc...
Cheers,
Fabio
On Saturday 06 November 2004 4:10 am, Alex Martelli wrote: with Python 2.4 beta 1 for the roughly equivalent:
inputFile = file("/usr/share/dict/web2", 'r')
outputFile = file("/tmp/acopy", 'w')
outputFile.write(inputFile.read())
inputFile.close()
outputFile.close()
I think a generator version works even better. I did tests at various files
sizes and overall the generator one was better and it was vastly better at
large file sizes and overall the generator one also impacted the system less.
The regular version which reads the whole file at once get really bad with
large files especially if the system is being used.
I suspect the generator version should work with any size file that the os is
capable of working with and should be resource friendly at any size.
Just thought the generator version would be a good comparison to the java
version and strangely enough in many cases it is actually faster then the
regular version. :)
Generator Version:
inputFile = file("/home/kosh/KNOPPIX_V3.6-2004-08-16-EN.iso", 'r')
outputFile = file("/tmp/acopy", 'w')
outputFile.writelines(inputFile)
inputFile.close()
outputFile.close()
Regular Version:
inputFile = file("/home/kosh/temp.txt", 'r')
outputFile = file("/tmp/acopy", 'w')
outputFile.write(inputFile.read())
inputFile.close()
outputFile.close()
The timing was done with python 2.3.4 on debian/sid
Large File Test:
File Copied: 733499392 KNOPPIX_V3.6-2004-08-16-EN.iso
Real User Sys
Gen 0m33.478s 0m4.302s 0m3.542s
Reg 2m28.029s 0m0.010s 0m4.992s *
Reg 0m34.913s 0m0.009s 0m4.713s
* This is how long the first run took. The machine swapped
heavily. The Other time is for subsequent runs. This method
overall uses a massive ammount of ram.
Memory Usage:
Virt Res Shr
Gen 3816K 2364K 2524K
Reg 703M 700M 2524K
Small File Test
File Copied: 2754459 Zope-2.7.2-0.tgz
Real User Sys
Gen 0m0.049s 0m0.023s 0m0.014s
Reg 0m0.037s 0m0.009s 0m0.019s
Tiny File Test:
File Copied: 205 May temp.txt
Real User Sys
Gen 0m0.012s 0m0.007s 0m0.005s
Reg 0m0.028s 0m0.009s 0m0.003s What if we do, _AND_ carefully follow Eric Raymond's excellent
recommendations each and every time we ask for help? Are then we
allowed to loathe and despise the mass of clueless dweebs?-)
I do have to thank you for the story on Plato and his students (in
"reverse jython" thread).
Now that courtnesy is done, I believe you do have all rights not to
reply to all requests for help. As in the law, you have the rights to
remain silent...
I can be a newbie at a bazillion subjects, easily -- but I cannot truly
be a newbie at such tasks as human interaction, social dynamics, general
information retrieval and processing. I can easily guess what will
happen if I enter any mailing list or newsgroup with both guns blazing
out of frustration, for example, and therefore I cannot easily
sympathize with anybody who _does_ behave so foolishly. It's not a
matter of expertise about any specific subject, not even exactly one of
skills, but rather one of personal maturity and character.
Bazillion subjects, my respect. Looking back at this thread...
1. I've asked a question which I may be wrong (many people do that)
2. Some had answered and pointed out my misconceptions, thank you all
for that.
3. Some had pointed to the fact that I am from University of Melbourne
(with unknown motives). It was then clarified that I was an honours
student (www.zoology.unimelb.edu.au) in the Dept of Zoology. Perhaps I
may say that I am a molecular biologist by degree.
4. Some had pointed out instances (books and all) whereby my wrong
impressions might have been formed.
5. Some had painfully taxed on the my initial misconceptions and
generalizing it to the ridicule of non-experts, and in the process of
so, suggesting controversial codes in the pre-text of eliciting responses.
6. Furthering it, using notable words from famous people, to
discriminate against a group of people, when the first instance had been
breached... you can choose not to reply.
All these happens when the discussion had been taken to other areas... I
brings one to wonder on maturity and character......
I know how to search mailing list archives, or google groups ones, and
considerate enough to use this easily acquired and very useful knowledge
to try and avoid wasting other people's time and energy, for example, by
airing some complaint that's been made a thousand times and answered
very comprehensively. When I can't find an answer that way, I ask with
courtesy and consideration and appreciation for the time of the people
who, I hope, will be answering my questions. Etc, etc -- reread Eric's
essay on how to ask for help, it's a great piece of work.
All the knowledge in this world are in libraries and now, networked
libraries via internet. Today, almost all high school students in
developed countries are versed in internet. And by your argument, it
seems that all universities are complete waste of money as all knowledge
is out there and the tools to access the knowledge is readily available.
As mentioned, the discussion is heading else where and my misconceptions
cleared before your replies. If I've indeed forgotten, my sincere
apologies and hereby thank you for your time and efforts.
That doesn't mean a newbie isn't always welcome, _if_ they show any sign
whatever of being worth it. But asking for tolerance and patience
against _rude_ newbies which barge in with shrill, mostly unjustified,
repetitious complaints, is, I think, a rather far-fetched request.
Alex
You still have the right to remain solemn.
maurice
Maurice LING <ma*********@acm.org> wrote:
I've already said the following and was not noticed:
1. it is a disk intensive I/O operation.
2. users delay is not in the equation (there is no user input)
3. I am not interested in the amount of time needed to develop it. But
only interested execution speed.
It is fabulous that you are able to enumerate your list of requirements so
completely. I'm quite serious; many people embark on even complicated
projects without a clear understanding of the tradeoffs they will
encounter.
However, given that set of needs, why would you mess with an "exotic"
language at all? Why wouldn't you just write straight to the metal in C++
or C?
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc. It is fabulous that you are able to enumerate your list of requirements so
completely. I'm quite serious; many people embark on even complicated
projects without a clear understanding of the tradeoffs they will
encounter.
However, given that set of needs, why would you mess with an "exotic"
language at all? Why wouldn't you just write straight to the metal in C++
or C?
Perhaps you can attribute it to C-phobia.
maurioce
Maurice LING <ma*********@acm.org> wrote:
dude that "comparision" from twistedmatrix you refrence is ANCIENT!!!
I am wondering the impact when IBM decided that the base memory to not
exceed 64kb, in the late 1960s...
What??? If you are referring to the original IBM PC, which did ship with
64k base memory, that was 1980, not 1960. You could certainly order one
with more than 64kB.
In the late 1960s, IBM was worrying about the System/360. It had a lot
more than 64kB of base memory.
it is comparing versions that are YEARS out of date and use!
Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
deprecated?
For new development, yes, Python 1.5.2 has been totally replaced. There
are legacy applications running in Python 1.5.2 that aren't worth the
trouble to upgrade.
Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
bootstrapping to LISP compiler.
That's just silly. It is true that LISP was one of the pioneers of the
compiled languages, but other compilers were not written in LISP. Almost
without exception, compilers were all written in assembly language until
Pascal came around.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Israel Raj T wrote: Kendall Clark <ke*****@monkeyfist.com> writes:
The main reason Java is "faster" is because
I would reject the premise entirely.
When looking at desktop apps made with Python, they positively whiz
when compared to Java swing apps.
Let's give a shout out to the GIL! Woo GIL! More seriously, I'd give
up Java's theoretical thread scalability any day in return for the ease
of Python's C API. Not that I've tried to code a C extension for either
language; but I get the impression the GIL is an important part of
making Python easy to use, and I frequently take advantage of the
extensions other people have written, and I'm betting there'd be less of
them without the GIL. They seem uncommon in Javaland.
As for non desktop apps, the entire portage system of Gentoo is
written in Python. 'emerge sync' causes a python app to synchronise a
local application database with database at a non-local mirror. It is
i/o intensive and appears to work very well and very fast.
Here, I'm betting it's fast because of a good implementation; because
emerge can avoid doing work, rather than obsessing about doing the work
quickly. For something like emerge, there's huge potential in caching,
dependency checking, and generally being smart about the tradeoffs.
This will apply to any program that uses the network, a database, large
files, or any of those other time sinks that easily outweigh CPU
performance. If you can get the job done in Python in half the time (or
better), that gives you more time to make the application faster.
--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org
> so as a result, I ask questions trying to describe the abstract case of what I'm trying to do so that I don't get distracted down a rathole of
defending the application. Needless to say, I suspect others are doing
the same thing and it's really really hard to describe the abstract case
in a way that's clear.
It is indeed tough to describe a situation in many cases. This may be
due to 3 cases, firstly, it will be extremely long and tedious to
describe the rationale for a decision or a situation. Secondly, during
idea explorations, the codes are not even written and there is no way to
present any codes in newsgroups because they simply hadn't existed yet.
Thirdly, it may be legally criminal to post any codes without prior
clearance.
Even in academic institutions, because there are many industry sponsored
projects, it is common these days that examiners of theses need to sign
a NDA beforehand...
maurice
> 3) Links to threads that answer common questions Yes, there is an FAQ and yet people still ask why Python gets division
wrong. But I've often seen people dig up links to threads for questions
perhaps not so common to be written up in an FAQ, but perhaps common
enough to merit linking on a wiki page. I'm not under the illusion that
it would solve the problem on its own, but it might well head some
repeat questions off. For those it doesn't, it would give an easy way to
answer.
This may be useful but it will certainly bring us a new set of questions
then, in the form of "is this <whatever information> still holds for
<some latest version of python>?" Although computer science stems from
mathematics, it had lost an important aspect of mathematics, that is,
"once proven true is forever true."
maurice
> What??? If you are referring to the original IBM PC, which did ship with 64k base memory, that was 1980, not 1960. You could certainly order one
with more than 64kB.
In the late 1960s, IBM was worrying about the System/360. It had a lot
more than 64kB of base memory.
I was thinking about the part whereby a program is allocated 64k memory
and other allocations are heap allocations which needs pointers. I
vaguely recall Turbo Pascal manual mentioned that you cannot statically
allocate more than 64k of variable memory, which is why pointers are
needed to circumvent it. And there is something called extended memory
manager (EMM386.com or something) in DOS 5 that is needed to address up
to 640kB of memory or something...
DISCLAIMER: before I am flamed again, I wish to say that these are from
vague memories of more than a decade ago. I may be COMPLETELTY WRONG. I
was then still an early teens trying to get my games running......
it is comparing versions that are YEARS out of date and use!
Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
deprecated?
For new development, yes, Python 1.5.2 has been totally replaced. There
are legacy applications running in Python 1.5.2 that aren't worth the
trouble to upgrade.
Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
bootstrapping to LISP compiler.
That's just silly. It is true that LISP was one of the pioneers of the
compiled languages, but other compilers were not written in LISP. Almost
without exception, compilers were all written in assembly language until
Pascal came around.
I'm wrong again. I suppose what I am trying to suggest is that design
decisions made in the last may have a longer effect than what we
consciously think. At least this is the impression I get while reading
James Gosling's argument that Java should be object-oriented from day 1
(and not added onto the language, like in C++) in The Java Programming
Environment: A white paper.
maurice
Maurice LING said unto the world upon 2004-11-07 01:04: > 3) Links to threads that answer common questions
Yes, there is an FAQ and yet people still ask why Python gets division
wrong. But I've often seen people dig up links to threads for questions
perhaps not so common to be written up in an FAQ, but perhaps common
enough to merit linking on a wiki page. I'm not under the illusion
that it would solve the problem on its own, but it might well head
some repeat questions off. For those it doesn't, it would give an easy
way to answer.
This may be useful but it will certainly bring us a new set of questions
then, in the form of "is this <whatever information> still holds for
<some latest version of python>?" Although computer science stems from
mathematics, it had lost an important aspect of mathematics, that is,
"once proven true is forever true."
maurice
Dang.
I already suspected that only a minority would check such a
resource. On reflection, I think you are likely correct many of that
minority would then end up asking the sort of question you indicate.
That *would* be better, but probably not enough so as to make the effort
of maintaining the resource seem worth the candle. :-(
Of the 3 parts I posted about, this one was the one I am least able to
do a draft of anyway. I think I will take a go at the other two, though.
Best,
Brian vdB
Tim Roberts <ti**@probo.com> wrote: Maurice LING <ma*********@acm.org> wrote:
I've already said the following and was not noticed:
1. it is a disk intensive I/O operation.
2. users delay is not in the equation (there is no user input)
3. I am not interested in the amount of time needed to develop it. But
only interested execution speed.
It is fabulous that you are able to enumerate your list of requirements so
completely. I'm quite serious; many people embark on even complicated
projects without a clear understanding of the tradeoffs they will
encounter.
However, given that set of needs, why would you mess with an "exotic"
language at all? Why wouldn't you just write straight to the metal in C++
or C?
Perhaps because point 3 has _never_ been true as stated? Nobody would
really be happpy to take 40 years more to develop a program in order to
shave a second off each hour-long run (well, maybe somebody _has_ taken
that choice 30 years ago, and we'll see their program in 10 more years).
There is always, at some point, a tradeoff - the only issue is where.
Otherwise, "to the metal" would be assembly or microcode, btw.
If a program is anyway spending its time waiting for disk, network, or
other I/O, the benefits of compressing the already-small CPU part are
tiny, by Amdahl's Law. On the other hand, ease of experimentation with
different program architectures -- for example trying to overlap some of
the I/O waits rather than serialize them -- could still help.
Alex
Roger Binns <ro****@rogerbinns.com> wrote:
... I/O is one area where Java is *very* different than other environments.
Java emphasises the ability to select at runtime (typically from
Python's dynamism at runtime is definitely one of its fortes.
Note how in Python, files do read/write whereas sockets do
send/recv.
Sure, since the semantics are different. Which is why we have the
makefile method of socket objects: for those occasions in which you want
signature-polymorphism at the expense of the overhead of adaptation.
But you are comparing Apples to Oranges. Java programs are written
in certain ways with various emphases (flexibility, interfaces and
factories). Python programs emphasise other things (generators,
typing). Exceptions are expensive in Java and not used much. They
are "cheap" in Python and used frequently.
Generators are a reasonably recent addition to Python, and I have no
idea what you mean by stating that Python emphasizes typing more than
Java does -- I typically see far more mention of the types of everything
in Java code than in Python, where the usual duck-typing generally
obviates the need. Python's flexibility is definitely one of its
fortes, and while duck typing obviates much of the need for explicit
interfaces, nevertheless they're getting popular in large Python
frameworks. And factory-based design patterns are everywhere in Python,
of course; indeed, it's in Java that you see lots of 'new ThisClass'
constructs which build an instance of some hardwired concrete class --
in Python, instantiation is generally by calling, which makes it
trivially easy to arrange for a function, rather than a class, to be
called, getting factory-effect. Do not underestimate the flexibility
you get by classes and functions being first-class objects, passed as
arguments as easily as any other, ready to call for instantiation...
In other words, I do not consider your observations to be at all well
founded; the one about exceptions is rather inapplicable to the example
codes posted so far. If, as the OP claimed, Python is slower than Java
for disk-intensive programs, this should be easy for him to show, and I
have not seen it shown yet.
The Python code is reading the entire string into memory and
then writing it.
Right, _Python_'s default.
Arguably Python's default is reading a line at a time, and it
Not for the somefile.read method -- read doesn't do lines. You may be
thinking of iter(somefile).next instead, and I'm not sure what the Java
equivalent of _that_ one is.
is a bad default in some circumstances (large files), just
as the Java code was a bad way of doing anything but small
files.
Python's default makes it trivially easy to read most files in a single
gulp, so it's appropriate in many cases; Java's makes it hard and slow
to read ANY file, so it's never appropriate.
The claim posted to this newsgroup, without any support nor examples
being given, was that Python's I/O was far slower than Java's in
_disk-intensive_ operations. I'm still waiting to see any small,
verifiable examples of that posted on this thead.
If the language code is the same, then that claim boils down to
the Java Native Interface vs the Python C API. In the case of
Java, I can see the claim having some relevance in multi-threaded
code since Java doesn't have the GIL.
Python does, but drops it during blocking I/O operations so that the
relevance should be just about the same in both cases.
defaults are tuned, making Python much faster. Great, then let those
who claim Java's I/O is much faster in disk intensive operation post
suitable examples, and we'll see.
Your timing included the overhead of starting up and shutting down
both environments, making the rest of the measure less than
interesting.
If the OP intended their claim to apply only to long-running programs
where the difference in environment startup/shutdown gets fully
amortized, they *MIGHT* have deigned to mention the fact. I have seen
no such claim yet, nor as yet ANY benchmark posted that purports to
prove anything related to the original claim.
I did observe (at some point along the substantial chain of small
benchmarks I and some other posters exchanged) that the 4:1 ratio in
runtime in favour of Python exactly matched the 4:1 ratio in pagefaults,
again in favour of Python, btw. I guess the startup/shutdown costs can
be amortized by simply looping over the filecopy operation N times.
The idea isn't to emphasise the open source side, but rather so
that anyone can see for themselves how it was all put together.
If I have a business critical app, and claim it is written in
Python but noone can see the insides then they can't really
know too much. The biggest thing is that they can't tell
if they could write code like that (or even how much was written)
to produce an app of similar functionality and complexity.
However, firms that choose not to release their business critical
applications as open source are likely to require at the very least a
non-disclosure agreement before they show you those sources, making it
impractical to use those sources to meet your wishes.
Note that even GPL would be no use here: if you do not _distribute_ your
programs, but keep them for in-house use, you keep the option to not
show anybody those programs' sources even when GPL applies. Therefore,
the problem applies equally to all languages, even a hypothetically
GPL'd one (not that I know of any GPL-covered language in common use for
writing business critical apps).
As for your latter sentence, I've never met a programmer whose default
assumption was that they would NOT be able to write code just as good as
most anybody else's.
Alex
Maurice LING <ma*********@acm.org> wrote:
... 1. I've asked a question which I may be wrong (many people do that)
So how would you react if somebody asked a question that _takes for
granted_ something that you strongly believe is not the case, to the
point of absurdity? Say somebody posted to a local NG or mailing list
about Melbourne nightlife, asking for explanations of why the bands
playing in Melbourne clubs are so much worse than those playing in
Canberra ones. No justification of the assertion, as if it was so
obvious it didn't need any, just a request for an explanation. And say
later the same guy clarified the claim by stating, again without ANY
supporting data, that his criterion is based on bands' records and how
well they place in the hit parades -- and again, not asking _whether_
Melbourne's scene is inferior by that measure, not even stating _that_
it is and inviting rebuttal, but still expressing himself as if this was
so EVIDENTLY the case that an explanation of WHY was all he needed.
To make you more personally involved in the issue, imagine that you had
spent lots of time and energy convincing friends and acquaintances to
move to Melbourne, rather to Canberra, based in some part on how much
better the club music scene is in Melbourne. And you even had some
little involvement in the past in trying to arrange for some Melbourne
clubs to get in contact with some hitparade-successful bands.
Now, even if you personally care little about hit parades, it seems
sensible for you to review the bidding -- if nothing else, to be able to
qualify future advice to other friends, or, if needed, try to help clubs
and bands get in touch again.
And you can't find *ANY* support for the unquestioned-assumptions, "so
obvious they only need explanation", behind that guy's questions. As
far as you can tell, Melbourne's clubs have about FOUR times more bands
that place high on the hit parade playing on typical nights than
Canberra clubs do.
So, would you be quiet and let Melbourne's reputation get sullied when
you believe to have data to show that? Or would you rather relate your
own observations, and challenge the original poster to come out and
*GIVE* those data he was basing his "too obvious to question" underlying
assumptions?!
2. Some had answered and pointed out my misconceptions, thank you all
for that.
Does this imply you now believe that the unquestioned-assumptions behind
your "why" questions were unfounded?
3. Some had pointed to the fact that I am from University of Melbourne
(with unknown motives). It was then clarified that I was an honours
student (www.zoology.unimelb.edu.au) in the Dept of Zoology. Perhaps I
may say that I am a molecular biologist by degree.
I have no idea about [3]. One of my best friends in Australia is in
Melbourne now (Canberra previously). I do occasionally hear snide jabs
at Melbourne, but those are generally from _Sidney_ people, so I tend to
discount them appropriately;-).
As for your professional specialization, how would it make you feel and
react if somebody posted a question such as, say, "why are the
nucleotides in cats' cells so different from those in dogs'?". Not a
good parallel, I guess, because in this case the total and utter
cluelessness of the asker and absurdity of the question are entirely
obvious -- you would not need any research to confirm that, nor would
you need to fear anybody else getting misled from this question. So
please find something slightly subtler, but just as wrong, and focus on
a poster taking the wrong underlying assumption so much for granted that
they only need to ask about WHY things are (obviously, w/o any need for
discussion or confirmation) that way...
4. Some had pointed out instances (books and all) whereby my wrong
impressions might have been formed.
Forming a wrong impression is always a possibility. It's proceeding to
take it for granted as an obvious fact, that is quite questionable. If
you had phrased your observation in terms such as "I have gotten the
impression, without having done any measurement myself, that" etc, the
reactions would have been vastly different; your choice to express
yourself by implying an unquestionable fact existed and only required
explanations of its reasons, is a good part of the reaction's cause.
5. Some had painfully taxed on the my initial misconceptions and
generalizing it to the ridicule of non-experts, and in the process of
so, suggesting controversial codes in the pre-text of eliciting responses.
Well I _did_ get responses, which easily led to Python and Java programs
that are strongly equivalent (same buffer sizes, and all), with a 4:1
performance advantage for Python (perhaps explainable by Java's terrible
startup/shutdown performance, with 4:1 ratio of pagefaults to Python's;
pagefaults, of course, _can_ be seen as disk-intensive, too;-).
6. Furthering it, using notable words from famous people, to
discriminate against a group of people, when the first instance had been
breached... you can choose not to reply.
Just like you could choose to stay silent, and let some assertions and
implications against the Melbourne club scene stand unchallenged when
you believe you can show those "stated as too obvious to discuss"
implications are totally wrong, ill-founded, and reverse of the truth.
If you let the untruth stand unchallenged, quite apart from the sympathy
for truth that many of us feel, you'd badly serve anybody who,
considering a move to Melbourne in the near future, might "do their
homework", research recent Melbourne/Canberra comparisons, and find that
apparently nobody questions with any real data the "too obvious to
discuss" assumption about bands playing in clubs. Plus, you'd waste the
effort that weirdly implied assumption prompted you to, in order to
start researching the issue a bit.
If you do post what you have, you serve well anybody who's looking up
the issue in the future, AND get a chance to see what solid data the
original poster based their taken-for-granted assumptions on -- IF ANY.
All these happens when the discussion had been taken to other areas... I
brings one to wonder on maturity and character......
_ALL_? Re [5], I'm still trying to get a good benchmark going -- I
expect to observe roughly 1:1 ratio (net of startup and shutdown) when
that's the case. Why is that "other areas" wrt your original question
of WHY (things were obviously, undisputably in a state they aren't)?
Are you claiming that, if one asks "why is the sky yellow?", striving to
show him and everybody else that it *ISN'T* is "taking to other areas"
the discussion?! I entirely disagree. Phrasing the original question
as a "why" was one issue surely deserving of metadiscussion, but I find
it perfectly appropriate (and a sign of impeccable character and
maturity) to rephrase the question to a better "is it the case that" and
trying to explore that in this enhanced form; including explanations of
one's observations in the matter (e.g., the one about the 4:1 pagefault
ratio that's clearly part of the slowdown of Java wrt Python here).
All the knowledge in this world are in libraries and now, networked
False: not all knowledge in the world can be usefully embodied in print
(text, images, even videos and sound recordings actualy). An important
part of human knowledge is experiential, and only a shadow of that
important part can be captured in libraries, including multimedia ones.
libraries via internet. Today, almost all high school students in
developed countries are versed in internet. And by your argument, it
seems that all universities are complete waste of money as all knowledge
is out there and the tools to access the knowledge is readily available.
Many universities, as a part of their mission, conduct research and
therefore presumably generate new knowledge. This entirely self-evident
and obvious fact, even by itself, makes your assertion doubly absurd:
"all knowledge is out there" readily implies there is no knowledge to be
added, and "all universities are complete waste of money" similarly
implies no university is generating new knowledge, or what they do
generate is utterly worthless.
Your assertion that "by my argument" (which had never touched anywhere
upon the research role of universities) research is nonexistent, futile,
or entirely worthless, is at the same time absurd and deeply insulting.
If and when I want to criticize university research, I will do so
myself, and I do not AT ALL appreciate this attempt to put words in my
mouth, even though any reader with a 3-digits IQ can see it as the
insulting absurdity it is.
If we stick to the _teaching_ role of universities, the reasons my
arguments imply nothing like you're stating are both more interesting
and subtler. On one hand, there is the experiential side of knowledge.
By conducting experiments in a laboratory under proper guidance, even
though those experiments are not novel, students acquire knowledge
experientially -- a very different learning mechanism from reading books
and articles, or listening to lectures. Of course, good high schools
have laboratories etc, too, but in University, at least in scientific
and technical disciplines, the experiential learning process _should_
blossom to a far higher degree (if it doesn't -- if a university skimps
on labs and overwhelms students with just books and lectures -- then
that may well be a valid ground for criticism, _of that particular
university's choice in didactics_, of course, not "of all
universities"). In other disciplines, experiential learning may be less
obvious, but if the university is any good, it will be there.
And then, there is the issue of selection and structuring. I have
posted about that recently, in a thread asking whether there was a book
about large-scale software development with Python, and you can easily
look it up on google groups. To summarize: I have lots of materials on
the subject. I find I'm easily able to organize these materials into
courses and workshops that are specifically aimed at an identified group
of students, with certain backgrounds and interests. Organizing the
same material into a _book_ is a far harder task, one which I can't take
the time off to undertake at present... which ties back to a _part_ of
the reason why not all knowledge is in books or other printed or
otherwise 'frozen' (recorded, filmed, ...) forms. A vast majority of
the materials I collected IS out there -- over the years, I've posted a
goodly fraction of it. But it's generally unselected and unstructured,
making the learning task far more daunting than proper structuring and
selection can potentially make it.
A good university course has selection and structuring, and is
interactive in a way a book can never be, thus potentially making the
s&s more appropriate and effective for the specific individual students
who are taking that course wrt books (or some other well-organized
subset of info from the net). Of course, if you throw 500 students at a
poor professor, no matter how good he is, his ability to teach a really
good course will be impaired -- smaller classes are MUCH better that way
(another valid criticism of the way many universities are structured).
Usenet does have the interactivity advantage, but normally not the
structuring one, with rare exceptions, and only to some extent the
selection one. Thus, it can complement rather than substitute for
books, courses, and information search on the raw net. It has little
experiential value, though not zero -- _some_ of the interaction on it
does work to stimulate and vaguely guide/aim some experiences.
As mentioned, the discussion is heading else where and my misconceptions
cleared before your replies. If I've indeed forgotten, my sincere
apologies and hereby thank you for your time and efforts.
Thanks, this is appreciated. I take it then that you do not any longer
opine that on disk-I/O intensive programs Python is self-evidently
slower than Java?
You still have the right to remain solemn.
Heh, nice. Well, it's a right I surely exercise far more often than the
more traditional one of remaining silent;-).
Alex Maybe as the old-timers go off, the next batch of old-timers feel that
it is too much to handle. Nobody requires anyone to answer to all
threads.....
Nevertheless I still have to thank Alex for his story on Plato and the
studetn who questioned the validity of studying geometry before
philosophy (in "reverse Jython" thread).
maurice
On 2004 Nov 07, at 11:37, Maurice LING wrote: Mainly to Alex and the rest of the adjitated community,
[snip about Melbourne club scene]
I do understand what you meant. There are restrictions in giving out
data (codes) in many cases and I seek your understanding.
Sure, if you need help understanding or fixing the behavior of
proprietary codes, that's harder. Nevertheless, although not a
work-free process, it IS often productive to try and extract a small
core of code that reproduces a performance problem. If you can't
reproduce the problem on a small scale (small in terms of lines of
code, not in quantity of data), that's significant too. Best is when
you _can_ reproduce it, because then you do have code you can post and
get free expert help about!
Nevertheless, I do feel that you had unfairly made use of this case to
voice out your accumulated dissatisfaction with answering newbies
questions.
I disagree: somebody else commented on newbie-friendliness of this
group, and my discussion was in response to their comments.
In later parts of this thread (after your post), it was suggested that
my errorous impressions might have been formed by books and
publications (such as "learning python", as suggested)...... I do not
seek to place blame on anyone for my misconceptions. But considering a
person trying to learn a new programming language, it is common that
the person takes in what is presented in the face, especially from
books such as, "Learning python" and "Python, the complete reference".
I have not seen "learning python" mentioned in this thread -- funny,
because I did read all posts; having been a tech reviewer for (2nd
edition) Learning Python, I'd have been quite interested (if nothing
else, to check if the guilty passage WAS one I had remarked on, and my
remarks had not been taken into account by the authors, or something
that had escaped me). I'll googlegroup in a few days when the archive
has had a chance to update.
Does this imply you now believe that the unquestioned-assumptions
behind
your "why" questions were unfounded?
Now I will say that Python is comparable to Java in terms of disk I/O.
This makes sense to me. Java apparently has more traps and pitfalls,
but once you're expert enough to bypass them, if program
startup/shutdown is no problem (long-running program), both Java and
Python should be able to saturate the disk bandwidth capacity,
normally.
All in all, through all these discussions, I can safely assert that
Python and Java are comparable in disk I/O. And a part of the original
misconceptions might have been formed possibly out-dated printed
materials which are still references for new python programmers. It is
then my concern that such misconceptions may be perpentuated.
I share your concerns in this regard. Which is why I'll be quite
interested to check "Learning Python" once I do get the specific
reference on google groups. I'm not sure what that "complete
reference" book _IS_ -- there is probably nothing we can do about that
one. But good publishers CARE, and O'Reilly IS a good publisher, so,
if Learning Python has some serious error, we can surely get it fixed
next printing!!!
I admit and apologise for my poor phrasing of questions which sparked
this chain of events. We had all lost some cool along the way and some
harsh words flew. Alex, I do hope you will accept my apologies. I
suppose I am pissed off when the flare is targetted towards myself and
not the situation. Anyway, my apologies...
Thanks!, and my apologies in return if the way I responded to other
people's comments about generic newbie-friendliness were poorly worded
and made you feel unfairly targeted for other people's mistakes. That
was not my intention, please be sure of that.
I _am_ interested in pursuing the issues of possible errors in Python
books, AND I/O performance issues in Python vs Java, btw, if anybody
wants to. The fact that _in theory_ there shouldn't be any such
issues, doesn't mean that some couldn't be found _in practice_ where we
(or JVM coders;-) goofed or took justifiable but unfortunate design
decisions...;-).
Alex
Dear Terry,
Not really. It's an impression you could easily get from several
books about Python (e.g. O'Reilly's "Learning Python"), which
make a rather big deal about Python being slow to execute, but
fast to develop in.
Do you have any idea which part of the book or chapter or passage which
suggests this? Apparently here appears to be a technical fault in the
book and Alex (in cc) is one of the technical reviewers of "Learning
Python" and is trying to fix this...
The reality is that it isn't really all *that* slow to execute,
and later versions have gotten quite a bit faster.
But it remains really fast to develop in. ;-)
The resistence to the idea really stems from a sense of rivalry
with Java. Which is really interesting actually, because it
wasn't all that long ago that Python was "just a scripting
language" and Java programmers wouldn't feel threatened by it.
Now they do, I guess. ;-)
It's quite possible that Java programmers console themselves
for all the low-level programming work by thinking the result
will be faster, without really testing to find out. Certainly
Java is going to be faster than Jython (Python running on a
Java platform).
And I have certainly written some extremely poorly optimized
Python programs that positively *crawled*.
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
On Sat, 06 Nov 2004 21:40:46 -0800, Tim Roberts wrote: Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
bootstrapping to LISP compiler.
That's just silly. It is true that LISP was one of the pioneers of the
compiled languages, but other compilers were not written in LISP. Almost
without exception, compilers were all written in assembly language until
Pascal came around.
Lisp had the first compiler for language X to be written in language
X, and used to compile itself (and presumably the first to be written
in any high level language), but not the first compiler in existence,
and non-Lisp compilers were not generally written in Lisp, no.
[There were C, Pascal, Ada and Prolog compilers written in Lisp,
though]
--
Never say #+never
-- Erik Naggum
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
"Bryan" <be*****@yahoo.com> wrote: also, just for fun, write the following fully
working python program in java:
import time
t = time.time()
s = open('in.txt').read()
open('out.txt', 'w').write(s)
print time.time() - t
OK. I will rewrite it in Java.
///
long t = currentTimeMillis();
tryCopyFile("in.txt","out.txt");
out.println( (currentTimeMillis() - t) / 1000);
///
You lost. The Java-version is shorter!
I didn't count import- and import static-statements
because Eclipse cares about imports automatically.
But maybe you want to have something more fun?
How about that?
read autoexec.bat,
sort the lines
create sorted_autoexec.bak
///
File source = new File("c:/autoexec.bat");
File destination = new File("c:/sorted_autoexec.bak");
String[] lines = readLines(source);
lines = sort(lines);
write(destination,lines);
///
You lost.
You Pythonistas are a bunch of losers.
And your language is dog-slow.
Eeeeeek.
And try to write Eclipse with your Mickey-Mouse-language!
<j>
Pythogoras
Roy Smith <ro*@panix.com> wrote: Terry Hancock <ha*****@anansispaceworks.com> wrote: And I have certainly written some extremely poorly optimized
Python programs that positively *crawled*.
My guess is the poor performance had nothing to do with the language you
wrote it in, and everything to do with the algorithms you used.
I think this is an overbid.
Local optimizations rarely gets you more than a factor of 2 improvement.
Choice of language (at least within the same general catagory such as
comparing one native compiled language to another, or one virtual
machine language to another) probably has a somewhat broader range, but
still a factor of 10 would be quite surprising.
kallisti:/tmp alex$ python -mtimeit 'exec("x=2")'
10000 loops, best of 3: 64.7 usec per loop
kallisti:/tmp alex$ python -mtimeit 'x=2'
10000000 loops, best of 3: 0.187 usec per loop
There: a factor of 350 just for using the wrong construct in the same
language -- a silly exec rather than a plain assignment.
To get really bad performance, you need to pick the wrong algorithm. A
project I worked on a while ago had a bit of quadratic behavior in it
when dealing with files in a directory. Most of our customers dealt
with file sets in the 100's. One customer had 50,000 files. Going
from, say, 500 to 50,000 is a 100-fold increase in N, and gave a
10,000-fold increase in execution time.
Right, big-O can often dominate (there are exceptions: in almost all
practical cases the outstanding performance of Python's list.sort wipes
away the theoretical issue that it's O(N logN), letting dominate for
many special cases approaches that are O(N) -- the multiplicative
constants differ by just TOO much for all practically usable N's!-).
Still, consider...:
kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(1000): s = s+[x]'
100 loops, best of 3: 13.7 msec per loop
kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(1000): s += [x]'
1000 loops, best of 3: 1.58 msec per loop
The difference between s += [x] and s = s + [x] is large. AND:
kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(4000): s = s+[x]'
10 loops, best of 3: 224 msec per loop
kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(4000): s += [x]'
100 loops, best of 3: 6.4 msec per loop
....the big-O is different!!! O(N) for +=, way bigger for plain +: as
you can see, a x4 on N makes a 16.3 times increase in time here,
suggesting AT LEAST quadratic behavior. Again, these are good vs bad
cases in the *same* language - Python 2.4 beta 1 in all cases. I'm sure
you can easily imagine how different languages might make apparently
identical constructs be O(N) vs O(N squared) or worse, if even the same
language can do so for constructs whose difference may not be apparent
at all to the newbie...
Alex
Maurice LING <ma*********@acm.org> wrote: Not really. It's an impression you could easily get from several
books about Python (e.g. O'Reilly's "Learning Python"), which
make a rather big deal about Python being slow to execute, but
fast to develop in.
Come to think of it, yes, "Python, The Complete Reference", "Programming
Python" and "Learning Python" all seems to have that "speed warning" tag
in the beginning chapters.
If this seems to be the wrong impression, should the authors do something?
I guess they should, if they care about what they're communicating.
This is how I put the issue in "Python in a Nutshell":
'''
Good compilers for classic compiled languages can often generate binary
machine code that runs much faster than Python code. However, in most
cases, the performance of Python-coded applications proves sufficient.
When it doesn't, you can apply the optimization techniques covered in
Chapter 17 to enhance your program's performance while keeping the
benefits of high programming productivity.
'''
I'm biased, having written this, but it seems a balanced set of
assertions which tries hard not to leave either wrong impression.
Alex
Pythogoras wrote: OK. I will rewrite it in Java.
///
long t = currentTimeMillis();
tryCopyFile("in.txt","out.txt");
out.println( (currentTimeMillis() - t) / 1000);
///
You lost. The Java-version is shorter!
I didn't count import- and import static-statements
because Eclipse cares about imports automatically.
I don't know what version of Java they're using in this troll's fantasy
land, but tryCopyFile does not, and has never existed in any Java
implementation. The real code for copying a file would look something
like the contents of this function (which is not a part of the standard
library):
public static void copy(File source, File dest) throws IOException {
FileChannel in = null, out = null;
try {
in = new FileInputStream(source).getChannel();
out = new FileOutputStream(dest).getChannel();
long size = in.size();
MappedByteBuffer buf = in.map(FileChannel.MapMode.READ_ONLY,
0, size);
out.write(buf);
} finally {
if (in != null) in.close();
if (out != null) out.close();
}
}
Maurice LING <ma*********@acm.org> wrote:
dude that "comparision" from twistedmatrix you refrence is ANCIENT!!!
I am wondering the impact when IBM decided that the base memory to not
exceed 64kb, in the late 1960s...
??? IBM in the '60s was developing the then-revolutionary concept of a
*family of computers* -- several models able to run the same codes with
different performance and price. "360 degrees computing", whence came
the idea of calling that family "IBM 360". Out of the 32 bits of a
register's width, only 24 bits were in fact used for addressing, so the
limit was *16 megabytes* of base memory -- 40 years ago, that not only
SEEMED huge, it WAS huge. To the point that Motorola in the late
'70s/early '80s took exactly the same architectural decision regarding
*their* (less-revolutionary...) 16-bit microprocessor, the 68000: again
32-bit registers, but, again, 24-bit addresses. The point being that,
about 15+ years later (10 doublings by Moore's Law!!!), IBM's crucial
architectural decision STILL seemed quite reasonable, albeit when
thinking of microcomputers rather than mainframes.
If you're thinking of IBM PC's, the key architectural decision there had
come from intel (8086 then 8088), again in the late '70s, and it _was_
way too restrictive -- just 1MB of addressability (in 64-k segments), vs
the unsegmented 16 MB of IBM earlier and Motorola at about the same
time. IBM when designing the IBM PC shortly afterwards decided to pick
1/3 of that MB for I/O and special extension cards' memories rather than
general base RAM -- leaving 640K, not 64K!, for the latter -- and the
difference betwen 640K and 1MB never really had any big impact.
The machines with 64-K byte limits I know of were early 16-bit minis
(such as PDP-11, despite later kludges to push that limit up) and just
about all 8-bit micros (intel, Motorola, and just about all others).
it is comparing versions that are YEARS out of date and use!
Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
deprecated?
No, there's a lot of code from that era still working happily.
Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
I'm sure Aho, Hopcroft and Ullmann would never be so ignorant or
insensitive as to detract from Backus' (and IBM Research's) epoch-making
result in making the first production compiler -- exactly 50 years ago,
quite a bit earlier than LISP, for the language first known as Formula
Translation, a name which was soon shortened to ForTran. Lisp has quite
some "first"s, but "first compiler" ain't among them.
bootstrapping to LISP compiler. What are the implications of design
decisions made in LISP compiler then affecting our compilers today? I
don't know. I repeat myself, I DO NOT KNOW.
I can't think of even a single one, although I fancy myself as quite
knowledgeable in the history of computing -- neither from Formula
Translation, nor from LISt Processor, not one design decision whose
implications are still affecting compilers being written today. Same
goes for computers of the same era, the '50s. If you move to the '60s
then some things do suggest themselves -- at least in computers: general
registers that are not part of the addressable memory, memory
addressable by the byte, 8-bit bytes with significant 16-bit and 32-bit
halfwords and fullwords too -- all parts of the IBM-360 legacy; not so
obvious in languages and compilers, maybe. Maybe the concepts of
grammar, tokenizers and parsers -- all stuff that wasn't in evidence in
the '50s, at least not in ForTran or Lisp. The ambitious concept of a
language good for all kinds of problems, commercial AND scientific, much
like IBM's "360 degrees computing" was breaking down the barriers
between scientific and commercial computers in the HW field. The very
first emergence of "bytecodes", partly from trying to emulate yet-older
computers on those of the time, to keep running old applications on new
hardware where IBM's revolutionary concept of "a family of computers"
didn't apply. Pretty thin stuff, IMHO... you have to get to the '70s to
find the emergence of a more solid legacy, I think.
Alex
Pythogoras <no****@email.org> wrote: But maybe you want to have something more fun?
How about that?
read autoexec.bat,
sort the lines
create sorted_autoexec.bak
file('sorted_autoexec.bak','w').writelines(sorted( file('autoexec.bat')))
73 chars in one line. Yeah, I cheated -- I _would_ normally put a space
after the comma, making the real total into seventyFOUR...
///
File source = new File("c:/autoexec.bat");
File destination = new File("c:/sorted_autoexec.bak");
String[] lines = readLines(source);
lines = sort(lines);
write(destination,lines);
How delightfully quaint and redundant. I do recall a time where Python
would take such a roundabout approach too -- of course, the Python code,
even at that time, was elegantly object-oriented, with the reading,
sorting and writing all neatly expressed as methods of file and list
objects, rather than these weird 'readLines' and 'sort' and 'write'
apparently-global functions taking the objects as arguments. Still, all
of those mysterious 'globals' does enhance the retrocomputing taste of
your code -- one can almost see you writing it with a quill dipped in
ink, at a carved oak desk, on your steam-powered computer. Charming!
Should you ever decide to move into the 21st century, though, don't
worry: Python will be there to help you do so.
Alex
Maurice LING <ma*********@acm.org> writes: it is comparing versions that are YEARS out of date and use!
Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
deprecated?
For new development, yes, Python 1.5.2 has been totally replaced.
There
are legacy applications running in Python 1.5.2 that aren't worth the
trouble to upgrade.
Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
bootstrapping to LISP compiler.
That's just silly. It is true that LISP was one of the pioneers of
the
compiled languages, but other compilers were not written in LISP. Almost
without exception, compilers were all written in assembly language until
Pascal came around.
I'm wrong again. I suppose what I am trying to suggest is that design
decisions made in the last may have a longer effect than what we
consciously think. At least this is the impression I get while reading
James Gosling's argument that Java should be object-oriented from day
1 (and not added onto the language, like in C++) in The Java
Programming Environment: A white paper.
The design decisions about the syntax and grammar of the languages may
have a longer effect (thought it's not clear how much of Java can be
blamed on CPL). The design decisions about the implementation tend to
vanish every time the language is implemented, and to vanish over time
as an implementation evolves. I'd be surprised if all the 1.5.2 code
has vanished from the complete python distribution. On the other hand,
the core compiler and VM may well have been completely replaced since
then.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. al*****@yahoo.com (Alex Martelli) wrote: file('sorted_autoexec.bak','w').writelines(sorted( file('autoexec.bat')))
73 chars in one line. Yeah, I cheated -- I _would_ normally put a space
after the comma, making the real total into seventyFOUR...
I understand what you're doing with the above one-liner, but I don't
think that's the best way to write it. Unless there's some over-riding
efficiency requirement, I'm always going to vote for easier to read over
fewer characters.
Chaining all those operations together into one big line makes it (IMHO)
more difficult to understand what's going on, especially since it's a
mix of method calls and global function calls. To understand the
sequence of operations, you need to read from the inside-out starting
from two different places, then put those two conceptual units together
from left-to-right.
You could refactor this in a multitude of ways, with varying levels of
compactness or verbosity, depending on how many intermediate variables
you want to use. I think I would go for something like:
inFile = file ('autoexec.bat')
outFile = file ('sorted_autoexec.bak', 'w')
outFile.writelines (sorted (inFile))
Some would say that the intermediate variables just add bulk, but I
think they provide conceptual punctuation, i.e. a place for the reader
to say, "OK, I understand that chunk, now let's see what the next chunk
does".
one can almost see you writing it with a quill dipped in
ink, at a carved oak desk, on your steam-powered computer. Charming!
Should you ever decide to move into the 21st century, though, don't
worry: Python will be there to help you do so.
I know you didn't write those lines with me in mind, but I can't help
chuckle over them. I'm tagged as a luddite by my co-workers because I
still don't have a cell phone or a palm pilot or an MP-3 player, not to
mention that I know what the program drum is used for on an 029 card
punch. I am however typing this from my wireless PowerBook :-)
Roy Smith <ro*@panix.com> wrote: al*****@yahoo.com (Alex Martelli) wrote:
file('sorted_autoexec.bak','w').writelines(sorted( file('autoexec.bat')))
73 chars in one line. Yeah, I cheated -- I _would_ normally put a space
after the comma, making the real total into seventyFOUR...
I understand what you're doing with the above one-liner, but I don't
think that's the best way to write it. Unless there's some over-riding
efficiency requirement, I'm always going to vote for easier to read over
fewer characters.
I agree, and efficiency is just the same if you _do_ give names to
intermediate objects. Terseness is worthy as long as it _helps_ reading
the code, by avoiding violations of Occam's Razor (introducing entities
without necessity).
Chaining all those operations together into one big line makes it (IMHO)
more difficult to understand what's going on, especially since it's a
mix of method calls and global function calls. To understand the
sequence of operations, you need to read from the inside-out starting
from two different places, then put those two conceptual units together
from left-to-right.
It's actually right-to-left, as that's the way the inside-out order
works out. But if you read left->right, it's "to file
sorted_autoexec.bak, write lines from sorted file autoexec.bat", which
doesn't scan all THAT badly in English, I think;-). It's right-left if
you think of things HAPPENING, of IMPERATIVE code, but it's not
necessarily that way if you think of the code as descriptive;-).
You could refactor this in a multitude of ways, with varying levels of
compactness or verbosity, depending on how many intermediate variables
Right.
you want to use. I think I would go for something like:
inFile = file ('autoexec.bat')
outFile = file ('sorted_autoexec.bak', 'w')
outFile.writelines (sorted (inFile))
Some would say that the intermediate variables just add bulk, but I
think they provide conceptual punctuation, i.e. a place for the reader
to say, "OK, I understand that chunk, now let's see what the next chunk
does".
My preference here might be to have a name for the output file variable
and not for the input one, but that's a pretty thin consideration. Your
version lets one close both files explicitly, which is good. one can almost see you writing it with a quill dipped in
ink, at a carved oak desk, on your steam-powered computer. Charming!
Should you ever decide to move into the 21st century, though, don't
worry: Python will be there to help you do so.
I know you didn't write those lines with me in mind, but I can't help
chuckle over them. I'm tagged as a luddite by my co-workers because I
still don't have a cell phone or a palm pilot or an MP-3 player, not to
mention that I know what the program drum is used for on an 029 card
punch. I am however typing this from my wireless PowerBook :-)
Heh -- you're a notch up from me, since the wireless Mac laptop I'm
using is a humble iBook 12";-).
Alex
what about : fat = lambda n: reduce(lambda x,y: x*y, range(1,n))
int = lambda f,a,b,dx: sum([f(x) for x in arange(a,b,dx)])*dx/(b-a)
Thoss (poorly) implements the factorial and integration function in just
one line. So what does my pet examples show us? Nothing! The same goes
for yours. So your poor affirmation about java compactness is the mere
statement that the only kind of code you can produce is autoexec.bat
sorting and the kinds. Every language has it's pros and cons, and having
a compact expressive syntax is NOT one place where Java outshines
python, ask any serious person.
You lost.
You Pythonistas are a bunch of losers.
And your language is dog-slow.
Eeeeeek.
And try to write Eclipse with your Mickey-Mouse-language!
<j>
Pythogoras
On Saturday 06 November 2004 09:07 pm, Roy Smith wrote: Terry Hancock <ha*****@anansispaceworks.com> wrote: And I have certainly written some extremely poorly optimized
Python programs that positively *crawled*.
My guess is the poor performance had nothing to do with the language you
wrote it in, and everything to do with the algorithms you used.
Wrong guess. ;-)
There was nothing wrong with the *algorithms* when considered apart
from the language. But considered *with* the language, they were
very bad choices.
Consider the case that you want to perform a string operation which
is not quite covered by the standard library. How do you solve that?
In C, you might very well write a function from scratch that does
what you want and nothing else. Usually this will be faster than
calling some standard library function that gets you halfway there
and then another that tries to fix the mistakes the first one made.
Not so in Python. Anything you write from scratch is going to be
interpreted, and therefore goes at a snail's pace compared to the
C code running in various built-ins and modules (consider the re
module, for example!). In fact, you might very well write a
regular expression solution that could have been done by less
impressive means in C, but would take much longer if you literally
translated the code from C to Python. The re solution will actually
do a lot more work "below the waterline" than the literally
translated version, but it won't have the loop overhead and such
to slow it down.
Generally speaking the simplest *conceptual* way to solve a problem
in Python is also the fastest.
I certainly learned this lesson. In a way, it's a good thing,
because the simplest conceptual way is probably the easiest for
a reader of your code to understand, too.
The reason why this is relevant is NOT because I'm saying "Python
is slow", but rather that it can be very slow if poorly programmed.
Thus an experienced Java programmer who tries Python may very well
find it to be "slow", since they will not necessarily make the
right choices in re-implementing a program in Python.
That's probably true for any two languages -- the one you are
most familiar with has a significant home-team advantage. ;-)
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
On Sun, 07 Nov 2004 10:33:01 +1100, Maurice LING <ma*********@acm.org> wrote:
dude that "comparision" from twistedmatrix you refrence is ANCIENT!!!
I am wondering the impact when IBM decided that the base memory to not
exceed 64kb, in the late 1960s...
I suppose more experienced people in this list can agree that certain
decisions made can be almost an edict. So, there is a re-building
process every now and then, hopefully to by-pass such edicts. Python
itself is already such an example.
it is comparing versions that are YEARS out of date and use!
Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
deprecated?
Lisp compiler is the 1st compiler to be created (according to the
Red-Dragon book, I think) and almost all others are created by
bootstrapping to LISP compiler. What are the implications of design
decisions made in LISP compiler then affecting our compilers today? I
don't know. I repeat myself, I DO NOT KNOW.
google is your friend. I would suggest prefixing "UIAM" to statements
or strong implications of "fact" that you are not really sure of ;-)
Perhaps you are not familiar with the various typical ways of softening
the assertiveness of statements in English? I notice several statements
above that start out looking like authoritative statements of fact, but
which you qualify in your way, yet it seems you were unsatisfied with
the effect, and added the last sentence.
"We are all ignorant, only on different subjects", as (UIAM ;-) Will Rogers
said. But here at c.l.py it is unlikely that all are totally ignorant on a
particular computer language subject, so if you post an unqualified statement
of "fact" (or slip an implicit statement of "fact" into a question, as in the
subject line of this thread ;-) that may not be so, someone will notice,
and wonder why you are doing that (since you haven't annnounced that you're
a political candidate ;-)
One reason might be language difficulties, but your English is too good
for that to jump immediately to mind.
Another reason might be forgetting that posting here is actually engaging other
human beings, and thinking of c.l.py posts as a kind of automated google
mechanism which has no feelings about how it is being used. But humans do care,
and provocative techniques of eliciting response do "provoke." Kids intent on
their immediate goals sometimes forget, but generally respond to a gentle reminder.
Another reason might be to spread disinformation for some private reason,
e.g. as a sleazy way to discredit competition. I don't think that applies here.
Or are you heavily invested in particular stocks? ;-)
Anyway, I think the best we can do is to help each other find out what the
real facts are, which requires not presenting suppositions as fact, while
recognizing that appearances are often deceiving to even the most experienced.
In that spirit, we wind up expressing doubts without bruising egos, and thanking
each other for contributions to improved understanding instead of defending against
feeling a fool for having believed something that was not so, or being annoyed
at careless spread of disinformation.
(of course, I haven't personally verified the "facts" stated in the
following sites ;-) http://www.emacswiki.org/cgi-bin/wiki/CommonLisp
"""
The first Lisp compiler was developed by JohnMcCarthy at Dartmouth College
between 1955 and 1959. This makes it the second oldest programming language
in common use today (only Fortran is older, developed between 1954 and 1957).
""" http://www.ibiblio.org/pub/languages/fortran/ch1-1.html
"""
This wonderful first FORTRAN compiler was designed and written from
scratch in 1954-57 by an IBM team lead by John W. Backus and staffed with
super-programmers like Sheldon F. Best, Harlan Herrick, Peter Sheridan,
Roy Nutt, Robert Nelson, Irving Ziller, Richard Goldberg, Lois Haibt
and David Sayre. By the way, Backus was also system co-designer of the
computer that run the first compiler, the IBM 704.
""" http://www.latrobe.edu.au/philosophy...s49hiteco.html http://www.moorecad.com/standardpascal/pcom.pas
Regards,
Bengt Richter
Alex Martelli wrote: Roger Binns <ro****@rogerbinns.com> wrote:
... I/O is one area where Java is *very* different than other
environments. Java emphasises the ability to select at runtime
(typically from
Python's dynamism at runtime is definitely one of its fortes.
We are talking about different things. Once you have written
some nice big Java "Enterprise" app, you'll see the difference.
I am not talking about the type system. It is more about how
Java applications are constructed. There are multiple JAR files,
many many properties files and the end user/adminstrator can
change what happens and plumb them together by changing the
properties files.
You could do *exactly* the same thing in Python, but people don't.
That doesn't make either language right or wrong, just that the
emphasis and what is considered "normal" is different.
Sure, since the semantics are different. Which is why we have the
makefile method of socket objects: for those occasions in which you
want signature-polymorphism at the expense of the overhead of
adaptation.
Yes. The point is that Java I/O is always done in that polymorphic
way, whereas Python doesn't. In both cases, you can do what the
other language does, but people usually don't. But it does mean
that if you want to measure I/O performance, you have to decide
if you want to do it with code optimised for speed, or what is "normal"
in each language.
Generators are a reasonably recent addition to Python, and I have no
idea what you mean by stating that Python emphasizes typing more than
Java does
I meant Python's typing mechanism ("duck typing"). Python programs
take advantage of that, just as Java programs take advantage of
the Java typing mechanism. Python's is more defined by the absence
of pervasive programmer defined typing, whereas the Java one requires
the specification of type information for all names, and interfaces
are used a lot.
Python frameworks. And factory-based design patterns are everywhere
in Python, of course; indeed, it's in Java that you see lots of 'new
ThisClass' constructs which build an instance of some hardwired
concrete class --
Java programs have *way* more factory stuff. Just a different emphasis.
Python's default makes it trivially easy to read most files in a
single gulp, so it's appropriate in many cases; Java's makes it hard
and slow to read ANY file, so it's never appropriate.
Your Java code was not representative of what an average programmer
would do in Java. In fact it was a spectacularly bad example of
Java programming. You can find bad examples of programming in
every language on the web.
If the language code is the same, then that claim boils down to
the Java Native Interface vs the Python C API. In the case of
Java, I can see the claim having some relevance in multi-threaded
code since Java doesn't have the GIL.
Python does, but drops it during blocking I/O operations so that the
relevance should be just about the same in both cases.
Python will be worse with the penalty being based on how much concurrent
I/O is happening and how many processers the host has. This is due to
the serialisation of the Python bytecode, and non-serialisation of the
Java bytecode. My best guess that this will be a few percentage points
at a low number of concurrent I/O and probably up to 20% with
thousands.
(At this moment at work I am in fact dealing with this very thing in some
Python code and a form of proxy server).
I did observe (at some point along the substantial chain of small
benchmarks I and some other posters exchanged) that the 4:1 ratio in
runtime in favour of Python exactly matched the 4:1 ratio in
pagefaults, again in favour of Python, btw.
Page faults aren't a valid way of measuring this. You don't incur page
faults for malloced/brk memory but you do for executable pagein, and
for mmap (usually). Using executable pagein and mmap is better when
you have multiple instances of programs since they will share
system memory. Again this all comes down to what the runtime
environment is optimised for.
However, firms that choose not to release their business critical
applications as open source are likely to require at the very least a
non-disclosure agreement before they show you those sources, making it
impractical to use those sources to meet your wishes.
That is missing my point completely. If I wanted to write a ray tracer
and I could find them all over the net and in business success stories
in all languages, I would want to examine the innards of them to see
if I could do the same thing.
We have all heard the Yahoo Stores/Paul Graham/Lisp story. I don't
think many people have seen that code. Do you think you could do something
similar in Lisp? Could you write a ray tracer in Lisp? If you could
see examples of even unrelated applications, and their code, you would
have a better idea. You would be able to judge if you could achieve
it with a team of 10 average programmers. But without being able to
see the internals of at least some examples, your guess would have a
very high margin of error.
As for your latter sentence, I've never met a programmer whose default
assumption was that they would NOT be able to write code just as good
as most anybody else's.
That only applies to languages they know or know about, and in many
cases also libraries (eg SQL, Persistence, Networking, Transactions).
Any programmer who believes they can write Yahoo Stores in Lisp just
as good as what Paul Graham and co did, when they don't know Lisp, have
no experience in that type of application, have never done credit
card processing etc is kidding themselves. They may be able to
do so eventually, but it will take much time to learn. They are
unlikely to be able to accurately estimate that time at the begining.
Using another example, do you think everyone who reads this group
could just go ahead and write Zope?
Roger
Roy Smith <ro*@panix.com> writes: mention that I know what the program drum is used for on an 029 card
punch. I am however typing this from my wireless PowerBook :-)
I hate to say this, but my kids have had 802.11g on their notebooks since
the age of 12 ( ie : nearly 2 years now).
Mainly to Alex and the rest of the adjitated community,
[snip about Melbourne club scene]
I do understand what you meant. There are restrictions in giving out
data (codes) in many cases and I seek your understanding.
Nevertheless, I do feel that you had unfairly made use of this case to
voice out your accumulated dissatisfaction with answering newbies
questions.
In later parts of this thread (after your post), it was suggested that
my errorous impressions might have been formed by books and publications
(such as "learning python", as suggested)...... I do not seek to place
blame on anyone for my misconceptions. But considering a person trying
to learn a new programming language, it is common that the person takes
in what is presented in the face, especially from books such as,
"Learning python" and "Python, the complete reference". Does this imply you now believe that the unquestioned-assumptions behind
your "why" questions were unfounded?
Now I will say that Python is comparable to Java in terms of disk I/O.
Forming a wrong impression is always a possibility. It's proceeding to
take it for granted as an obvious fact, that is quite questionable. If
you had phrased your observation in terms such as "I have gotten the
impression, without having done any measurement myself, that" etc, the
reactions would have been vastly different; your choice to express
yourself by implying an unquestionable fact existed and only required
explanations of its reasons, is a good part of the reaction's cause.
My apologies for raising your blood pressure, take care.
False: not all knowledge in the world can be usefully embodied in print
(text, images, even videos and sound recordings actualy). An important
part of human knowledge is experiential, and only a shadow of that
important part can be captured in libraries, including multimedia ones.
Many universities, as a part of their mission, conduct research and
therefore presumably generate new knowledge. This entirely self-evident
and obvious fact, even by itself, makes your assertion doubly absurd:
"all knowledge is out there" readily implies there is no knowledge to be
added, and "all universities are complete waste of money" similarly
implies no university is generating new knowledge, or what they do
generate is utterly worthless.
Perhaps I should rephase it as known knowledge so far.
Your assertion that "by my argument" (which had never touched anywhere
upon the research role of universities) research is nonexistent, futile,
or entirely worthless, is at the same time absurd and deeply insulting.
If and when I want to criticize university research, I will do so
myself, and I do not AT ALL appreciate this attempt to put words in my
mouth, even though any reader with a 3-digits IQ can see it as the
insulting absurdity it is.
If we stick to the _teaching_ role of universities, the reasons my
arguments imply nothing like you're stating are both more interesting
and subtler. On one hand, there is the experiential side of knowledge.
By conducting experiments in a laboratory under proper guidance, even
though those experiments are not novel, students acquire knowledge
experientially -- a very different learning mechanism from reading books
and articles, or listening to lectures. Of course, good high schools
have laboratories etc, too, but in University, at least in scientific
and technical disciplines, the experiential learning process _should_
blossom to a far higher degree (if it doesn't -- if a university skimps
on labs and overwhelms students with just books and lectures -- then
that may well be a valid ground for criticism, _of that particular
university's choice in didactics_, of course, not "of all
universities"). In other disciplines, experiential learning may be less
obvious, but if the university is any good, it will be there.
And then, there is the issue of selection and structuring. I have
posted about that recently, in a thread asking whether there was a book
about large-scale software development with Python, and you can easily
look it up on google groups. To summarize: I have lots of materials on
the subject. I find I'm easily able to organize these materials into
courses and workshops that are specifically aimed at an identified group
of students, with certain backgrounds and interests. Organizing the
same material into a _book_ is a far harder task, one which I can't take
the time off to undertake at present... which ties back to a _part_ of
the reason why not all knowledge is in books or other printed or
otherwise 'frozen' (recorded, filmed, ...) forms. A vast majority of
the materials I collected IS out there -- over the years, I've posted a
goodly fraction of it. But it's generally unselected and unstructured,
making the learning task far more daunting than proper structuring and
selection can potentially make it.
A good university course has selection and structuring, and is
interactive in a way a book can never be, thus potentially making the
s&s more appropriate and effective for the specific individual students
who are taking that course wrt books (or some other well-organized
subset of info from the net). Of course, if you throw 500 students at a
poor professor, no matter how good he is, his ability to teach a really
good course will be impaired -- smaller classes are MUCH better that way
(another valid criticism of the way many universities are structured).
Usenet does have the interactivity advantage, but normally not the
structuring one, with rare exceptions, and only to some extent the
selection one. Thus, it can complement rather than substitute for
books, courses, and information search on the raw net. It has little
experiential value, though not zero -- _some_ of the interaction on it
does work to stimulate and vaguely guide/aim some experiences.
As mentioned, the discussion is heading else where and my misconceptions
cleared before your replies. If I've indeed forgotten, my sincere
apologies and hereby thank you for your time and efforts.
Thanks, this is appreciated. I take it then that you do not any longer
opine that on disk-I/O intensive programs Python is self-evidently
slower than Java?
You still have the right to remain solemn.
Heh, nice. Well, it's a right I surely exercise far more often than the
more traditional one of remaining silent;-).
Alex
All in all, through all these discussions, I can safely assert that
Python and Java are comparable in disk I/O. And a part of the original
misconceptions might have been formed possibly out-dated printed
materials which are still references for new python programmers. It is
then my concern that such misconceptions may be perpentuated.
I admit and apologise for my poor phrasing of questions which sparked
this chain of events. We had all lost some cool along the way and some
harsh words flew. Alex, I do hope you will accept my apologies. I
suppose I am pissed off when the flare is targetted towards myself and
not the situation. Anyway, my apologies...
maurice
In article <87************@pop-server.bigpond.net.au>,
Israel Raj T <ra****@bigpond.net.au> wrote: Roy Smith <ro*@panix.com> writes:
mention that I know what the program drum is used for on an 029 card
punch. I am however typing this from my wireless PowerBook :-)
I hate to say this, but my kids have had 802.11g on their notebooks since
the age of 12 ( ie : nearly 2 years now).
That's OK. I once went for a job interview that really made me feel
antiquated. The kid who was interviewing me looked at my resume, saw
that I had started using Unix in 1977, and said, "Wow, you've been doing
Unix longer than I've been alive!".
The key to avoiding becoming a dinosaur is to keep learning. If you
don't learn something major (a new language, operating system, etc)
every year, it won't be too long before you start to sink into the tar
pits.
Roger Binns wrote: We are talking about different things. Once you have written
some nice big Java "Enterprise" app, you'll see the difference.
I am not talking about the type system. It is more about how
Java applications are constructed. There are multiple JAR files,
many many properties files and the end user/adminstrator can
change what happens and plumb them together by changing the
properties files.
You could do *exactly* the same thing in Python, but people don't.
That doesn't make either language right or wrong, just that the
emphasis and what is considered "normal" is different.
FWIW, this is something they are doing in Zope 3. ZCML (an XML markup)
is used to define the relationship of various components, in a role that
is probably similar to Java properties, jars, etc.
--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org fi**************@gmail.com (Lonnie Princehouse) wrote in message news:<4b**************************@posting.google. com>... Yes, wxPython is typically quicker than swing. It's not fair to use
this in a generic Python-vs-Java speed shootout, though, since
wxPython is just a wrapper around wxWidgets' C++ code; you're really
comparing C++ vs. Java here.
But the ease of development of extensions in other languages and the
willingness of the community to do so IS one of the key differences
between Java and Python, especially with respect to performance.
Where Java tends to be platform independent, Python tends to be
platform agnostic. In real code, people use SciPy/NumPy, wxpython,
etc because those things work for them and get the job done.
Moreover, since the GUI developer in Python is writing only in Python
(never touching C++ or needing to know about it at all), you're
basically saying that this example is unfair because Python has a
faster implementation.
Mike Meyer <mw*@mired.org> wrote in message news:<x7************@guru.mired.org>... fi**************@gmail.com (Lonnie Princehouse) writes:
Yes, wxPython is typically quicker than swing. It's not fair to use
this in a generic Python-vs-Java speed shootout, though, since
wxPython is just a wrapper around wxWidgets' C++ code; you're really
comparing C++ vs. Java here.
Is it unfair to compare Python dictionaries to Java HashTables because
Python is using hand-tuned C where Java is using Java? I'd say that's
a perfectly fair comparison. If that's fair, what's unfair about
comparing graphics toolkits that happen to be written in C rather than
Python (is there a graphics toolkit written in Python?).
Perhaps instead of "unfair", I should have written "not meaningful".
Because wxPython is C++ code, you can't really infer that Python is
faster than Java just because wxPython is faster than Swing. The
best meaningful assertion that can be made is that Python can be
faster than Java for GUI operations.
That's *how* interpreted languages manage to compete with compiled
languages - they perform the common operations in hand-tuned compiled
code. That people tend to write Java libraries in Java rather than C
just means they're going to get slower libraries.
Sure, but it's possible to do the same thing with Java via the JNI.
Maybe what should be compared is the relative ease of writing native
extensions (considerably easier in Python IMHO)
Java is interpreted just like Python is...
Java bytecodes are interpreted, but javac has the opportunity to do
some optimizations when compiling source into bytecodes that
fundamentally can't be done for Python because it's interpreted.
There's no equivalent of "exec" in Java. Psyco makes a valiant
attempt to do this sort of optimization (and does an excellent job!),
but it's not hard to write perfectly legal Python code that makes
Psyco explode.
[someone correct me if I'm wrong; I'm not an expert Java programmer
:P]
Maurice LING <ma*********@acm.org> wrote in message 3. I am not interested in the amount of time needed to develop it. But
only interested execution speed.
-If you really don't care about it, spend time developing it in C or
asambler or machine code, is it going to be faster, maybe?
-If you really don't care about it, write it in both, Java and Python
and decide for yourself about the speed.
-Do you honestly believe someone here can make those valid statements
you are waiting for to validate your unspoken reasons of this dilemma?
Here is how it goes:
No matter what others are going to try and persuade you about, you
will only make it right and probably fast enough when you will have
the experience to do it. Do you know Java better? go ahead and write
it in Java. Are you willing to learn Python and see for yourself if
the decision was right, I suggest you do that, I believe it should be
worthy. Are you afraid you are going to make the wrong decision?. You
must be mature and assume your decisions.
So, if you do have time my suggestion is:
Go ahead and try a few things in python (it seams you have some
reasons to do that already) and see if they are going to perform the
way you would like and if yes, make a plan and do it.
Success!!!
If it is not what you expected, do it in Java.
Success!!!
If you want to see reactions like the one from that Pythongoras, go
ahead and wait some more.
>>>>> "Tim" == Tim Roberts <ti**@probo.com> writes:
Tim> It is fabulous that you are able to enumerate your list of
Tim> requirements so completely. I'm quite serious; many people
Tim> embark on even complicated projects without a clear
Tim> understanding of the tradeoffs they will encounter.
Tim> However, given that set of needs, why would you mess with an
Tim> "exotic" language at all? Why wouldn't you just write
Tim> straight to the metal in C++ or C? -- - Tim Roberts,
Tim> ti**@probo.com Providenza & Boekelheide, Inc.
It is quite possible that the list of features, requirements, etc.,
are all known only after the Python prototype show that it worked.
Very few people (except those who are really very proficient in C++)
would like to write prototypes in such static languages, but once the
prototype show what is needed, and the prototype becomes part of the
production system, one have to step by step turn it back to C++.
Regards,
Isaac.
In article <87************@pop-server.bigpond.net.au>, Israel Raj T wrote: On Windows XP, Windows NT and Linux (Gentoo ), I have consistently
found python apps using wxpython to be far faster to load
and to be far more responsive than Java apps.
I've casually compared the jython/Swing tree widget with the pygtk tree
widget, both with the same large data set, and the Swing tree widget
responds quite a bit faster than the gtk tree widget (there have been a lot
of complaints about the gtk treeviews slowness). Obviously the Swing tree
widget is much better optimized.
wxpython runs on top of gtk on Linux, but I don't know if they use the gtk
treeview as a "peer" or work around it and implement their own tree widget.
Dave Cook fi**************@gmail.com (Lonnie Princehouse) writes: Yes, wxPython is typically quicker than swing. It's not fair to use
this in a generic Python-vs-Java speed shootout, though, since
wxPython is just a wrapper around wxWidgets' C++ code; you're really
comparing C++ vs. Java here.
And Python's list.sort is just a wrapper around C code. So I guess
that it's not fair to use that, or any other Python built-in function,
in a Python-vs-X speed shootout. This would mean you can't use Python
classes in such a shootout either, as type.__new__ and object.__new__
are both also merely wrappers around C code ... not to mention Python
dictionaries: wrappers around C code which are used in just about
every name lookup in Python.
So, the conclusion is that it's not fair to use Python in a
Python-vs-X speed shootout.
I rather like that conclusion :-)
Hehe. I'm really not trying to start a flame war, honest :P
I don't even like Java.
My point was just that it's sort of misleading to say "wxPython is
faster than Swing, therefore Python tends to be faster than Java for
all things".
Jacek Generowicz <ja**************@cern.ch> wrote in message news:<ty*************@pcepsft001.cern.ch>... fi**************@gmail.com (Lonnie Princehouse) writes:
Yes, wxPython is typically quicker than swing. It's not fair to use
this in a generic Python-vs-Java speed shootout, though, since
wxPython is just a wrapper around wxWidgets' C++ code; you're really
comparing C++ vs. Java here.
And Python's list.sort is just a wrapper around C code. So I guess
that it's not fair to use that, or any other Python built-in function,
in a Python-vs-X speed shootout. This would mean you can't use Python
classes in such a shootout either, as type.__new__ and object.__new__
are both also merely wrappers around C code ... not to mention Python
dictionaries: wrappers around C code which are used in just about
every name lookup in Python.
So, the conclusion is that it's not fair to use Python in a
Python-vs-X speed shootout.
I rather like that conclusion :-)
Dave Cook wrote: wxpython runs on top of gtk on Linux, but I don't know if they use the gtk
treeview as a "peer" or work around it and implement their own tree widget.
Given that the express goal of wxWidgets is to use native widgets
wherever possible (a goal which results in some cross-platform
inconsistencies, but is largely responsible for its "better" (i.e.
native) look and usually-better speed), I'd think it very likely that it
does use the GTK treeview.
Jeff Shannon
Technician/Programmer
Credit International
Lonnie Princehouse <fi**************@gmail.com> wrote: Java is interpreted just like Python is...
Java bytecodes are interpreted, but javac has the opportunity to do
some optimizations when compiling source into bytecodes that
fundamentally can't be done for Python because it's interpreted.
This assertion is, simply, wrong. The Python compiler has the
opportunity to perform plenty of optimizations, too. If it only
performs a very few of them is most definitely _NOT_ "because it's
interpreted": Python is interpreted just as much as Java is.
There's no equivalent of "exec" in Java.
....so on any function containing an 'exec', even the few key
optimizations the Python compiler does are turned off. So what?
Doesn't mean they have to be turned off in normal, sane functions which
simply to NOT use 'exec'.
The fact that optimizations are turned off is one of many excellent
reasons to avoid USING Python's exec, btw.
Psyco makes a valiant
attempt to do this sort of optimization (and does an excellent job!),
but it's not hard to write perfectly legal Python code that makes
Psyco explode.
I wouldn't be surprised if psyco had bugs: so did the first several
generations of Java JITs, even with a couple more orders of magnitude of
people slaving away on them than have worked on psyco. That has nothing
to do with "being interpreted" somehow differing between Java and
Python.
Alex
Jeremy Bowers wrote: On Sat, 06 Nov 2004 20:53:26 +0000, Israel Raj T wrote:
As for non desktop apps, the entire portage system of Gentoo is written in
Python. 'emerge sync' causes a python app to synchronise a local
application database with database at a non-local mirror. It is i/o
intensive and appears to work very well and very fast.
"emerge sync" mostly runs an rsync command (at least on standard
installs). The python contribution to that process is minimal.
The primary slowdown with "emerge" appears to be the way the database is
stored as many thousands of little files in /usr/portage. Again, not
really python; you want to accelerate emerge, speed up your hard drive.
(They have more cached metadata now at least in the cutting-edge release,
but as that is the one I use I don't know if that is now considered
stable. It has really sped things up. A couple more iterations and Python
might actually become the bottleneck.)
Jeremy:
I just noticed your date is set a month ahead.
regards
Steve
-- http://www.holdenweb.com http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Catalin |
last post by:
How can I make executables with python?
I found some utilities that claim they can do something like that like
Installer and py2exe but they actualy pack the code in a huge arhive!
This solves the...
|
by: Ville Vainio |
last post by:
I don't know if you have seen this before, but here goes:
http://text.userlinux.com/white_paper.html
There is a jab at Python, though, mentioning that Ruby is more
"refined".
--
Ville...
|
by: Stuart Turner |
last post by:
Hi Everyone,
I'm working hard trying to get Python 'accepted' in the organisation I work
for. I'm making some good in-roads. One chap sent me the text below on
his views of Python. I wondered...
|
by: 63q2o4i02 |
last post by:
Hi, I've been thinking about Python vs. Lisp. I've been learning
Python the past few months and like it very much. A few years ago I
had an AI class where we had to use Lisp, and I absolutely...
|
by: Anthony Irwin |
last post by:
Hi All,
I am currently trying to decide between using python or java and have
a few quick questions about python that you may be able to help with.
#1 Does python have something like javas...
|
by: Jens |
last post by:
I'm starting a project in data mining, and I'm considering Python and
Java as possible platforms.
I'm conserned by performance. Most benchmarks report that Java is
about 10-15 times faster than...
|
by: Raxit |
last post by:
Hi,
i was reading/learning some hello world program in python.
I think its very simillar to Java/C++/C#. What's different (except
syntax) ?
what can i do easily with python which is not easy...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| |
