http://pc.watch.impress.co.jp/docs/2008/0811/kaigai458.htm
Cell B.E.と似て非なるLarrabeeの内部構造
https://www-903.ibm.com/kr/event/download/200806_344_green/d_07.pdf
COMIC: A Coherent Shared Memory Interface for Cell BE
檢討起來的話就會變成10core好像是筆誤….XD
假設總計都是4MB L2 cache的話，10core只有2560KB，由於後面有提到每個TMU有32KB texture cache，這不就變成有48個TMU….
何況內文也有提到，512bit雙向ringbus會在超過16core的時候再加第二組bus，所以32core的話就會變成1024bit雙向bus，既然重複提到16core這個數字，那麼表格裡面的10core就有可能是筆誤了。XD
只是vector throughtput(160 per clock)也是支持10core的另一個數字就是了….
總之這張表看來不能太在意。_A_
不過文章裡面另外有提到幾點要注意的：
1. 每個core有32KB texture cache，這可能是放在core上、或者是TMU這邊；針對每個core可以提供32KB，而且這個空間是與core的256KB L2 cache分開。
2. ring bus是在奇偶數clock各送一個方向的資料，以簡化設計，在ring bus上也沒有storage，cache的資料同步性則會以硬體來維持。
3. 論文內的”fiber”指的是software manage thread，這等於是用軟體排程來”預測延遲”、透過軟體使得L2 cache的空間可以發揮目前GPU常見的hardware threading般的作用。CPU core的4 thread SMT則是用來應付L1 miss、存取L2時的不固定延遲。此外，cache透過指令可以提供類似scratchpad memory般的使用法；話說Nehalem的L2也是256KB….
4. Larrabee預設會有TMU而沒有ROP，這邊的ROP指的是rasterization、Z/stencil、alpha blending。因為ROP的規模很難估計是否適當，用硬體的話又會造成靈活度的限制，所以全以軟體執行，當然前提是可以提供適當性能。在架構圖上的fix function則是對應到display function logic等固定功能線路，並不是ROP的部分。由於Larrabee在TMU這部分已經有電晶體投資，現在Larrabee和GPU主要的性能差，就在延遲吸收、與ROP軟體化之後的性能差距。
結論：intel的自信全在cache設計上。