Re: is None or == None ?
On 2009-11-10, at 07:46, Grant Edwards wrote: > MacOS applications made the same mistake on the 68K. They > reserved the high-end bits At the time the 32-bit Macs were about to come on the market, I saw an internal confidential document that estimated that at least over 80% of the applications that the investigators had looked at (including many from that company named after a fruit, whose head office is on Infinite Loop) were not 32-bit clean. This in spite of the original edition of Inside Mac (the one that looked like a telephone book) that specifically said always to write 32-bit clean apps, as 32-bit machines were expected in the near future. It's not quite as bad as the program I once looked at that was released in 1999 and was not Y2K compliant, but it's pretty close. --v -- http://mail.python.org/mailman/listinfo/python-list
Re: is None or == None ?
On 2009-11-10, at 19:07, Steven D'Aprano wrote: > On Tue, 10 Nov 2009 16:05:01 -0800, Vincent Manis wrote: > That is incorrect. The original Inside Mac Volume 1 (published in 1985) > didn't look anything like a phone book. The original Macintosh's CPU (the > Motorola 68000) already used 32-bit addressing, but the high eight pins > were ignored since the CPU physically lacked the pins corresponding to > those bits. > > In fact, in Inside Mac Vol II, Apple explicitly gives the format of > pointers: the low-order three bytes are the address, the high-order byte > is used for flags: bit 7 was the lock bit, bit 6 the purge bit and bit 5 > the resource bit. The other five bits were unused. You are correct. On thinking about it further, my source was some kind of internal developer seminar I attended round about 1985 or so, where an Apple person said `don't use the high order bits, we might someday produce machines that use all 32 address bits', and then winked at us. You are also correct (of course) about the original `Inside Mac', my copy was indeed 2 volumes in looseleaf binders; the phonebook came later. > By all means criticize Apple for failing to foresee 32-bit apps, but > criticizing them for hypocrisy (in this matter) is unfair. By the time > they recognized the need for 32-bit clean applications, they were stuck > with a lot of legacy code that were not clean. Including code burned into > ROMs. That's my point. I first heard about Moore's Law in 1974 from a talk given by Alan Kay. At about the same time, Gordon Bell had concluded, independently, that one needs extra address bit every 18 months (he was looking at core memory, so the cost factors were somewhat different). All of this should have suggested that relying on any `reserved' bits is always a bad idea. I am most definitely not faulting Apple for hypocrisy, just saying that programmers sometimes assume that just because something works on one machine, it will work forevermore. And that's unwise. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: is None or == None ?
On 2009-11-10, at 22:07, Vincent Manis wrote: > On 2009-11-10, at 19:07, Steven D'Aprano wrote: >> In fact, in Inside Mac Vol II, Apple explicitly gives the format of >> pointers: the low-order three bytes are the address, the high-order byte >> is used for flags: bit 7 was the lock bit, bit 6 the purge bit and bit 5 >> the resource bit. The other five bits were unused. I inadvertently must have deleted a paragraph in the response I just posted. Please add: The pointer format would have caused me to write macros or the like (that was still in the days when Apple liked Pascal) to hide the bit representation of pointers. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-11, at 14:31, Alain Ketterlin wrote: > Terry Reedy writes: > >> I can imagine a day when code compiled from Python is routinely >> time-competitive with hand-written C. > > Have a look at > http://code.google.com/p/unladen-swallow/downloads/detail?name=Unladen_Swallow_PyCon.pdf&can=2&q= > > Slide 6 is impressive. The bottom of slide/page 22 explains why python > is so slow: in most cases "the program is less dynamic than the > language". I'm having some trouble understanding this thread. My comments aren't directed at Terry's or Alain's comments, but at the thread overall. 1. The statement `Python is slow' doesn't make any sense to me. Python is a programming language; it is implementations that have speed or lack thereof. 2. A skilled programmer could build an implementation that compiled Python code into Common Lisp or Scheme code, and then used a high-performance Common Lisp compiler such as SBCL, or a high-performance Scheme compiler such as Chez Scheme, to produce quite fast code; Python's object model is such that this can be accomplished (and not using CLOS); a Smalltalk-80-style method cache can be used to get good method dispatch. This whole approach would be a bad idea, because the compile times would be dreadful, but I use this example as an existence proof that Python implementations can generate reasonably efficient executable programs. In the Lisp world, optional declarations and flow analysis are used to tell the compiler the types of various variables. Python 3's annotations could be used for this purpose as well. This doesn't impact the learner (or even the casual programmer) for who efficiency is not that important. Unladen Swallow's JIT approach is, IMHO, better than this; my point here is that we don't know what the speed limits of Python implementations might be, and therefore, again, we don't know the limits of performance scalability. 3. It is certainly true that CPython doesn't scale up to environments where there are a significant number of processors with shared memory. It is also true that similar languages for highly parallel architectures have been produced (Connection Machine Lisp comes to mind). Whether the current work being done on the GIL will resolve this I don't know. Still, even if CPython had to be thrown away completely (something I don't believe is necessary), a high-performance multiprocessor/shared memory implementation could be built, if resources were available. 4. As to the programming language Python, I've never seen any evidence one way or the other that Python is more or less scalable to large problems than Java. My former employers build huge programs in C++, and there's lots of evidence (most of which I'm NDA'd from repeating) that it's possible to build huge programs in C++, but that they will be horrible :) -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: Python & Go
On 2009-11-11, at 21:27, Mensanator wrote: >> Go doesn't support inheritance, so C++ is pretty much out. C >> is a lot closer, but still not all that close. OK, if that's the case (I haven't read the Go documents), then Go is nothing like Python, no matter how many or few semicolons there are in Go programs, or whether one imports external code modules with `import', `require', or `iwant'. Programming languages are similar if their *semantics* are similar, not if their *syntaxes* are similar. A device that apparently has brake and accelerator pedals is similar to a car if the functions of these two pedals match those of a car, and is different from a car if the `brake' causes bread to be inserted into a toaster and the `accelerator' drops a 16ton weight on the driver. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
When I was approximately 5, everybody knew that higher level languages were too slow for high-speed numeric computation (I actually didn't know that then, I was too busy watching Bill and Ben the Flowerpot Men), and therefore assembly languages were mandatory. Then IBM developed Fortran, and higher-level languages were not too slow for numeric computation. When I was in university, IBM released a perfectly horrible implementation of PL/I, which dynamically allocated and freed stack frames for each procedure entry and exit (`Do Not Use Procedures: They Are Inefficient': section heading from the IBM PL/I (G) Programmer's Guide, circa 1968). Everyone knew PL/I was an abomination of a language, which could not be implemented efficiently. Then MIT/Bell Labs/GE/Honeywell wrote Multics in a PL/I subset, and (eventually) it ran quite efficiently. When Bell Labs pulled out of the Multics effort, some of their researchers wrote the first version of Unix in assembly language, but a few years later rewrote the kernel in C. Their paper reporting this included a sentence that said in effect, `yes, the C version is bigger and slower than the assembler version, but it has more functionality, so C isn't so bad'. Everybody knew that high-level languages were too inefficient to write an operating system in (in spite of the fact that Los Alamos had already written an OS in a Fortran dialect). Nobody knew that at about that time, IBM had started writing new OS modules in a company-confidential PL/I subset. When I was in grad school, everybody knew that an absolute defence to a student project running slowly was `I wrote it in Lisp'; we only had a Lisp interpreter running on our system. We didn't have MacLisp, which had been demonstrated to compile carefully-written numerical programs into code that ran more efficiently than comparable programs compiled by DEC's PDP-10 Fortran compiler in optimizing mode. In an earlier post, I mentioned SBCL and Chez Scheme, highly optimizing compiler-based implementations of Common Lisp and Scheme, respectively. I don't have numbers for SBCL, but I know that (again with carefully-written Scheme code) Chez Scheme can produce code that runs in the same order of magnitude as optimized C code. These are both very old systems that, at least in the case of Chez Scheme, use techniques that have been reported in the academic literature. My point in the earlier post about translating Python into Common Lisp or Scheme was essentially saying `look, there's more than 30 years experience building high-performance implementations of Lisp languages, and Python isn't really that different from Lisp, so we ought to be able to do it too'. All of which leads me to summarize the current state of things. 1. Current Python implementations may or may not be performance-scalable in ways we need. 2. Reorganized interpreters may give us a substantial improvement in performance. More significant improvements would require a JIT compiler, and there are good projects such as Unladen Swallow that may well deliver a substantial improvement. 3. We might also get improvements from good use of Python 3 annotations, or other pragma style constructs that might be added to the language after the moratorium, which would give a compiler additional information about the programmer's intent. (For example, Scheme has a set of functions that essentially allow a programmer to say, `I am doing integer arithmetic with values that are limited in range to what can be stored in a machine word'.) These annotations wouldn't destroy the dynamic nature of Python, because they are purely optional. This type of language feature would allow a programmer to exploit the high-performance compilation technologies that are common in the Lisp world. Even though points (2) and (3) between them offer a great deal of hope for future Python implementations, there is much that can be done with our current implementations. Just ask the programmer who writes a loop that laboriously does what could be done much more quickly with a list comprehension or with map. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: Does turtle graphics have the wrong associations?
On 2009-11-12, at 11:36, AK Eric wrote: > On Nov 12, 11:31 am, Terry Reedy wrote: >> Alf P. Steinbach wrote: >>> One reaction to >> http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle >>> graphics may be off-putting to some readers because it is associated >>> with children's learning. Take a look at Abelson and diSessa's _Turtle Geometry: The Computer as a Medium for Exploring Mathematics_ (MIT Press, 1986). This is most definitely not a kids' book. Chapter titles include `Topology of Turtle Paths', `Piecewise Flat Surfaces', and `Curved Space and General Relativity'. As well as being a very nice 2D graphics API, turtles let you explore very deep math. Of course, they also let you explore cybernetics and feedback; see some of the old MIT AI Lab reports on LOGO for that (you can find them at MIT's CSAIL lab website). For a lot of that, you actually need a robot turtle, like perhaps a LEGO Mindstorms robot. Seymour Papert (who did a lot of the MIT LOGO work) was, before his terrible motor accident, in research chair endowed by...LEGO. Hmmm... :) Of course, some people don't like Python itself because they are afraid of snakes. > I used Turtle back on the Apple in the early 80's... so I personally > have very positive feelings towards it ;) To each their own eh? I did my master's thesis on LOGO about 10 years before that, and I have VERY warm and fuzzy feelings about turtles :) -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: Does turtle graphics have the wrong associations?
On 2009-11-12, at 19:13, Peter Nilsson wrote: > My recollection is that many children struggled with Turtle > graphics because they had very little concept of trigonometry. > [Why would they? Many wouldn't learn for another 2-10 years.] > Adults tend to have even less concept since they almost never > use trig (or much else from school ;-) in the real world. > This paragraph is based upon a complete misunderstanding of turtle geometry. You do NOT use trigonometry to teach it, because the goal isn't to replicate cartesian geometry. The whole point about turtle geometry is that the student viscerally imagines him/herself BEING the turtle, and moving around the room according to the succession of FORWARD and TURNRIGHT commands. This is easier to visualize when one has an actual robot that draws pictures on butcher paper, as the second iteration of the MIT/BBN turtle work did (and they worked in middle schools, Grades 4-8, so there was no issue of trigonometry). > They can see the patterns and understand there's a logic to > it, but they struggle replicating it. Get an angle wrong > and you end up with a mess where it's not clear whether it's > your algorithm or the maths that's at fault. Kindly explain to me the difference between `algorithm' and `maths' here. I believe you just said that if there's a bug in the design, the program won't work. Hmmm. This reminds me of a well-known anecdote about the original LOGO study done at Muzzey High in Lexington, MA, in 1968. A group of NSF funding people was doing a tour of the school, and they came across a Grade 5 student who was doing a family tree program. The NSF people were impressed by the complexity of the program. One of them said in a patronizing tone, `I guess this stuff really helps you learn math'. She got quite angry, and responded, `This stuff has NOTHING to do with math!' > The visual aspect might pique interest, but may put just as > many people off. In any case, it won't relieve the difficulty > of having to teach what is fundamentally an abstraction that > doesn't have very good parallels with how people approach > problems in the real world. Humans simply don't think like > mathematicians^W computers. :-) Having taught grade 8 math, I can tell you that cartesian geometry is much LESS intuitive to people that are learning it than the relative polar coordinates of turtle geometry are. (`Oh, you want to get to the mall food court? Turn left, and walk past about 10 stores. The food court is right after the Gap.') > I've met a lot of mathematics and comp sci teachers who > honestly believe that you can't teach these subjects without > a mathematical perspective. That stands in contrast to the > number of people I see using spreadsheets with a very high > proficiency who would never dream of saying they were good > at mathematics or programming. It is true that you can't teach computer science to children without having a strong understanding of the mathematical foundations. It is also true that when you teach it to children that you very carefully hide the mathematical formalism. I might point out that the people who had most to do with the invention of turtle geometry were Wally Feurzeig (who was my boss when I worked at BBN in the 1970s) and Seymour Papert. Papert had spent a lot of time working with Jean Piaget in Switzerland. If you read the original LOGO memos, you will see his clear explanations on how this material ought to be taught to people with no math background, including children who are too young to do symbolic thinking (that kicks in in the early teens). That's why the visceral `I am a turtle' approach works well with middle-school kids. -- v > > -- > Peter > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-12, at 23:19, Steven D'Aprano wrote: > On Thu, 12 Nov 2009 22:20:11 -0800, Vincent Manis wrote: > > Vincent, could you please fix your mail client, or news client, so > that it follows the standard for mail and news (that is, it has a > hard-break after 68 or 72 characters? My apologies. Will do. > Having to scroll horizontally to read your posts is a real pain. At least you're reading them. :) -- v-- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 12:46, Brian J Mingus wrote: > You're joking, right? Try purchasing a computer manufactured in this > millennium. Monitors are much wider than 72 characters nowadays, old timer. I have already agreed to make my postings VT100-friendly. Oh, wait, the VT-100, or at least some models of it, had a mode where you could have a line width of 132 characters. And what does this have to do with Python? About as much as an exploding penguin on your television. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 15:32, Paul Rubin wrote: > This is Usenet so > please stick with Usenet practices. Er, this is NOT Usenet. 1. I haven't, to the best of my recollection, made a Usenet post in this millennium. 2. I haven't fired up a copy of rn or any other news reader in at least 2 decades. 3. I'm on the python-list mailing list, reading this with Apple's Mail application, which actually doesn't have convenient ways of enforcing `Usenet practices' regarding message format. 4. If we're going to adhere to tried-and-true message format rules, I want my IBM 2260 circa 1970, with its upper-case-only display and weird little end-of-line symbols. Stephen asked me to wrap my posts. I'm happy to do it. Can we please finish this thread off and dispose of it? -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: > ... Python *the language* is specified in a way that > makes executing Python programs quickly very very difficult. That is untrue. I have mentioned before that optional declarations integrate well with dynamic languages. Apart from CL and Scheme, which I have mentioned several times, you might check out Strongtalk (typed Smalltalk), and Dylan, which was designed for high-performance compilation, though to my knowledge no Dylan compilers ever really achieved it. > I'm tempted to > say it's impossible, but great strides have been made recently with JITs, so > we'll see. > If you want to know why Python *the language* is slow, look at the Lisp code > CLPython generates and at the code implementing the run time. Simple > operations end up being very expensive. Does the object on the left side of a > comparison implement compare? No, then does the right side implement it? No, > then try something else I've never looked at CLPython. Did it use a method cache (see Peter Deutsch's paper on Smalltalk performance in the unfortunately out-of-print `Smalltalk-80: Bits of History, Words of Advice'? That technique is 30 years old now. I have more to say, but I'll do that in responding to Bob's next post. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 18:02, Robert Brown wrote: > Common Lisp and Scheme were designed by people who wanted to write complicated > systems on machines with a tiny fraction of the horsepower of current > workstations. They were carefully designed to be compiled efficiently, which > is not the case with Python. There really is a difference here. Python the > language has features that make fast implementations extremely difficult. Not true. Common Lisp was designed primarily by throwing together all of the features in every Lisp implementation the design committee was interested in. Although the committee members were familiar with high-performance compilation, the primary impetus was to achieve a standardized language that would be acceptable to the Lisp community. At the time that Common Lisp was started, there was still some sentiment that Lisp machines were the way to go for performance. As for Scheme, it was designed primarily to satisfy an aesthetic of minimalism. Even though Guy Steele's thesis project, Rabbit, was a Scheme compiler, the point here was that relatively simple compilation techniques could produce moderately reasonable object programs. Chez Scheme was indeed first run on machines that we would nowadays consider tiny, but so too was C++. Oh, wait, so was Python! I would agree that features such as exec and eval hurt the speed of Python programs, but the same things do the same thing in CL and in Scheme. There is a mystique about method dispatch, but again, the Smalltalk literature has dealt with this issue in the past. Using Python 3 annotations, one can imagine a Python compiler that does the appropriate thing (shown in the comments) with the following code. import my_module# static linking __private_functions__ = ['my_fn'] # my_fn doesn't appear in the module dictionary. def my_fn(x: python.int32): # Keeps x in a register def inner(z): # Lambda-lifts the function, no nonlocal vars return z // 2 # does not construct a closure y = x + 17# Via flow analysis, concludes that y can be registerized; return inner(2 * y) # Uses inline integer arithmetic instructions. def blarf(a: python.int32): return my_fn(a // 2) # Because my_fn isn't exported, it can be inlined. A new pragma statement (which I am EXPLICITLY not proposing; I respect and support the moratorium) might be useful in telling the implementation that you don't mind integer overflow. Similarly, new library classes might be created to hold arrays of int32s or doubles. Obviously, no Python system does any of these things today. But there really is nothing stopping a Python system from doing any of these things, and the technology is well-understood in implementations of other languages. I am not claiming that this is _better_ than JIT. I like JIT and other runtime things such as method caches better than these because you don't have to know very much about the implementation in order to take advantage of them. But there may be some benefit in allowing programmers concerned with speed to relax some of Python's dynamism without ruining it for the people who need a truly dynamic language. If I want to think about scalability seriously, I'm more concerned about problems that Python shares with almost every modern language: if you have lots of processors accessing a large shared memory, there is a real GC efficiency problem as the number of processors goes up. On the other hand, if you have a lot of processors with some degree of private memory sharing a common bus (think the Cell processor), how do we build an efficient implementation of ANY language for that kind of environment? Somehow, the issues of Python seem very orthogonal to performance scalability. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 19:53, Paul Rubin wrote: > "Robert P. J. Day" writes: >> http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1 >> thoughts? > > I'd bet it's not just about multicore scaling and general efficiency, > but also the suitability of the language itself for large, complex > projects. It's just not possible to be everything for everybody. > Python is beginner-friendly, has a very fast learning curve for > experienced programmers in other languages, and is highly productive > for throwing small and medium sized scripts together, that are > debugged through iterated testing. One might say it's optimized for > those purposes. I use it all the time because a lot of my programming > fits the pattern. The car analogy is the no-frills electric commuter > car, just hop in and aim it where you want to go; if you crash it, > brush yourself off and restart. But there are times (large production > applications) when you really want the Airbus A380 with the 100's of > automatic monitoring systems and checkout procedures to follow before > you take off, even if the skill level needed to use it is much higher > than the commuter car. OK. The quoted link deals with Unladen Swallow, which is an attempt to deal with the very real performance limitations of current Python systems. The remarks above deal with productivity scalability, which is a totally different matter. So... People can and do write large programs in Python, not just `throwing...medium sized scripts together'. Unlike, say, Javascript, it has the necessary machinery to build very large programs that are highly maintainable. One can reasonably compare it with Java, C#, and Smalltalk; the facilities are comparable, and all of those (as well as Python) are used for building enterprise systems. I believe that the A380's control software is largely written in Ada, which is a perfectly fine programming language that I would prefer not to write code in. For approximately 10 years, US DOD pretty much required the use of Ada in military (and aerospace) software (though a a couple of years ago I discovered that there is still one remaining source of Jovial compilers that still sells to DOD). According to a presentation by Lt. Colonel J. A. Hamilton, `Programming Language Policy in the DOD: After The Ada Mandate', given in 1999, `We are unlikely to see a return of a programming language mandate' (www.drew-hamilton.com/stc99/stcAda_99.pdf). As I understand it, the removal of the Ada mandate came from the realization (20 years after many computer scientists *told* DOD this) that software engineering processes contribute more to reliability than do programming language structures (c.f. Fred Brooks, `No Silver Bullet'). So: to sum up, there are lots of large systems where Python might be totally appropriate, especially if complemented with processes that feature careful specification and strong automated testing. There are some large systems where Python would definitely NOT be the language of choice, or even usable at all, because different engineering processes were in place. >From a productivity viewpoint, there is no data to say that Python is more, >less, or equally scalable than in that it produces correctly-tested, highly-maintainable programs at a lower, higher, or equal cost. I would appreciate it if people who wanted to comment on Python's scalability or lack thereof would give another programming language that they would compare it with. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 22:51, Alf P. Steinbach wrote: > It's sort of hilarious. It really is, see below. > So no, it's not a language that is slow, it's of course only concrete > implementations that may have slowness flavoring. And no, not really, they > don't, because it's just particular aspects of any given implementation that > may exhibit slowness in certain contexts. And expanding on that trend, later > in the thread the observation was made that no, not really that either, it's > just (if it is at all) at this particular point in time, what about the > future? Let's be precise! Can't have that vague touchy-feely impression about > a /language/ being slow corrupting the souls of readers. Because `language is slow' is meaningless. An earlier post of mine listed four examples where the common wisdom was `XXX is slow' and yet where that turned out not to be the case. Some others. 1. I once owned a Commodore 64. I got Waterloo Pascal for it. I timed the execution of some program (this was 25 years ago, I forget what the program did) at 1 second per statement. Therefore: `Pascal is slow'. 2. Bell Labs produced a fine programming language called Snobol 4. It was slow. But some folks at IIT in Chicago did their own implementation, Spitbol, which was fast and completely compatible. Presto: Snobol 4 was slow, but then it became fast. 3. If you write the following statements in Fortran IV (the last version of Fortran I learned) DO 10 I=1, 100 DO 10 J=1, 100 A(I, J) = 0.0 10 CONTINUE you would paralyze early virtual memory systems, because Fortran IV defined arrays to be stored in column major order, and the result was extreme thrashing. Many programmers did not realize this, and would naturally write code like that. Fortran cognoscenti would interchange the two DO statements and thus convert Fortran from being a slow language to being a fast one. 4. When Sun released the original Java system, programs ran very slowly, and everybody said `I will not use Java, it is a slow language'. Then Sun improved their JVM, and other organizations wrote their own JVMs which were fast. Therefore Java became a fast language. > Actually, although C++ has the potential for being really really fast (and > some C++ programs are), the amount of work you have to add to realize the > potential can be staggering. This is most clearly evidenced by C++'s standard > iostreams, which have the potential of being much much faster than C FILE i/o > (in particular Dietmar Kuhl made such an implementation), but where the > complexity of and the guidance offered by the "design" is such that nearly > all extant implementations are painfully slow, even compared to C FILE. So, > we generally talk about iostreams being slow, knowing full well what we mean > and that fast implementations are theoretically possible (as evidenced by > Dietmar's) -- but "fast" and "slow" are in-practice terms, and so what > matters is in-practice, like, how does your compiler's iostreams > implementation hold up. OK, let me work this one out. Because most iostreams implementations are very slow, C++ is a slow language. But since Kuhl did a high-performance implementation, he made C++ into a fast language. But since most people don't use his iostreams implementation, C++ is a slow language again, except for organizations that have banned iostreams (as my previous employers did) because it's too slow, therefore C++ is a fast language. Being imprecise is so much fun! I should write my programs this imprecisely. More seriously, when someone says `xxx is a slow language', the only thing they can possibly mean is `there is no implementation in existence, and no likelihood of an implementation being possible, that is efficient enough to solve my problem in the required time' or perhaps `I must write peculiar code in order to get programs to run in the specified time; writing code in the way the language seems to encourage produces programs that are too slow'. This is a very sweeping statement, and at the very least ought to be accompanied by some kind of proof. If Python is indeed a slow language, then Unladen Swallow and pypy, and many other projects, are wastes of time, and should not be continued. Again, this doesn't have anything to do with features of an implementation that are slow or fast. The only criterion that makes sense is `do programs run with the required performance if written in the way the language's inventors encourage'. Most implementations of every language have a nook or two where things get embarrassingly slow; the question is `are most programs unacceptably slow'. But, hey, if we are ok with being imprecise, let's go for it. Instead of saying `slow' and `fast', why not say `good' and `bad'? -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 23:20, Robert Brown wrote, quoting me: > On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: > >>> ... Python *the language* is specified in a way that >>> makes executing Python programs quickly very very difficult. > >> That is untrue. I have mentioned before that optional declarations integrate >> well with dynamic languages. Apart from CL and Scheme, which I have >> mentioned several times, you might check out Strongtalk (typed Smalltalk), >> and Dylan, which was designed for high-performance compilation, though to my >> knowledge no Dylan compilers ever really achieved it. > > You are not making an argument, just mentioning random facts. You claim I've > made a false statement, then talk about optional type declarations, which > Python doesn't have. Then you mention Smalltalk and Dylan. What's your > point? To prove me wrong you have to demonstrate that it's not very difficult > to produce a high performance Python system, given current Python semantics. The false statement you made is that `... Python *the language* is specified in a way that makes executing Python programs quickly very very difficult. I refuted it by citing several systems that implement languages with semantics similar to those of Python, and do so efficiently. >> I've never looked at CLPython. Did it use a method cache (see Peter >> Deutsch's paper on Smalltalk performance in the unfortunately out-of-print >> `Smalltalk-80: Bits of History, Words of Advice'? That technique is 30 years >> old now. > > Please look at CLPython. The complexity of some Python operations will make > you weep. CLPython uses Common Lisp's CLOS method dispatch in various places, > so yes, those method lookups are definitely cached. Ah, that does explain it. CLOS is most definitely the wrong vehicle for implementing Python method dispatch. CLOS is focused around generic functions that themselves do method dispatch, and do so in a way that is different from Python's. If I were building a Python implementation in CL, I would definitely NOT use CLOS, but do my own dispatch using funcall (the CL equivalent of the now-vanished Python function apply). > Method lookup is just the tip if the iceburg. How about comparison? Here are > some comments from CLPython's implementation of compare. There's a lot going > on. It's complex and SLOW. Re comparison. Python 3 has cleaned comparison up a fair bit. In particular, you can no longer compare objects of different types using default comparisons. However, it could well be that there are nasty little crannies of inefficiency there, they could be the subject of PEPs after the moratorium is over. > > ;; The CPython logic is a bit complicated; hopefully the following > ;; is a correct translation. I can see why CLPython has such troubles. The author has endeavoured to copy CPython faithfully, using an implementation language (CLOS) that is hostile to Python method dispatch. OK, let me try this again. My assertion is that with some combination of JITting, reorganization of the Python runtime, and optional static declarations, Python can be made acceptably fast, which I define as program runtimes on the same order of magnitude as those of the same programs in C (Java and other languages have established a similar goal). I am not pushing optional declarations, as it's worth seeing what we can get out of JITting. If you wish to refute this assertion, citing behavior in CPython or another implementation is not enough. You have to show that the stated feature *cannot* be made to run in an acceptable time. For example, if method dispatch required an exponential-time algorithm, I would agree with you. But a hypothetical implementation that did method dispatch in exponential time for no reason would not be a proof, but would rather just be a poor implementation. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-13, at 23:39, Robert Brown wrote, quoting me: > Common Lisp blends together features of previous Lisps, which were designed to > be executed efficiently. Operating systems were written in these variants. > Execution speed was important. The Common Lisp standardization committee > included people who were concerned about performance on C-optimized hardware. Guy L Steele, Jr., `Common Lisp The Language' 1/e (1984). p. 1 `COMMON LISP is intended to meet these goals: Commonality [...] Portability [...] Consistency [...] Expressiveness [...] Compatibility [...] Efficiency [...] Power [...] Stability [...]' The elided text amplifies each of the points. I repeat: the purpose of Common Lisp was to have a standard Lisp dialect; efficiency was less of an issue for those investigators. As for C-optimized hardware, well, the dialects it aims to be compatible with are ZetaLisp (Symbolics Lisp Machine), MacLisp (PDP-10), and Interlisp (PDP-10, originally). CLtL mentions S-1 Lisp as its exemplar of high numerical performance. Unfortunately, S-1 Lisp, written by Richard Gabriel and Rod Brooks was never finished. MacLisp was a highly efficient implementation, as I've mentioned. I worked at BBN at the time Interlisp flourished; it was many things, some of them quite wonderful, but efficiency was NOT its goal. > The Scheme standard has gone through many revisions. I think we're up to > version 6 at this point. The people working on it are concerned about > performance. Yes, they are. You should see 's rants about how specified certain features so they'd be efficient on his implementation. I had real people's names there, but I deleted them in the interests of not fanning flamewar flames. > For instance, see the discussions about whether the order of > evaluating function arguments should be specified. That was a long time ago, and had as much if not more to do with making arguments work the same as let forms as it had to do with efficiency. But I'll point out that the big feature of Scheme is continuations, and it took quite a few years after the first Scheme implementations came out to make continuations stop being horrendously *IN*efficient. > You can't point to Rabbit (1978 ?) as > representative of the Scheme programming community over the last few decades. I didn't. I used it to buttress YOUR argument that Schemers have always been concerned with performance. >> Using Python 3 annotations, one can imagine a Python compiler that does the >> appropriate thing (shown in the comments) with the following code. > I can imagine a lot too, but we're talking about Python as it's specified > *today*. The Python language as it's specified today is hard to execute > quickly. Not impossible, but very hard, which is why we don't see fast Python > systems. Python 3 annotations exist. Check the Python 3 Language Reference. I notice you've weakened your claim. Now we're down to `hard to execute quickly'. That I would agree with you on, in that building an efficient Python system would be a lot of work. However, my claim is that that work is engineering, not research: most of the bits and pieces of how to implement Python reasonably efficiently are known and in the public literature. And that has been my claim since the beginning. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-14, at 00:22, Alf P. Steinbach wrote, in response to my earlier post. > Anyways, it's a good example of focusing on irrelevant and meaningless > precision plus at the same time utilizing imprecision, higgedly-piggedly as > it suits one's argument. Mixing hard precise logic with imprecise concepts > and confound e.g. universal quantification with existential quantification, > for best effect several times in the same sentence. Like the old Very Hard > Logic + imprecision adage: "we must do something. this is something. ergo, we > must do this". OK, now we've reached a total breakdown in communication, Alf. You appear to take exception to distinguishing between a language and its implementation. My academic work, before I became a computer science/software engineering instructor, was in programming language specification and implementation, so I *DO* know what I'm talking about here. However, you and I apparently are speaking on different wavelengths. > It's just idiocy. Regretfully, I must agree. > But fun. Not so much, from my viewpoint. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On 2009-11-14, at 01:11, Alf P. Steinbach wrote: >> OK, now we've reached a total breakdown in communication, Alf. You appear >> to take exception to distinguishing between a language and its >> implementation. > > Not at all. > > But that doesn't mean that making that distinction is always meaningful. It certainly is. A language is a (normally) infinite set of strings with a way of ascribing a meaning to each string. A language implementation is a computer program of some sort, which is a finite set of bits representing a program in some language, with the effect that the observed behavior of the implementation is that strings in the language are accepted, and the computer performs the operations defined by the semantics. These are always different things. > It's not like "there exists a context where making the distinction is not > meaningful" means that "in all contexts making the distinction is meaningful". Because they are different things, in all cases the distinction is meaningful. > > So considering that, my quoted comment about confounding universal > quantification with existential quantification was spot on... :-) It was not spot on. The examples I provided were just that, examples to help people see the difference. They were not presented as proof. The proof comes from the definitions above. > In some contexts, such as here, it is meaningless and just misleading to add > the extra precision of the distinction between language and implementation. > Academically it's there. But it doesn't influence anything (see below). Your assertion that this distinction is meaningless must be based upon YOUR definitions of words like `language' and `implementation'. Since I don't know your definitions, I cannot respond to this charge. > Providing a counter example, a really fast Python implementation for the kind > of processing mix that Google does, available for the relevant environments, > would be relevant. I have presented arguments that the technologies for preparing such an implementation are basically known, and in fact there are projects that aim to do exactly that. > > Bringing in the hypothethical possibility of a future existence of such an > implementation is, OTOH., only hot air. Hmm...in every programming project I have ever worked on, the goal was to write code that didn't already exist. > If someone were to apply the irrelevantly-precise kind of argument to that, > then one could say that future hypotheticals don't have anything to do with > what Python "is", today. Now, there's a fine word-splitting distinction... ;-) Python is a set of strings, with a somewhat sloppily-defined semantics that ascribes meaning to the legal strings in the language. It was thus before any implementation existed, although I imagine that the original Python before GvR wrote any code had many differences from what Python is today. It is quite common for language designers to specify a language completely without regard to an implementation, or only a `reference' implementation that is not designed for performance or robustness. The `good' implementation comes after the language has been defined (though again languages and consequently implementations are almost always modified after the original release). If you like, a language is part of (but not all of) the set of requirements for the implementation. Alf, if you want to say that this is a difference that makes no difference, don't let me stop you. You are, however, completely out of step with the definitions of these terms as used in the field of programming languages. >> My academic work, before I became a computer science/software engineering >> instructor, was in programming language specification and implementation, so >> I *DO* know what I'm talking about here. However, you and I apparently >> are speaking on different wavelengths. > > Granted that you haven't related incorrect facts, and I don't think anyone > here has, IMO the conclusions and implied conclusions still don't follow. The fact that you see the situation that way is a consequence of the fact that we're on different wavelengths. -- v -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
This whole thread has now proceeded to bore me senseless. I'm going to respond once with a restatement of what I originally said. Then I'm going to drop it, and never respond to the thread again. Much of what's below has been said by others as well; I'm taking no credit for it, just trying to put it together into a coherent framework. 1. The original question is `Is Python scalable enough for Google' (or, I assume any other huge application). That's what I was responding to. 2. `Scalable' can mean performance or productivity/reliability/maintenance quality. A number of posters conflated those. I'll deal with p/r/m by saying I'm not familiar with any study that has taken real enterprise-type programs and compared, e.g., Java, Python, and C++ on the p/r/m criteria. Let's leave that issue by saying that we all enjoy programming in Python, and Python has pretty much the same feature set (notably modules) as any other enterprise language. This just leaves us with performance. 3. Very clearly CPython can be improved. I don't take most benchmarks very seriously, but we know that CPython interprets bytecode, and thus suffers relative to systems that compile into native code, and likely to some other interpretative systems. (Lua has been mentioned, and I recall looking at a presentation by the Lua guys on why they chose a register rather than stack-based approach.) 4. Extensions such as numpy can produce tremendous improvements in productivity AND performance. One answer to `is Python scalable' is to rephrase it as `is Python+C scalable'. 5. There are a number of JIT projects being considered, and one or more of these might well hold promise. 6. Following Scott Meyers' outstanding advice (from his Effective C++ books), one should prefer compile time to runtime wherever possible, if one is concerned about performance. An implementation that takes hints from programmers, e.g., that a certain variable is not to be changed, or that a given argument is always an int32, can generate special-case code that is at least in the same ballpark as C, if not as fast. This in no way detracts from Python's dynamic nature: these hints would be completely optional, and would not change the semantics of correct programs. (They might cause programs running on incorrect data to crash, but if you want performance, you are kind of stuck). These hints would `turn off' features that are difficult to compile into efficient code, but would do so only in those parts of a program where, for example, it was known that a given variable contains an int32. Dynamic (hint-free) and somewhat less-dynamic (hinted) code would coexist. This has been done for other languages, and is not a radically new concept. Such hints already exist in the language; __slots__ is an example. The language, at least as far as Python 3 is concerned, has pretty much all the machinery needed to provide such hints. Mechanisms that are recognized specially by a high-performance implementation (imported from a special module, for example) could include: annotations, decorators, metaclasses, and assignment to special variables like __slots__. 7. No implementation of Python at present incorporates JITting and hints fully. Therefore, the answer to `is CPython performance-scalable' is likely `NO'. Another implementation that exploited all of the features described here might well have satisfactory performance for a range of computation-intensive problems. Therefore, the answer to `is the Python language performance-scalable' might be `we don't know, but there are a number of promising implementation techniques that have been proven to work well in other languages, and may well have tremendous payoff for Python'. -- v -- http://mail.python.org/mailman/listinfo/python-list
