Re: [Tutor] python, speed, game programming
Hi Danny, no, I don't think there's any disk access, and the memory of the two machines is rather different: one is 4 Gb or so, the other 9 changing to 12 any day... but I think I haven't been rigorous enough to justify a great deal more attention here. I am convinced that I should just keep developing my next project, and my programming skills, and worry about speed issues as I hit them. I was overreaching, or anticipating or something... On Sat, Jan 4, 2014 at 10:30 PM, Danny Yoo wrote: > There's an assumption in the question here that all programs are CPU bound. > > I actually do not think so. From prior discussion about what the > program is doing, I got the impression that it was trying to hold > gigabytes of data in RAM. Isn't that still true? If so, then I would > be very surprised if the program were not thrashing virtual memory. > Under such conditions, give up on any assumptions about program speed > being related to CPU speed. It's hitting disk hard, and that's a Game > Over. Under heavy virtual memory swapping conditions, it doesn't > matter how fast your CPU is: the time that your program is taking is > due to the physical act of moving spindles and spinning disks of metal > around. > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
There's an assumption in the question here that all programs are CPU bound. I actually do not think so. From prior discussion about what the program is doing, I got the impression that it was trying to hold gigabytes of data in RAM. Isn't that still true? If so, then I would be very surprised if the program were not thrashing virtual memory. Under such conditions, give up on any assumptions about program speed being related to CPU speed. It's hitting disk hard, and that's a Game Over. Under heavy virtual memory swapping conditions, it doesn't matter how fast your CPU is: the time that your program is taking is due to the physical act of moving spindles and spinning disks of metal around. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On Fri, Jan 03, 2014 at 08:38:47PM -0500, Keith Winston wrote: > The thing that put me on edge was noticing that my simple > Chutes & Ladders game doesn't go ANY faster on a machine that benchmarks > perhaps 1000 times faster than another... Damn! You've discovered our secret! Hidden deep insight the Python compiler is code that determines the speed of computer, and deliberately slows down the Python runtime so that it runs just as slowly on all PCs, no matter how fast they are or how much memory they have... *wink* But seriously... This is clearly bogus. There has to be an explanation, apart from "Python secretly tries to run just as slow on everything". Even slow, inefficient code will run faster on faster hardware. But how much faster? How accurate are your timing measurements? Some possible explanations: - the method you used to time the code is inaccurate or doesn't measure what you think it does; - the code you have written spends most of its time doing things that aren't sped up by a faster computer, e.g. waiting for human input, downloading data from the Internet, reading and writing to a network drive, etc.; - the benchmarks that say the second computer is 1000 times faster than the first are bogus (not necessarily lying, although possibly lying by ommission). I expect that the anwser to this mystery is a combination of the first and the last factors. It's harder to measure the execution speed of code than you might think, and most PC benchmarks are worse than you might think. Many benchmarks are artifical and designed as advertising, to show the product in the best possible light. If a machine has a CPU clock speed that is 1000 times faster than the last model, the benchmarks will all be for tiny little programlets that are reliant on CPU speed. Meanwhile, the fact that real-world applications see hardly any benefit because the computer can't push data into and out of the CPU any faster than before gets conveniently swept under the carpet. (Cynical? Who, me?) -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On 01/04/2014 02:38 AM, Keith Winston wrote: The thing that put me on edge was noticing that my simple Chutes & Ladders game doesn't go ANY faster on a machine that benchmarks perhaps 1000 times faster than another... You could say this about most programs in most langs. Actually, some even regress in perf while harware progresses by orders of magnitude. This is due to the whole software platform (OS + layers of UI and graphics, plus underlying libs and frameworks, plus the ones your apps explicitely call) becoming more and more HW resource consuming, this independently of actual app logic processing. As Alan evoked, I remember how early PCs were fast, retrospectively, with comparatively ridiculous HW resources (clock freq & live mem mainly). Resource consumptions of what I call here software platforms have progressed at a rythm comparable to HW resources. However, in general, there remain resource gains for apps, in absolute (rather than proportional) value. (But you can see that prop gains are not that important when running multiple heavy apps at once.) Denis ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On 01/04/2014 10:14 AM, Steven D'Aprano wrote: While I agree with Devin, it is possible to write absurdly slow code in *any* language. This is why is is better to write straightforward, simple code in preference to complicated, intricate code -- it is easier to understand simple code, which means it is easier to work out which bits are bottlenecks and do something about them. Then, only if it turns out the code is too slow, do you add complexity to speed it up. +++ I would add: it is preferable to write _clear_ code, in the widest sense of "easy to understand". Simplicity is not the only factor or clarity (good naming, using right constructs [1], direct mapping from conception to code structure & logic...); also, some simple schemes are very difficult to figure out (eg various functional programing idioms). From clear code, everything else is easier: modification, extension, improving efficeincy (time and/or space), doc, debugging, testing, trials... I would even say (surprisingly?) that clarity has precedence over correctness: it's easier to correct clear code, while correct but obscure code makes anything else harder. personal point of view: Issue number 1 in programming is understanding (what code actually means and actually does). That's why we spend about 97.531% of our time thinking ;-) Denis [1] Python's "one good way to do it". ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On Fri, Jan 03, 2014 at 02:11:21PM -0800, Devin Jeanpierre wrote: > On Fri, Jan 3, 2014 at 1:53 PM, Keith Winston wrote: > > I am gearing up for the next project (yeah, an eventual end to Chutes & > > Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak but > > I would expect it easily adapted to QWERTY or anything else. [...] > Modern computers are just so absurdly fast that the overhead Python > has compared to other languages just doesn't matter for the kind of > work you are doing. If you typed at a hundred characters per second > Python could still keep up, unless there's something about your > problem you aren't describing. While I agree with Devin, it is possible to write absurdly slow code in *any* language. This is why is is better to write straightforward, simple code in preference to complicated, intricate code -- it is easier to understand simple code, which means it is easier to work out which bits are bottlenecks and do something about them. Then, only if it turns out the code is too slow, do you add complexity to speed it up. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On Fri, Jan 3, 2014 at 11:14 PM, Mark Lawrence wrote: > On 03/01/2014 21:41, Keith Winston wrote: > >> -- >> Keith >> >> > Frankly I think you're lining up to jump fences when you're actually > riding on the flat :) > Fair enough, but I am thinking of the next project as a long-term dabbling: hopefully my abilities will rise to my concept... I guess I'm about 3 weeks into Python (and OOP) so far, of course my ability to focus on it will depend on work and other pressures, but I'm amazed at how accessible this language is. Anyway, thanks to you and everyone who've helped me as I crawl on the flat... this group has been way more than invaluable. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On 03/01/2014 21:41, Keith Winston wrote: -- Keith Frankly I think you're lining up to jump fences when you're actually riding on the flat :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
Truth in advertising: I just realized a Core I7 only benchmarks about 10x faster than a Core 2 Duo, using Passmark. Wow, something like 6 years newer and only 10 times? Anyway, I'd STILL expect to see some of that in the program performance, though maybe once I get it ironed out it will be a little sleeker... Keith On Fri, Jan 3, 2014 at 8:38 PM, Keith Winston wrote: > Just to be clear, what I'm asking this typing tutor to do is vastly more > than normal, albeit still not seemingly very much. In most programs, they > give you a sentence or paragraph to type, and then time how long it takes. > I'm talking about timing every keypress, and modifying the text stream > based on that. The thing that put me on edge was noticing that my simple > Chutes & Ladders game doesn't go ANY faster on a machine that benchmarks > perhaps 1000 times faster than another... > > Keith > > > On Fri, Jan 3, 2014 at 8:17 PM, Alan Gauld wrote: > >> On 03/01/14 21:53, Keith Winston wrote: >> >> Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak >>> but I would expect it easily adapted to QWERTY or anything else. >>> ... >>> >>> >>> My concern is with speed. This will have to keep up with (somewhat >>> arbitrarily) fast typing, >>> >> >> Lets see. The speed record for touch typing is around 150 wpm with >> average word being about 5 chars, so a speed of about 750 cpm >> or 12.5cps That's about 80ms between letters. >> >> Python on a modern PC can probably execute around 100k lines >> of code(*) per second or 100 per millisecond. That's 8k lines >> executed between each keypress for the worlds fastest typist. >> >> I used to use a typing tutor that was written in old GW Basic >> on the original IBM PC (speed 4.7MHz) and it had no problem >> analyzing my stats (albeit at a modest 40-50 wpm). >> >> I'd worry about speed after you find you need to. >> >> (*)Caveat: I haven't tried any kind of objective test and >> of course some Python 'lines' are equal to many >> lines of simpler languages - think list comprehensions. >> But in practice I still don't think you will have a >> big problem. >> >> >> -- >> Alan G >> Author of the Learn to Program web site >> http://www.alan-g.me.uk/ >> http://www.flickr.com/photos/alangauldphotos >> >> >> ___ >> Tutor maillist - Tutor@python.org >> To unsubscribe or change subscription options: >> https://mail.python.org/mailman/listinfo/tutor >> > > > > -- > Keith > -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
Just to be clear, what I'm asking this typing tutor to do is vastly more than normal, albeit still not seemingly very much. In most programs, they give you a sentence or paragraph to type, and then time how long it takes. I'm talking about timing every keypress, and modifying the text stream based on that. The thing that put me on edge was noticing that my simple Chutes & Ladders game doesn't go ANY faster on a machine that benchmarks perhaps 1000 times faster than another... Keith On Fri, Jan 3, 2014 at 8:17 PM, Alan Gauld wrote: > On 03/01/14 21:53, Keith Winston wrote: > > Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak >> but I would expect it easily adapted to QWERTY or anything else. >> ... >> >> >> My concern is with speed. This will have to keep up with (somewhat >> arbitrarily) fast typing, >> > > Lets see. The speed record for touch typing is around 150 wpm with average > word being about 5 chars, so a speed of about 750 cpm > or 12.5cps That's about 80ms between letters. > > Python on a modern PC can probably execute around 100k lines > of code(*) per second or 100 per millisecond. That's 8k lines > executed between each keypress for the worlds fastest typist. > > I used to use a typing tutor that was written in old GW Basic > on the original IBM PC (speed 4.7MHz) and it had no problem > analyzing my stats (albeit at a modest 40-50 wpm). > > I'd worry about speed after you find you need to. > > (*)Caveat: I haven't tried any kind of objective test and > of course some Python 'lines' are equal to many > lines of simpler languages - think list comprehensions. > But in practice I still don't think you will have a > big problem. > > > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > http://www.flickr.com/photos/alangauldphotos > > > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On 03/01/14 21:53, Keith Winston wrote: Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak but I would expect it easily adapted to QWERTY or anything else. ... My concern is with speed. This will have to keep up with (somewhat arbitrarily) fast typing, Lets see. The speed record for touch typing is around 150 wpm with average word being about 5 chars, so a speed of about 750 cpm or 12.5cps That's about 80ms between letters. Python on a modern PC can probably execute around 100k lines of code(*) per second or 100 per millisecond. That's 8k lines executed between each keypress for the worlds fastest typist. I used to use a typing tutor that was written in old GW Basic on the original IBM PC (speed 4.7MHz) and it had no problem analyzing my stats (albeit at a modest 40-50 wpm). I'd worry about speed after you find you need to. (*)Caveat: I haven't tried any kind of objective test and of course some Python 'lines' are equal to many lines of simpler languages - think list comprehensions. But in practice I still don't think you will have a big problem. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
Okay, thanks, I'll probably be proceeding over the next few weeks, as I finish up my Chutes & Ladders project... I think I have to do a bit more code/manual reading in proportion to my coding for a bit, also. Thanks for the insights. K On Fri, Jan 3, 2014 at 6:12 PM, spir wrote: > On 01/03/2014 10:53 PM, Keith Winston wrote: > >> My concern is with speed. This will have to keep up with (somewhat >> arbitrarily) fast typing, while doing background processing, with a GUI of >> course. >> > > I wouldn't even bother. Try & see, you may be surprised. There are several > factors at play: > * The core processing in dealing with user input (read, decode, store, > queue key strokes, etc) will be done by low-level (OS) routines written in > C, with only thin Python wrappers (which essentially translate from/to > python data types). > * Similar point for GUI and/or other user interface layer (less so if > you'd use a pure python GUI framework, but in general they're also just > wrappers over C code). > * The ratio between such low-level processing and actual processing code > written and executed in python for your application logic is certainly high > (as is usually the case), unless there is much realtime computation you did > not speak about. > Anyway, just try and see. > > This is similar to how & why python is reputed to be good (read: fast) at > "number crunching": they are standard libs for that just link to low-level > C routines which do about all computation, behind the stage, and very few > application logic remains written *and actually executed* in python (search > "numpy"). > > Denis > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On 01/03/2014 10:53 PM, Keith Winston wrote: My concern is with speed. This will have to keep up with (somewhat arbitrarily) fast typing, while doing background processing, with a GUI of course. I wouldn't even bother. Try & see, you may be surprised. There are several factors at play: * The core processing in dealing with user input (read, decode, store, queue key strokes, etc) will be done by low-level (OS) routines written in C, with only thin Python wrappers (which essentially translate from/to python data types). * Similar point for GUI and/or other user interface layer (less so if you'd use a pure python GUI framework, but in general they're also just wrappers over C code). * The ratio between such low-level processing and actual processing code written and executed in python for your application logic is certainly high (as is usually the case), unless there is much realtime computation you did not speak about. Anyway, just try and see. This is similar to how & why python is reputed to be good (read: fast) at "number crunching": they are standard libs for that just link to low-level C routines which do about all computation, behind the stage, and very few application logic remains written *and actually executed* in python (search "numpy"). Denis ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On Fri, Jan 3, 2014 at 1:53 PM, Keith Winston wrote: > I am gearing up for the next project (yeah, an eventual end to Chutes & > Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak but > I would expect it easily adapted to QWERTY or anything else. > [snip] > > I hope Python is a good choice here, though I suppose some modules or > classes or parts will have to be recoded into something faster... Any > thoughts on this will be appreciated, including how to structure it in such > a manner that it might be more portably applied to future versions in > entirely different knowledge realms (music/midi input, > language/vocabulary/audio output, etc). Modern computers are just so absurdly fast that the overhead Python has compared to other languages just doesn't matter for the kind of work you are doing. If you typed at a hundred characters per second Python could still keep up, unless there's something about your problem you aren't describing. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
Just to be clear: this is equal parts learning Python project, prototype tutorial software project, OOP practice, and the beginning of a more general inquiry into learning styles/paradigms/parameters... I'm (slowly) writing some of these ideas up in a separate doc. On Fri, Jan 3, 2014 at 4:53 PM, Keith Winston wrote: > Shoot, sorry for the empty message. Here's what I was going to say: > > I am gearing up for the next project (yeah, an eventual end to Chutes & > Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak > but I would expect it easily adapted to QWERTY or anything else. > > The basic idea is build a database of the key and response time of every > keystroke, with simultaneous background processing going on, based on a > customizable set of parameters to select the test text in more or less real > time. So for example, I might wish to adjust the interval at which I > revisit old material, to be sure I "get" it without becoming bored by it: > we could call this the repetition interval, and it might well be a function > that increases with time, though it might also be keyed to the speed of > recall... all responses are to be saved long-term for subsequent analysis. > > My concern is with speed. This will have to keep up with (somewhat > arbitrarily) fast typing, while doing background processing, with a GUI of > course. This illustrates why I was concerned about the fact that my Chutes > & Ladders game seems to run at the same speed on my 8 y.o. Core 2 Duo and > my 2 y.o. Core I7 with 3-4x as much memory. This WILL require a faster > machine and a more significant share of it's resources, if I develop it in > the direction I am thinking. > > I hope Python is a good choice here, though I suppose some modules or > classes or parts will have to be recoded into something faster... Any > thoughts on this will be appreciated, including how to structure it in such > a manner that it might be more portably applied to future versions in > entirely different knowledge realms (music/midi input, > language/vocabulary/audio output, etc). > > -- > Keith > -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
Shoot, sorry for the empty message. Here's what I was going to say: I am gearing up for the next project (yeah, an eventual end to Chutes & Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak but I would expect it easily adapted to QWERTY or anything else. The basic idea is build a database of the key and response time of every keystroke, with simultaneous background processing going on, based on a customizable set of parameters to select the test text in more or less real time. So for example, I might wish to adjust the interval at which I revisit old material, to be sure I "get" it without becoming bored by it: we could call this the repetition interval, and it might well be a function that increases with time, though it might also be keyed to the speed of recall... all responses are to be saved long-term for subsequent analysis. My concern is with speed. This will have to keep up with (somewhat arbitrarily) fast typing, while doing background processing, with a GUI of course. This illustrates why I was concerned about the fact that my Chutes & Ladders game seems to run at the same speed on my 8 y.o. Core 2 Duo and my 2 y.o. Core I7 with 3-4x as much memory. This WILL require a faster machine and a more significant share of it's resources, if I develop it in the direction I am thinking. I hope Python is a good choice here, though I suppose some modules or classes or parts will have to be recoded into something faster... Any thoughts on this will be appreciated, including how to structure it in such a manner that it might be more portably applied to future versions in entirely different knowledge realms (music/midi input, language/vocabulary/audio output, etc). -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] python, speed, game programming
-- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor