OLPC upgrades

[Albert Cahalan]

On Wed, Feb 4, 2009 at 2:14 PM, Wade Brainerd <wadetb at gmail.com> wrote:
> On Wed, Feb 4, 2009 at 1:38 AM, Albert Cahalan <acahalan at gmail.com> wrote:
>> Bobby Powers writes:

>>> The idea is to give kids as much transparency into the software
>>> stack as possible, AND make it easy to hack on and easy to create
>>> new activities for.  Python is much more forgiving than C.
>>
>> Python is less forgiving if you want performance on the XO. :-)
>>
>> For teaching, remember that Knuth uses assembly. C is an awful
>> lot closer to that than Python, and isn't the XO about teaching?
>
> Ha, ahat age group is Knuth teaching assembly to??  What level of math and
> science skills are they expected to have?

Assuming we start with no programming skills...

Assembly has a reputation for being "hard", but this is
far from the truth. It is large assembly projects that are
hard to understand. For tiny things, assembly is even
easier than C. What you see is what you get, exactly.
Python has lots of magic. With assembly, everything
is there for you to see.

>> > Its killing the XO?  A personal pygtk based project launches in a few
>> > seconds on my debXO install on an XO, but much much longer on 8.2.
>> > It is a completely loaded statement to say that Python is killing
>> > the XO, and didn't really deserve a response :)
>>
>> I'm assuming that "personal [...] project" means small.
>>
>> The fact that you consider "a few seconds" to be acceptable shows
>> just how much people have lost touch with the concept of performance.
>
> Python is not the problem. Just strace the activity startup process to see
> everything that goeson.

Using strace is not appropriate here. It's appropriate when
you know that computational overhead is low. (when using C)

> A lot of it appears to be erelated to
> a) Rainbow
> b) Journal instance creation

Not that strace is appropriate, but AFAIK these are Python.

> Also I agree that the huge animated loating icon is probably not helping on
> XO.  Could'nt it be replaced by a large non-animated icon in the center of
> the screen, and then smoe dots that appear around the icon in a circle,
> adding one dot per second, like a clock?  That would take no overhead and
> would even give an informal way to measure startup time by counting the
> dots.

That'd be an improvement, but it would still hurt. Good software
can start far faster than you can display a non-animated icon.

> Please don't try to hijack a technical discussion into a political one.

Already done...

(disturbing that a technical choice is considered political though)

> Use of the Python language is not the cause of the performance problems
> on the XO or in Sugar in general.  Every system must be optimized no
> matter what language it is written in.  It just takes a little effort.

...and you are in fact in denial.

If it were a **little** effort, Sugar would be well-optimized by now.
Lots of effort has been applied to the problem, with little result.

Sure, one can optimize code in any language. This does not
contradict the simple fact that some languages are really slow.
You won't get far if you insist on using a stinker.