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

[Zarro Boogs per Child]

#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/>