Fwd: The XO-1.5 software plan.
NoiseEHC at freemail.hu
Sat May 16 14:35:30 EDT 2009
Please, always use reply-all. Answers inlined where I have an answer.
Tiago Marques wrote:
> On Sat, May 16, 2009 at 6:42 PM, NoiseEHC <NoiseEHC at freemail.hu
> <mailto:NoiseEHC at freemail.hu>> wrote:
> The 1GHz C7 is still a slow cpu, as it seems from reviews of
> similar netbooks:
> For most tasks it is slower than an 600MHz Celeron M and
> that's not exactly fast. Does anyone more familiar with the
> hardware have any idea of how fast it is when compared to the
> >From my measurements of the Geode and the very limited
> "documentation" of the C7 I can speculate that the integer unit
> can have similar speed to the Geode clock-by-clock (but can have a
> better branch predictor and faster movsb/movsd implementation) and
> probably the floating point unit is better integrated so floating
> point code does not block the integer unit like on the Geode. So
> if we do not consider the 3d unit or the probably better flash
> hardware (scatter-gather support) it will have exactly the same
> speed on similar clock speeds but of course it can go more than 2x
> And the memory should also help, it should be enough. But still, IMHO
> Xfce would still be a better fit, especially since these laptops go to
> places where things being snappy is almost a requirement.
I do not think that the memory speed is a bottleneck on the XO-1. The
problem is that the Geode is an in-order processor and an uncached
memory read block the processor for >25 clocks. It will be the same on
the C7 unless it has a Core2 Duo category speculative memory prefetcher
but of course I doubt it... BTW the faster memory will not hurt either.
> What about random write performance of the flash memory this time?
> That will be a show stopper if it's below at least 0.5MB/s. But that
> would be hard without cache for the flash.
The 0.5 MB/s came mostly from the zlib compression code. With LZO the
Geode could compress 10MB/sec so it would have been a big help in write
performance but the conclusion from most of the developers was that the
biggest win would be having per inode compression setting (like not
compressing zip and jpeg files) but of course nothing was implemented.
BTW I have a half-made asm zlib decompressor what I have left rotting
since it became impossible to debug (hallowed are gcc developers and the
holy UNIX command piping, gcc generates 1 line of debug info for a whole
asm block). I have another half-made asm decompressor for LZO but it
seems that the creator of LZO f***ed up the code and it has unused
opcodes so I tried to actually document the LZO compressor but my
efforts stalled since kernel developers were fired from OLPC (I will not
integrate such code to the kernel that is sure).
The conclusion is that if the XO 1.5 will use a normal filesystem then
compression will not be supported so flash write speed will not be a
> As for Gnome/Xfce/KDE, whatever, how are you considering that older
> students guess where F1-12 are? Are any changes planned for the
> keyboard stamping to accommodate this change in direction or are you
> taking that as part of the learning process?
I do not know so reposted to devel.
> Best regards,
> Tiago Marques
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel