x86 vs ARM: сложность инструкций

Например, спрашиваешь у библиотеки: «а сколько взять памяти чтоб не промазывать мимо кэша?» и она тебе рассказывает.

man sysconf, getconf -a

LEVEL2_CACHE_SIZE, LEVEL2_CACHE_ASSOC, LEVEL2_CACHE_LINESIZE и прочие

Или вообще - даешь инструменту алгоритм (на инструментовском языке), а он тебе рассказывает как его красиво сделать.

http://code.entropywave.com/documentation/orc/orc-concepts.html

man sysconf, getconf -a

Для начинающего оптимизатора хотелось бы, натурально, библиотеку. Чтоб моск отдыхал, чтоб платформ побольше и документация красивая :)

Но вообще я пока остыл, в такие тонкие оптимизации нужно как-то уж слишком углубляться, там бездны какие-то.

http://code.entropywave.com/documentation/orc/orc-concepts.html

Ага, спасибо, посмотрю. Но он как-то не очень современно выглядит - GPU я не увидел, SSE даже второго нет?

там ничего подобного сделать нельзя, как правило.

Мы говорим о готовых продуктах под ключ или о разработке таких продуктов?

Всё равно кто-то пишет это ПО. Вот эти люди могут заложить в систему нужные свойства. Только тут конфликт интересов. Исполнителю хочется «направлять усилия на то, чтобы бизнес приносил больше выручки». У заказчика же стремление сокращать издержки.

ведь не просто так стоит своих денег

По мне так в большинстве случаев не стоит :(. Как минимум пока счёт не идёт на сотни гигов данных. Вообще, тут даже не объём важен, а то что ты с этим делаешь. На посгресе тоже не вопрос сделать многотеррабайтные базы даже в пределах одной тачки (пруфы в гугле). И, конечно, возможности и суппорт будут не те что в оракле. Но тут надо определиться что нужно.

К чему это я. Абстрактно рассуждать какое решение лучше глупо. Нужна задача, нужны как минимум по одной рабочей реализации и нужны данные по ним чтобы сравнить в лоб. Плюс компетенция в этих областях.

А то можно долго хвастаться, например, «а моя СУБД держит триггеры на C». Но когда я столкнулся с сишными триггерами в боевом продукте мне захотелось убивать. Там где было достаточно key-value БД воткнули ппц который программисты за 9 или 10 месяцев так и не смогли нормально отрефакторить. И так со многими фичами. У меня знакомый на стажировке работал программистом БД банка (и такое бывает) в одной братской республике, так там такой индусокод был... Не удивительно что нужны тачки размером с комнату чтобы функции over 64k строк|кб (уже не помню) работали. Доходило до маразма, функцию били на две потому что возможности субд не позволяли создавать одиночные функции такого объёма.

Более того, на однопоточных тестах вообще всё ужасно:
http://www.mysqlperformanceblog.com/2008/05/01/t2000-cpu-performance-watch-out/

Это, конечно, круто - в 2013 году приводить ссылку на заметку из 2008 про тестирование производительности системы, выпущенной еще в 2005 и построенный на базе первого поколения Ниагар (UltaSPARC T1). Начиная с T4 произошли очень существенные изменения в тактовой частоте тэшек, внутренней архитектуре и производительности. А сейчас уже T5 на дворе.

Именно - FSM, те самые, которые реализуются в интегральных схемах, мало общего имеют с теоретической сранью.

Смешно ты пытаешься прикрыть своё невежество.

Та же машина Тьюринга с точки зрения электронщика это простой FSM + бесконечная лента.

А с точки зрения не-электронщика? :)

В реальности это выглядит так: Есть софтовый продукт за $100500 тыщ. Для твоих нужд чтобы использовать этот продукт надо ещё железку за $100500 тыщ. Ты говоришь, а давайте, я вместо этой железки использую кластер x86 за $100500/2. Вендор говорит - ради бога, но нашему продукту для работы на кластере нужно доработки, стоимость доработок будет к основной сумме ещё $100500/2, и полгода времени. Поэтому пока что железки за $100500 всё ещё продаются, не смотря на наличие более дешёвых и производительных на сокет x86 железок.

Пока что я не вижу альтернативы oracle или ibm в промышленных БД mission critical, в тех же телекоме и банках. Если есть истории успеха x86 - буду очень рад познакомиться, ибо сам сейчас вынужден оную писать...

Ты, тупица, влез в тему про проектирование электроники. Вот и вали отсюда, свинья некомпетентная.

тестирование производительности системы, выпущенной еще в 2005

Речь шла об архитектуре. Я показал что не стоит слепо верить в архитектуру и рекламу вендора.

А сейчас уже T5 на дворе.

Отлично, покажешь нам независимые тесты T5?

ибо сам сейчас вынужден оную писать...

вот ты нам и расскажешь :)

Да вот очень не хотелось бы. К сожалению, найти новую работу не так просто оказалось...

Речь шла об архитектуре.

А по-моему речь шла о неких многопоточных тестах MySQL/PostgreSQL, на которых Ксеоны якобы отодрали Ниагары, которые почему-то не удалось отыскать. Зато удалось отыскать нечто другое :)

Я показал что не стоит слепо верить в архитектуру и рекламу вендора.

Ага, приведя в качестве примера ссылку на тест, который показывает что первая Ниагара не чемпион в однопоточной производительности. Только знаешь в чем проблема? В том что Сан и не скрывал этой особенности архитектуры, говорил о ней на каждом углу. Ы?

К тому же, архитектура с тех пор претерпела весьма существенные изменения.

Так что ты выглядишь не очень убедительно с таким аргументом.

Отлично, покажешь нам независимые тесты T5?

Критерий независимости в студию, пожалуйста. Тебе Хокум вон приводил ссылку на TPC-C. Чем тебя не устраивает? Там достаточно строгие правила проведения теста, результаты к тому же проходят аудит. Так что абы что не опубликуешь. Другое дело, что сам TPC-C несколько далек от сегодняшней реальности. Ну так помимо него и другие результаты есть.

Или для тебя независимые - это те, которые провел Петя Зайцев? Тогда придется подождать еще немного, годика два-три :)

Появятся результаты не от Оракла, никуда не денутся. Сколько времени прошло с момента начала продаж? Полгода где-то. Так что меня ничуть не удивляет, что с тестами не от Оракла пока не густо.

В том что Сан и не скрывал этой особенности архитектуры, говорил о ней на каждом углу. Ы?

Были и другие тесты (pg, mysql). Но за давностью лет они тупо исчезли из моей выдачи гугла. там xeon отодрал ниагару. Но у меня нет этих данных. Поэтому, за неименем лучшего, предлагаю судить по тому что есть — скорость однопоточного теста интерполируем на кол-во потоков.

Критерий независимости в студию, пожалуйста.

1) сделано не сотрудниками оракла

2) не проходило через их одобрение

Чем тебя не устраивает?

1) Я хочу посмотреть как оно, например, крутит постгрес

2) Это только один тест

Напомню, было утверждение что архитектуры power, mips итп гораздо лучше справляются с OLTP. На конкретный вопрос что именно там заточено я так и не получил конкретного ответа. Я вижу бенчмарки этого TPC-C, но мне это совершенно не интересно. Я хочу пруфов что x86 не сможет показать аналогичные или лучшие результаты.

Сколько времени прошло с момента начала продаж? Полгода где-то

Для сравнения, под интел тесты вылезают раньше офицально презентации. А тут, похоже, увидим тесты когда оно окончательно сдохнет.

Я бы сказал что хорошее железо прятать не будут, но зная закидоны оракла всё что угодно может быть.

А, впрочем, вот нашлось:

http://tweakers.net/reviews/649/8/database-test-sun-ultrasparc-t1-vs-amd-opte...

Поэтому, за неименем лучшего, предлагаю судить по тому что есть — скорость однопоточного теста интерполируем на кол-во потоков.

Взяв за основу данные теста 2008 года с непонятной методологией с использованием железа, которое уже много лет как не производится. Отлично! При всей оторванности TPC-C от сегодняшних реалий я уж лучше буду отталкиваться от него.

Ты ведь сам говорил, что главный тормоз - это память. Так вот если пользоваться таким подходом, то не получится учесть все те особенности архитектуры даже первой Ниагары, которые, несмотря даже на мизерные кэши, позволяют эффективно «прятать» задержки памяти.

Критерий независимости в студию, пожалуйста.

1) сделано не сотрудниками оракла
2) не проходило через их одобрение

А в чем проблема с сотрудниками Оракла? Или это что-то личное? А если тест будут проводить сотрудники IBM, Bull, Fujitsu или Cisco, это резко сделает тест независимым?

Я вижу бенчмарки этого TPC-C, но мне это совершенно не интересно

А жаль. Тут ведь смысл то в чем - есть стандартный понятно работающий тест, со стандартной методологией проведения этого теста. Внедорожниках старается получить наилучший результат, который затем обязательно получается в присутствии представителей TPC, следящих за тем, чтобы все было чисто.

Я хочу посмотреть как оно, например, крутит постгрес

Понятное желание. Посто тому же Ораклу какой интерес заниматься тестированием постгреса, который он не продает? Так что остается или ждать, пока кто-то попробует и поделится результатами, или действовать самому.

Я хочу пруфов что x86 не сможет показать аналогичные или лучшие результаты.

Ты хочешь невозможного, ибо технологии не стоят на месте.

Для сравнения, под интел тесты вылезают раньше офицально презентации.

Результаты TPC-C (да и других тестов) тоже очень часто выходят за несколько месяцев до того, как станет доступна соответствующая конфигурация. Например, это на сегодня справедливо для результата на T5-8.

Я бы сказал что хорошее железо прятать не будут, но зная закидоны оракла всё что угодно может быть.

Кмк, у тебя что-то личное по ношению к Ораклу :)

А в чем проблема с сотрудниками Оракла?

Они запрещают выкладывать тесты без согласования с ними. Это как бы намекает. Если ты не понимаешь что в этом плохого то можешь дальше не писать, мы не найдём общего языка.

Результаты TPC-C (да и других тестов) тоже очень часто выходят за несколько месяцев до того, как станет доступна соответствующая конфигурация

Угу, тесты от самого оракла. Тебе самому не смешно?

особенности архитектуры даже первой Ниагары, которые, несмотря даже на мизерные кэши, позволяют эффективно «прятать» задержки памяти.

Это пустые словамаркетинг. Как конкретно ты предлагаешь «прятать» задержки? Не стесняйся технических терминов, я в этом немного понимаю. А ещё лучше тесты которые это покажут в сравнении с x86.

Ты хочешь невозможного, ибо технологии не стоят на месте.

1) Я хочу услышать подтверждение тому что было сказано выше. Если это нельзя подтвердить то и говорить этого не стоит.

2) что мешает сравнить текущие технологии?

есть стандартный понятно работающий тест, со стандартной методологией проведения этого теста.

У нас все базы в мире одинаковые и под одинаковой нагрузкой?

А, впрочем, вот нашлось:

Отлично, это еще старше.. Подумаешь, всего-то 7 лет прошло. Результаты ведь не устаревают и их с легкостью можно экстраполировать на день сегодняшний...

И ты говорил про Ксеоны, а тут вроде как оптероны :) ну да ладно, я это так.

Какова была методика проведения теста? Сколько клиентов создавало нагрузку? Не уперлись ли мы в ограничения клиента(ов), создающих нагрузку? Не один раз приходилось видеть картинки, похожие на графики постгреса, а в результате оказывалось, что дело не в бобине, а в клиенте. И если клиентов добавлялось, то Ниагара продолжала еще какое-то время расти, а быстрые x86 ядра начинали резко загибаться.

И потом, если сравнить результаты с одинаковым количеством чипов (то есть взять график для 2-х ядер оптерона), то окажется, что Ниагара таки прилично ( в полтора раза) сделала оптерон, у которого частота в два раза больше.

Вторая же картинка демонстрирует наглядным образом, как же дерьмово были сделаны блокировки в MySQL в 2006 году :)

Отлично, это еще старше.. Подумаешь, всего-то 7 лет прошло.

Ну так приведи свежие результаты - это будет всяко продуктивнее, чем выяснение, есть ли у true_admin что-то личное против Оракула.

Они запрещают выкладывать тесты без согласования с ними. Это как бы намекает. Если ты не понимаешь что в этом плохого то можешь дальше не писать, мы не найдём общего языка.

Можно подумать, они такие одни на всем белом свете. Точно так же делает еще и куча других. Потом, ты так говоришь, как будто это ужасно плохо. Но у каждой медали есть две стороны, как известно. Конечно, такое требование ограничивает свободу делать все, что угодно. С другой стороны, это ставит некоторый барьер для публикации всяких бредовых результатов непонятных тестов, проведенных по непонятной методике и сравнивающих яблоки с апельсинами. Впрочем, переубеждать я тебя не собираюсь.

Угу, тесты от самого оракла. Тебе самому не смешно?

Мне - нет. Помимо результатов от Оракла, там есть результаты от IBM, Bull, Fujitsu и других. Суть в том, что это проверенные и воспроизводимые результаты.

Это пустые словамаркетинг. Как конкретно ты предлагаешь «прятать» задержки? Не стесняйся технических терминов, я в этом немного понимаю.

Ну если понимаешь, иди почитай про CMT.

А ещё лучше тесты которые это покажут в сравнении с x86.

См. предыдущий пост с ответом на результаты от 2006 года.

У нас все базы в мире одинаковые и под одинаковой нагрузкой

Мы вроде про сравнение железом говорим, а не про сравнение нагрузок. Не надо соскакивать с темы.

было бы интересно оценить именно эффективность декодера команд без влияния кэша и прочих хитростей вроде OoOE

Ну так приведи свежие результаты - это будет всяко продуктивнее, чем выяснение, есть ли у true_admin что-то личное против Оракула.

Меня вполне устраивают имеющиеся свежие результаты TPC-C, TPC-H и так далее.

Вот и покажи свежие тесты раз старые не нравятся. Победа в одном тесте не говорит о беззаговорочном лидерстве во всех сценариях.

Кстати, давайте взглянем на top-5 того tpc-c теста.

Древняя суся на интеле 2011 года показывает 3млн запросов при цене в 1.7млн баксов (неплохо за 4 процессора).

Новейший SPARC T5-8 Server с 8-ю процами показывает 8.5млн запросов и стоит 4.6млн баксов.

Что-то я не вижу особых различий ни в цене, ни в производительности. Плюс не факт что там всё в процы упирается, верно?

:)

http://www.sap.com/solutions/benchmark/sd3tier.epx?num=200

иди почитай про CMT

CMT

Это что такое? Не SMT ли? Если да то у меня для тебя плохие новости, интел уже давно это во всю использует.

это ставит некоторый барьер для публикации всяких бредовых результатов непонятных тестов

Бредовая отмазка.

Это бенчмарк SAP, а не железа.

Это что такое? Не SMT ли?

Ну вот, а ты говорил, что понимаешь. Нет, это не SMT. В первой Ниагаре его не было. Это именно CMT. Тебя в гугле столь забанили?

Если да то у меня для тебя плохие новости, интел уже давно это во всю использует.

Не интел один. И IBM использует, и Оракл в более современных тэшках.

А тебе надо чистую синтетику? Вэлком ту линпак, со лонг :)

А тебе надо чистую синтетику?

Мне надо процессоры и не надо SAP.

со лонг :)

Фейрвелл.

Это именно CMT. Тебя в гугле столь забанили?

Гугл выдавал всякую фигню аля Country Music Television. Но я нашёл что ты имеешь в виду. Это всё давно есть у AMD и интела — исполнительные блоки шарятся между ядрами. Внутри сидит планировщик который решает что где исполнять. У AMD четыре «ядра» (или лучше сказать OS visible CPU cores), у интеля только два ядра, но с HT.

Мне надо процессоры и не надо SAP.

Ты их по зернистости кремния сравнивать хочешь?

Ты их по зернистости кремния сравнивать хочешь?

сравнивать производительность с использованием 100500 прослоек от конкретной реализации JVM до ОС это ИМХО не совсем корректно.

Вот и покажи свежие тесты раз старые не нравятся. Победа в одном тесте не говорит о беззаговорочном лидерстве во всех сценариях.

Не надо мне приписывать то, что я не говорил. Меня вполне устраивают имеющиеся свежие результаты. Я не делал утверждения о безоговорочном лидерстве того или иного профессора во всех сценариях.

Я всего лишь пытаюсь донести до тебя простую мысль, что ссылки на результаты 5-7 летней давности выглядят не очень убедительно, ибо с тех пор технологии прошли большой путь в своем развитии.

Кстати, давайте взглянем на top-5 того tpc-c теста.

Давай. Какие результаты будем смотреть - кластерные или нет?

Древняя суся на интеле 2011 года показывает 3млн запросов при цене в 1.7млн баксов (неплохо за 4 процессора).
Новейший SPARC T5-8 Server с 8-ю процами показывает 8.5млн запросов и стоит 4.6млн баксов.
Что-то я не вижу особых различий ни в цене, ни в производительности.

Не видишь разницы в 5 миллионов tpmC?

Потом это не очень удачные конфигурации для сравнения. Лучше сравнить T5-8 и X2-8, ибо они более-менее похожи и по цене, и по конфигурации - 8 процессоров, 4тера памяти, да и по возрасту не очень сильно отличаются. Плюс Оракл в обоих случаях :)

И что мы видим?

Это бенчмарк SAP, а не железа

Ну ты даешь. Это очень популярная и достаточно точная метрика для сайзинга конфигураций железа под SAP.

Это очень популярная и достаточно точная метрика для сайзинга конфигураций железа под SAP.

Это метрика для оценки покупки. Мне это неинтересно.

Ну ты даешь. Это очень популярная и достаточно точная метрика для сайзинга конфигураций железа под SAP.

знаем, плаваем по самые уши в этом ынтырпрайзе. недавно даже был срачик по поводу процессора т.к. у нас были более новые процы но с меньшей частотой чем было заявлено в спеках. и кстати производитель клал болт на бенчмарки и требовал что бы частота была не ниже заявленной.

Но я нашёл что ты имеешь в виду.

Я не знаю, что ты там нашел, но я имею ввиду вот это. В ядрах первой Ниагары использовался только CMT, ну и на уровне чипа CMP, ибо было до 8 ядер.

Это всё давно есть у AMD и интела — исполнительные блоки шарятся между ядрами. Внутри сидит планировщик который решает что где исполнять. У AMD четыре «ядра» (или лучше сказать OS visible CPU cores), у интеля только два ядра, но с HT.

Я где-то говорил, что нету? Есть, конечно. Но везде свое со своими шахматами и поэтессами :)

В Ниагарах начиная со второй появилась поддержка SMT2, а в новом ядре S3 (это T4/T5 и M5/M6) добавилось еще и Out of Order Execution.

Так что сравнение результатов TPC-C для T5-8 и X2-8 достаточно показательно.

Нуу, скажем так, убедил что для этого теста имеет смысл иметь множество мелких ядер.

Так же убедился в том что если запустить это на кластере то будет на порядок быстрее и дешевле. Просто потому что tpc-c это вещь которая практически бесконечно паралелится.

Это метрика для оценки покупки. Мне это неинтересно.

Конечно, сферических коней в вакууме сравнивать интереснее :)

SMT <...> интел уже давно это во всю использует.

У intel'а же не больше двух нитей? На двух нитях задержки не скроются. В доках про CUDA были наглядные картинки. Там десятки нитей, и сокрытие задержек вполне реально.

Так же убедился в том что если запустить это на кластере то будет на порядок быстрее и дешевле

Я бы не был столь категоричен, ибо если посмотреть на ближайшие к T5-8 кластерные результаты сверху и снизу, ни о каком «на порядок» говорить не получается :) хотя это и не вполне корректные сравнения.

Ну так а что, богомипсы считать? Они оторваны от реальной жизни куда больше, чем Керенский от волжских бурлаков.

Синтетики, кстати, на самом деле хватает, вплоть до того, что можно самому позапускать вдоволь, если матчасть есть. Даже фороникс пытается отойти от попугаев, слишком уж много нынче ньюансов стало. А когда-то в детстве мерились надписями движковых кубиков на машинах отцов и частотами камешков на сегментных индикаторах с нажатой кнопкой Турбо. Пора уже понять, что в отрыве от приложений производительности нет. Ровно так же, как нет в реальной жизни задач не учитывающих цену решения. Реализм, консерватизм и прагматизм - так учит нас, в конце концов, новый классик стабильности, и не нам с ним спорить.

сферических коней в вакууме сравнивать интереснее :)

Ты и Хокум сравниваете 2-процессорный HP Proliant с 8-процессорным IBM Power - что ж, у каждого свои кони.

Ты что-то путаешь. Я сравниваю 8-ми процессорные T5-8 и X2-8.

Ты что-то путаешь

Нет. В отличие от тебя, я прошел по ссылке на «точную метрику для сайзинга конфигураций железа под SAP».

У intel'а же не больше двух нитей?

Два ядра по две нити шарят ресурсы. Отсюда я делаю что четыре нити.

сокрытие задержек вполне реально.

У оперативной памяти есть предельная скорость работы. Самое большое ограничение это скорость «позиционирования» (ras-тайминг). На большинстве тяжёлых нагрузок это является слабым местом. Так вот, скорость выполнения ограничена этим фактором. Всякие out-of-order execution «всего лишь» позволяют процу работать до тех пор пока в кэшах есть для этого данные. Но это не позволит работать быстрее чем работает оперативная память.

На двух нитях задержки не скроются.

Скажем так, при вшестеро меньшем кол-ве ядер интел отстал всего в 1.7 раза от мощного спарковского сервера. При том что у интел частота 2.4GHz, а у spark 3.6 . Поэтому я бы не сказал что это плохо работает. Но теперь я начинаю понимать что значит «архитектура заточена под OLTP». Другое дело что один бенчмарк не репрезентативен. Я почитал его описание, это интересно, но в реальной жизни, кмк, приложения гораздо более серьёзные чем TPC-C.

Ты не понял фишки. Есть результаты в близких конфигурациях:

http://www.sap.com/solutions/benchmark/sd2tier.epx?num=200

Суть-то в другом, когда надо что-то большое и быстрое, то тут x86 сливает. То же самое происходит, когда надо что-то отказоустойчивое и надёжное.

Зато, когда надо что-то дешёвое, тут x86 уделает врагов как тузег грелку.

То есть, каждому своё, у каждого своя ниша и свой рынок.

А рядом кто-то пытается всерьёз сравнивать армы и серверные процессоры...

Я бы не был столь категоричен

Я сужу со своей колокольни. Я знать ничего не знаю об всех этих машинах и делаю выводы только потому что вы мне сами накидали. Естественно что в моём случае глупо утверждать что я хорошо разбираюсь в топике.

Отсюда мне и хотелось посмотреть на другие бенчмарки. Мне сама идея «давайте возьмём некий бенчмарк и посмотрим что он выдаст» кажется дикой. Я отталкиваюсь от конечных целей и смотрю какие есть подходы для их решения. Поэтому мне бы хотелось самому задизайнить то что делает TPC-C и сравнить свой подход с ихним. А то вдруг там что-то делается через задницу? Но этого не будет т.к. мне SQL не интересен.

Впрочем, в октябре у меня как раз будет собеседование по проектированию больших ЦОД, меньше чем через месяц я узнаю на сколько я далёк от истины.

Пора уже понять, что в отрыве от приложений производительности нет.

особенно интересно это звучит в контексте того что тырпрайз собран строго под x86 а в требованиях amd64 хост. я конечно порывался провести тестирования сколько накладных расходов на переключение из long в legacy и обратно.

Нет. В отличие от тебя, я прошел по ссылке на «точную метрику для сайзинга конфигураций железа под SAP».

Ты делаешь слишком много предположений - что я не ходил по ссылке, что я сравниваю две верхних конфигурации в списке.

Ты делаешь слишком много предположений - что я [...]

Ахпрости, ты такой загадочный и непостижимый.

Я не совсем понял, есть возражения относительно того что такое производительность железа и в чём её суть для бизнеса? :)