core factor

После прочтения core factors table каждому разумному человеку становиться понятно, что Oracle стоит покупать только на SPARC T3 процессор из-за коэффициента 0.25. И все крики что не не все процессоры одинаково полезны сталкиваются с "а докажите !". Доказать, это кстати интересное упражнение -).

Начну издалека: во первых, лично я ненавижу разговоры о БД на серии T из-за того что они ...были сделаны для Web серверов, и только потом появилась (я уверен что в маркетинге) идея запихивать их под БД тоже. Собственный тест на еще на T1 показал мне что так оно и есть. По моему убеждению Intel Xeon порвет T2/T3 под нагрузкой БД. 4 сокета максимум в T3 тоже не добавляют оптимизма. Борорься с Intel на 4-х сокетах сейчас очень не просто даже настоящим RISC. Что не вовсе не умоляет иженерных достоинств T3, в том числе весьма достойной виртуализации. Во-вторых, мне кажется странным, что Oracle решил вот так просто отдавать что-то дешевле. Не верю, что за счет весьма стабильного бизнеса СУБД решили поднимать производство T3. Я хочу показать, что причина тут в другом.
Все, пора показать данные:



Все конечно знаю про spec.org. Я взял вот такой тест:

SPARC T3-1, 16 core, Peak Result - 166
Sun Fire X2270 M2 (Intel Xeon X5675 3.06 GHz), 12 core, Peak Result - 386

Очень грубо, не придираясь - T3 дает 200, Intel Xeon - 400 - следовательно коэффициент и должен отличаться между ними в 2 раза. Что мы и видим в табличке core factor tables. Для меня все логично.
Sun SPARC Enterprise M9000, 128 core, Peak Result 1290. Вы конечно не поверите, но 1290/166 = 7.7, а 128/16 ~ 8. В это же время, 1290/386 = 3.3 а 128/12 = 10.6, и тут даже коэффициент 0,5 для Sparc смотрелся бы очень не плохо (а стоит 0.75)

Есть правда такой результат:
Fujitsu SPARC Enterprise M9000, 128 core, Peak Result 1450, что улучшает ситуацию для Sparc.


IBM Power 780 (3.86 GHz, 16 core), Peak Result - 652. Пробуем сравнить с Xeon - 386/662 = 0,58 (но помним что у Xeon было 12 ядер против 16)

IBM Power 795 (4.0 GHz, 256 core), Peak Result - 11200, Пробуем сравнить c Xeon, учитывая что ядер было 12 у Xeon - (386 * 256 / 12) = 8234 / 11200 = 0,75 ( а стоит 1, как вы помните)

Мое заключение - очень тяжелая была задача у того кто составлял core factor tables, поскольку разные системы, частоты и сделать коэффициентами сложными дробями также было нельзя. Я не вижу никакого маркетинга/попыток каким-то образом воздействовать на конкурентов в этой таблице, а просто огрубленный расчет производительности процессора. Причем понятно, что я взял один из тестов spec.org, можно было взять и другой, и не только spec.org. Все разумно (с точки зрения Oracle) - берешь более быстрые процессоры - значит их берешь меньше - значит нужно платить Oracle'у больше.

Ну хорошо, ведь действительно а что я прицепился к SPECint - какое он отношение имеет к производительности систем на Oracle ? Да, весьма опосредованное, надо сказать. Даже в применении к логическим чтениям, частота процессора не так важна, как скажем работа с памятью. На Solaris 8 (если я правильно помню) был баг (быстро исправленный) который приводил к медленной работе с памятью. И тут даже дело было скорее в ОС, чем в процессоре. Есть известный тест Jonathan Lewis, который мне нравиться больше остальных, но даже с ним я не возьмусь доказывать что это имеет прямое отношение к работе OEBS, скажем.

Есть интересный подход компании IDEAS International, которая говорит, что они берут сразу несколько разных тестов (в том числе spec, tpc.org и т.д.) , далее выводят среднее между ними таким образом снижая возможность опротестовать их результат. К большому сожалению, результаты они выдают за деньги и запрещают публиковать. Я видел их отчеты, они сравнивают не процессоры, а системы, и не только производительность но и также например, энергопотребление. Уверяю вас, если бы Oracle базировался на метриках IDEAS, коэффициенты в core factor table были бы еще более "злые" -)
Насколько я понимаю сейчас у Вас есть возможность запрашивать у вендоров сравнение с конкурентами именно по метрикам IDEAS. Это интересно посмотреть, рекомендую -)