Какова Стоимость Неудачного обращения в кэш L1?
Обходной путь для Android 4.x:
Я нашел AutoResizeTextView, и он отлично работает на моем эмуляторе Android 2.1. Я так это любил. Но, к сожалению, это не удалось на моем собственном мобильном телефоне 4.0.4 и эмуляторе 4.1. После попытки я обнаружил, что это можно легко решить, добавив следующие атрибуты в класс AutoResizeTextView в xml:
android: ellipsize = "none"
android: singleLine = "true"
С двумя вышеупомянутыми строками AutoResizeTextView отлично работает на моем 2.1 & amp; Эмуляторы 4.1 и мой собственный мобильный телефон 4.0.4.
Надеюсь, это поможет тебе. : -)
6 ответов
While I can't offer an answer to whether or not the numbers make sense (I'm not well versed in the cache latencies, but for the record ~10 cycle L1 cache misses sounds about right), I can offer you Cachegrind as a tool to help you actually see the differences in cache performance between your 2 tests.
Cachegrind is a Valgrind tool (the framework that powers the always-lovely memcheck) which profiles cache and branch hits/misses. It will give you an idea of how many cache hits/misses you are actually getting in your program.
Some numbers for a 3.4GHz P4 from a Lavalys Everest run:
- the L1 dcache is 8K (cacheline 64 bytes)
- L2 is 512K
- L1 fetch latency is 2 cycles
- L2 fetch latency is about double what you are seeing: 20 cycles
More here: http://www.freeweb.hu/instlatx64/GenuineIntel0000F25_P4_Gallatin_MemLatX86.txt
(for the latencies look at the bottom of the page)
3.2ns for an L1 cache miss is entirely plausible. For comparison, on one particular modern multicore PowerPC CPU, an L1 miss is about 40 cycles -- a little longer for some cores than others, depending on how far they are from the L2 cache (yes really). An L2 miss is at least 600 cycles.
Cache is everything in performance; CPUs are so much faster than memory now that you're really almost optimizing for the memory bus instead of the core.
Трудно сказать что-либо наверняка без дополнительного тестирования. , но, по моему опыту, эта разница определенно может быть отнесена к кеш-памяти L1 и / или L2 ЦП, особенно в сценарии с произвольным доступом. Вы, вероятно, могли бы усугубить ситуацию, убедившись, что каждый доступ находится на некотором минимальном расстоянии от последнего.
Ну да, похоже, это в основном промахи в кэше L1.
10 циклов для промаха кэша L1 звучат вполне разумно, вероятно, немного не в меру.
Чтение из ОЗУ займет порядка 100 или даже 1000 (я слишком устал, чтобы пытаться делать математику прямо сейчас;)) циклов, так что это все еще большая победа над этим.
The easiest thing to do is to take a scaled photograph of the target cpu and physically measure the distance between the core and the level-1 cache. Multiply that distance by the distance electrons can travel per second in copper. Then figure out how many clock-cycles you can have in that same time. That's the minimum number of cpu cycles you'll waste on a L1 cache miss.
You can also work out the minimum cost of fetching data from RAM in terms of the number of CPU cycles wasted in the same way. You might be amazed.
Notice that what you're seeing here definitely has something to do with cache-misses (be it L1 or both L1 and L2) because normally the cache will pull out data on the same cache line once you access anything on that cache-line requiring less trips to RAM.
However, what you're probably also seeing is the fact that RAM (even though it's calls Random Access Memory) still preferres linear memory access.