■ THIS WEEK (9/1~9/7)
□ Booksim
i tested the same process with randperm traffic, but the result is almost similar.
now i am trying to print out the hot spot latency and other latency, and compare them.
□ Phoenix
* degradation of map time
i thought that the reason of degradation was the disk io time.
for shared memory system, cache miss rate increases when # of processors increases.
* test with the sunT2 stats
using 8KB private L1 data cache for each processor and 4MB shared L2 cache.
the speedup degradation appears after 16 cores.
and the map time usually dominates the whole processing time.
* test with the perfect cache
using 100MB private L1 data cache and 400MB shared L2 cache. (other configs are the same as sunT2)
the L1 read hit rate of each processor is almost 99% (it's not 100% because of the cold misses)
but the write hit rate slightly decreases as the number of the processors increases.
the overall performance of the processors increases but the pattern of the speedup is the same.
there still exists the degradation after 16 cores and the map time is a dominative part.
i think that i need to test other application and compare the results.
and i try to focus on working set size of each application.
'Lab.work' 카테고리의 다른 글
| Weekly report (9/28) (0) | 2009.09.29 |
|---|---|
| Progress Report (9/15) (0) | 2009.09.15 |
| PROGRESS REPORT (9/1) (0) | 2009.09.01 |
| PROGRESS REPORT (8/26) (0) | 2009.08.26 |
| PROGRESS REPORT (8/17) (0) | 2009.08.17 |
민둥
phoenix_timeval.pdf