OLPC upgrades

[Wade Brainerd]

2009/2/7 Tiago Marques <tiagomnm at gmail.com>

> That seems a good idea.
> The use of SVGs seems unnecessary. Although an awsome functionality, which
> probably saves a lot of work, would allow to scale the use of Sugar to
> systems with bigger screens - were it probably will never be in use. I've
> never seen SVGs being used extensively in a desktop system, let alone an
> "embedded" one.
>

Caching the SVGs as pixmaps can help this out a lot.  I remember IRIX from
the mid 90s using vector-based icons, and it didn't seem to have performance
issues.


> As I talked with some people that know more Python than me, they argued
> that programmer productivity would be a major factor for it's use in some
> situations. I haven't heard that argument here. I haven't read a good
> argument that justifies the burden of using an interpreted language in a
> desktop environment, so it really does seem stubbornness more than anything
> else, even more and it's all already written in Python.
>

It is wonderful to be able to modify a part of the Sugar shell or an
Activity directly on the XO, without the need for a compiler and a wide
variety of installed headers and libraries eating up space on your disk, not
to mention obscure build systems and megabytes of build artifacts.

It's also great that most activities are <100k downloads and are totally
cross platform and architecture independent.

> No matter what interpreted language you're using, it will always stink.
> Either it's java, python, javascript, whatever. Sugar isn't a webapp, it
> doesn't even need to be so portable that it can't be written in a language
> that can be compiled.
>
Here's the difference:  In Sugar, Python fills the role of the *glue* code.
 It doesn't do any real work itself.

> Even in powerful machines, most programs I have used written in Java have a
> huge amount of computing and memory overhead - and Java isn't the worst of
> it, I read.
>
Do you need high performance for every program?  I use GMail all day and
have never had a performance issue with it.

> I can't stress this enough: unless the whole OLPC project is starting to
> take aim at building a laptop that doesn't cost less than $170, I don't see
> any reason at all not to properly optimize the software. You will always be
> running some kind of over powered, embedded type system, with little RAM and
> CPU power.
>
I completely agree, I just want to make sure the optimization happens to the
right parts - the parts that do the heavy lifting.  And the algorithms that
control the parts that do the heavy lifting.

For example, I was recently involved in a discussion about the pulsing icon
that is shown when activities launch.  It turns out, the *entire screen* was
being redrawn at 10fps, not just the activity icon.  Not to mention that the
icon caching was not working, so the .svg file was being reparsed each frame
and going through a text filter like s/&stroke_color;/#aabbcc/ to achieve
the pulsed color.  Fortunately Benjamin Berg corrected this today.

Another one, I have had to rewrite large chunks of THREE of my activities to
overcome performance issues in Cairo (which is an optimized library written
in C).  I have written several games and other realtime activities for the
XO and not yet seen Python become a bottleneck.

> The whole project is taking the show source thing way too far, hurting you
> too much, especially as that is still far from "the vision". You already
> have Pippy, which should be enough for most kids. The really good kids won't
> have a problem doing the work to go to the next step(building activities and
> such) and you can always leave the door open for python activities, while
> having the basis of Sugar in C, C++ or something. Isn't that what bindings
> between languages are for?
>
I'm telling you, I'm still looking for some solid performance numbers.
 Memory issues I am more inclined to believe but again, actually optimizing
the problem (controlling Python's garbage collector) is a much better
solution than throwing everything away and starting over!

I have spent the last 10 years optimizing software for a living, and can
tell you without a doubt that any system can be optimized without starting
from scratch.

It's just much harder to understand the performance characteristics of a
large, complex, existing system than it is to imagine an ideal performance
world in your head.

Best regards,
Wade

> Best regards,
>
>                             Tiago Marques
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20090210/c3a7fd0b/attachment.html>