Re: [Tutor] python, speed, game programming

2014-01-04 Thread Steven D'Aprano
On Fri, Jan 03, 2014 at 02:11:21PM -0800, Devin Jeanpierre wrote:
 On Fri, Jan 3, 2014 at 1:53 PM, Keith Winston keithw...@gmail.com 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

2014-01-04 Thread spir

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

2014-01-04 Thread spir

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

2014-01-04 Thread Steven D'Aprano
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

2014-01-04 Thread Danny Yoo
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

2014-01-04 Thread Keith Winston
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 d...@hashcollision.org 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


[Tutor] python, speed, game programming

2014-01-03 Thread Keith Winston
-- 
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

2014-01-03 Thread Keith Winston
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


Re: [Tutor] python, speed, game programming

2014-01-03 Thread Keith Winston
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 keithw...@gmail.com 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

2014-01-03 Thread Devin Jeanpierre
On Fri, Jan 3, 2014 at 1:53 PM, Keith Winston keithw...@gmail.com 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

2014-01-03 Thread spir

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

2014-01-03 Thread Keith Winston
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 denis.s...@gmail.com 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

2014-01-03 Thread Alan Gauld

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

2014-01-03 Thread Keith Winston
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 alan.ga...@btinternet.comwrote:

 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

2014-01-03 Thread Keith Winston
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 keithw...@gmail.com 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 alan.ga...@btinternet.comwrote:

 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

2014-01-03 Thread Mark Lawrence

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

2014-01-03 Thread Keith Winston
On Fri, Jan 3, 2014 at 11:14 PM, Mark Lawrence breamore...@yahoo.co.ukwrote:

 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