[Trac #125] Geode GX is a poor CPU choice

[supat at supat.eu.org]

Hi,

Total performance of OLPC based on "Limiting Factors Theory".
We cannot know its total performance at this day because we still use USB 
storage while true performance based on internal memory.

So, increasing CPU performance may or may not affect total performance but 
improve in storage speed are surely improve total OLPC performance.

At this moment, the first limiting factor is USB storage speed and it has 
acceptible performance based on my experiment.

Ofcause, improve in CPU performance and internal memory storage may 
imporove OLPC quality much. And we should do it.

Regards,
supat

On Mon, 25 Sep 2006, Zarro Boogs per Child wrote:

> #125: Geode GX is a poor CPU choice
> ------------------------+---------------------------------------------------
> Reporter:  bluefoxicy  |        Owner:  mfoster
>     Type:  defect      |       Status:  new
> Priority:  low         |    Milestone:
> Component:  hardware    |   Resolution:
> Keywords:              |
> ------------------------+---------------------------------------------------
> Old description:
>
>> The first revision of machines is going to be based on the Geode GX.
>> Reviewing its data sheet, there are a few numbers that need attention:
>>
>> * Memory controller on the CPU
>> * 32KiB L1 cache
>> ** 16KiB I1
>> ** 16KiB D1
>> ** 4-way Set Associative
>> ** 1 Cycle Cache hits
>> ** 2 Cycle Cache hits if not using the same way
>> ** '''25 Cycle''' Cache misses (give or take a few depending on the exact
>> conditions)
>> * No L2 Cache
>> * 80-Entry TLB
>> ** 8 L1 ITLB
>> ** 8 L1 DTLB
>> ** 64 L2 TLB
>>
>> To simulate cache, you can use the following cachegrind line:
>>
>>   ''valgrind --tool=cachegrind --I1=16384,4,32 --D1=16384,4,32
>> --L2=64,2,32 [program]''
>>
>> Ignore L2, it doesn't exist on the Geode GX.  Cachegrind demands it be
>> set valid.
>>
>> A simulation of Rhythmbox shows a 1.2% overall cache miss rate.  Multiply
>> this by 25 cycles and that's a 33.2% slowdown; multitasking will give you
>> another 0.7% slowdown give or take a little bit but this is negligible.
>>
>> The folks in ##electronics on Freenode seemed to be under the impression
>> that 25 cycle cache miss penalties indicate a "crippled" CPU and that
>> this thing is "dumpster-bait."  I'm no EE so I'll have to go with what
>> they came up with.
>>
>> Point being, we should look at moving to a new CPU in the next revision,
>> if possible.  Another choice is to try to get AMD to redesign the memory
>> controller to find some L2 somewhere at only a few cycles per cache miss;
>> but this is probably not really feasible (modify the hardware?  Uh..).
>> I've had thoughts along this vein but I'm not an EE, and they're already
>> splattered on the mailing list so I'll spare you.
>>
>>   [''Adjust the L2 level in cache grind and check out the miss rate to
>> figure out how much L2 would be good.  As indicated on the mailing list,
>> I favor siphoning a little from RAM and making it BIOS adjustable...'']
>>
>> The point is, this kind of performance hit isn't going to be fixed by
>> software; you CAN make improvements, but they'll be on orders of much
>> lower magnitude.  Taking a cup of water out of a swimming pool for
>> example....
>
> New description:
>
> The first revision of machines is going to be based on the Geode GX.
> Reviewing its data sheet, there are a few numbers that need attention:
>
> * Memory controller on the CPU[[BR]]
> * 32KiB L1 cache[[BR]]
> ** 16KiB I1[[BR]]
> ** 16KiB D1[[BR]]
> ** 4-way Set Associative[[BR]]
> ** 1 Cycle Cache hits[[BR]]
> ** 2 Cycle Cache hits if not using the same way[[BR]]
> ** '''25 Cycle''' Cache misses (give or take a few depending on the exact
> conditions)[[BR]]
> * No L2 Cache[[BR]]
> * 80-Entry TLB[[BR]]
> ** 8 L1 ITLB[[BR]]
> ** 8 L1 DTLB[[BR]]
> ** 64 L2 TLB[[BR]]
>
> To simulate cache, you can use the following cachegrind line:
>
>   ''valgrind --tool=cachegrind --I1=16384,4,32 --D1=16384,4,32
> --L2=64,2,32 [program]''
>
> Ignore L2, it doesn't exist on the Geode GX.  Cachegrind demands it be set
> valid.
>
> A simulation of Rhythmbox shows a 1.2% overall cache miss rate.  Multiply
> this by 25 cycles and that's a 33.2% slowdown; multitasking will give you
> another 0.7% slowdown give or take a little bit but this is negligible.
>
> The folks in ##electronics on Freenode seemed to be under the impression
> that 25 cycle cache miss penalties indicate a "crippled" CPU and that this
> thing is "dumpster-bait."  I'm no EE so I'll have to go with what they
> came up with.
>
> Point being, we should look at moving to a new CPU in the next revision,
> if possible.  Another choice is to try to get AMD to redesign the memory
> controller to find some L2 somewhere at only a few cycles per cache miss;
> but this is probably not really feasible (modify the hardware?  Uh..).
> I've had thoughts along this vein but I'm not an EE, and they're already
> splattered on the mailing list so I'll spare you.
>
>   [''Adjust the L2 level in cache grind and check out the miss rate to
> figure out how much L2 would be good.  As indicated on the mailing list, I
> favor siphoning a little from RAM and making it BIOS adjustable...'']
>
> The point is, this kind of performance hit isn't going to be fixed by
> software; you CAN make improvements, but they'll be on orders of much
> lower magnitude.  Taking a cup of water out of a swimming pool for
> example....
>
> -- 
> Ticket URL: <http://dev.laptop.org/ticket/125#comment:1>
> One Laptop Per Child <http://laptop.org/>
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
>