Это я понимаю, но я спрашивал про другой тип данных — xml структуру данных, представляющее собой сериализацию (в xml, json, yaml, toml, что-нибудь еще более модное) какой-то определенной иерархии объектов с полями и с вложенностью. Что предполагает немного другой сценарий использования, и больший, скажем так, «порядок».
Хотелось бы посмотреть именно на «enterprise xml» с адской вложенностью, чтобы понять где наши ограничения будут упираться в пределы движка.
И, laphroaig, также присоединяюсь к высказанному выше приглашению на фестиваль РИТ++ в рамках которого у нас будет проходить конференция CachéConf. Я вам, как бывшему пользователю Caché, даже могу дать скидочный код на весь фестиваль, про который мы писали здесь. На следующей неделе мы увеличим цены на билеты, т.ч. торопитесь — забронируйте билет по текущей цене! Обращайтесь!
При внутреннем тестировании приложения, когда в игру вовлечены несколько вендоров (в данном случае 4: Epic Systems, InterSystems, Intel, Vmware) публикация таких подробных деталей конфигураций часто невозможна. Даже если пара вендоров даст добро на публикацию, любой другой легко может наложить вето. И в итоге получается такая, максимально обтекаемая форма, и график без цифр. Извините, в данной ситуации более подробных данных мы опубликовать не можем.
Если бы речь была о публичном бенчмарке, типа SPECint, HPC-H, и т.п. то вендор обязан был бы публиковать все подробности конфигураций и скриптов. Но в данном случае это внутренний бенчмарк, созданный Epic в 2002 году и применяемый им все это время для определения потолка производительности системы. Детали раскрывать не могу (да и не знаю многого), но высокоуровневое описание почитал на страницах проекта.
Epic использует ECP для горизонтального масштабирования системы. [Вы, как бывший пользователь Caché, знаете что это такое, для других поясню — это Enterprise Caching Protocol, протокол для передачи данных на удаленные монтировки, со встроенной синхронизацией и когерентностью]
На тестовой системе Epic трафик внешних «пользователей» (в рамках тестирования, конечно, генерируемый) распределяется по «более чем 50» (на начало 2014 года) серверам приложений. Сразу заметим, что максимальное количество ядер на 1 сервере приложений дела не играет, всегда можно рядом поставить еще десяток. В итоге мы имеем, скажем, 3000 тысячи ядер, так или иначе распределенных на машины.
На момент начала проекта Epic заметил, что чтобы они ни делали, сколько бы серверов приложений не ставили, они получают потолок в 7миллионов GloRef в секунду на 2013.1. В лучшем случае получалось увеличение responce time до неприемлемых значений. В рамках работ по оптимизации в 2015.1 было сделано несколько улучшений, больших и малых, но пару стоит упомянуть:
улучшен алгоритм синхронизации на Linux/x64 системах (как собственно для примитивов синхронизации, так и, например, для write daemon);
и собственно ускорена работа всех элементов, вовлеченных в ECP взаимодействие, что позволило снять видимые ограничения в 7миллионов GloRef, и достичь 3-хкратного увеличения
В теории могли достичь и больших значений верхнего предела, но:
— этого значения более чем хватает на их прогнозируемые нагрузки на самых больших инсталляциях ;
— и у них закончились возможности тестовой лаборатории :)
Т.е. конечно же, эта история больше про все агрегатные улучшения в движке Caché 2015.1 (на всех поддерживаемых аппаратных платформах, а не только x64), чем про специфичные x64 оптимизации. Но и про оптимизации тоже.
Вы надеюсь понимаете, что речь идет о СУБД а не чисто счетной задаче из какого-нибудь набора SPECint? И количество и процессоров не самый определяющий фактор, и часто задачи, которые мы тут решаем скорее disk-bound, а не cpu-bound?
Самый большой вызов при проектировании алгоритмов на СУБД и/или сервере приложений (а Caché является одновременно и сервером базы данных и сервером приложений) получить хоть какой выигрыш от дополнительных ядер. В большинстве движков баз данных от добавления ядер вообще ничего не меняется, или меняется на единицы процентов, а с определенного предела даже может стать немного хуже.
На данном графике к порогу еще не приблизились.
Для более детальных комментариев, не руководствуясь догадками, мне нужно больше информации по природе алгоритма Epic EMR, надеюсь получить её вскоре и дать уже обоснованный ответ.
Тут конечно есть некоторая методическая нечистота, и не получилось сравнения «яблок с яблоками». Думаю, данные сравнивались с теми что были в наличии с предыдущего тестирования годом а может и больше раньше (это пока спекуляции — спрошу внутри). Надо учитывать, что Epic постоянно занимается тестированием на новом интеловском и не интеловском железе (и в облаке), и они могут представить полный ряд референсных данных своего приложения на любом процессоре, любого предыдущего поколения.
Заранее оговорюсь, что в момент «предыдущего тестирования» (больше чем год назад) я работал на другой стороне и посему дальше комментарии про процессоры, а не базы данных.
Xeon E5-2680 является серверным 8-и ядерным процессором семейства SandyBridge-EP (2 процессора на мамке). Техпроцесс 32 нанометра. Xeon E7-4890 является серверным 15-ядерным процессором семейства IvyBridge-EX (4 процессора на мамке), со следующим техпроцессом — 22нанометра.
IvyBridge является «компактизацией» SandyBridge, т.е. дизайн ядра процессора почти не менялся, вместо этого просто перешли на новый техпроцесс. И при всех прочих обстоятельствах, переход на новый техпроцесс считается успешным если удается при той же частоте дать 10-15% ускорения (ну или уменьшения потребления электричества при той же производительности).
Таким образом при почти одинаковой частоте, ядро-к-ядру, чисто за счет улучшения техпроцесса, могут давать ускорение 15-20%. Т.е. если при похожем увеличении параллелизма на разных, но близких процессорах, мы видим кривую роста на новой версии СУБД не повторяющую рост на предыдущей версии (пусть и с некоторым сдвигом), а более крутой рост (больше чем ожидаемые 15%), то прирост получен через алгоритмические оптимизации а не через улучшения в железе.
Попрошу показать мне не такой транспонированный график — прокомментирую больше.
Более того, на базе NuGet, который всегда считался как-бы только .NET, был сделан Chocolatey Nuget, который вообще все. (Ну или очень многое, от броузеров до VisualStudio или Office)Ну то есть реально как какой-нибудь apt-get но для Windows.
c:\>choco install googlechrome
И у вас скачан и инсталлирован последний стабильный chrome.
(Я его случайно нашел когда озаботился обновлением редактора Github Atom, в котором не было встроенных служб обновления, но которые посоветовали использовать choco)
Ну и развитием этой идей для первоначальной раскрутки голой установки Windows с применением chocolatey является проект BoxStarter. Видео там очень показательное.
Докладываю по обстановке: после покупки Интелом Трансметы и их всех наработок я думал в мире оставалось 2-3 команды занимающихся подобными делами и с нужной экспертизой (команда Дейва Дитцеля в американском Интеле, команда Б.А.Бабаяна в российском Интеле и МЦСТ-Эльбрус команда как остатки прежнего Эльбруса). Все они так или иначе работают(ли) над темой hardware-software codesign с вытаскиванием параллелизма при помощи бинарной трансляции. Оказалось же что есть как бы и 4-ая команда, работавшая в ИТМиВТ с американцами, которая здесь и выстрелила. (Вполне допускаю что это может быть и тот самый МЦСТ и команды всего 3).
В Интеле с осени прошлого года фактически закрыли эти эксперименты, т.ч. «взоры прогрессивной общественности» устремились в сторону softmachines как последних представителей БТ-школы. Посмотрим, что у них получится.
Множество виртуальных ядер и все подходы очень похожи на последний проект Бабаяна со стрендами, но все еще много недоговоренного и много вопросов. Очень интересует как они будут справлять единым front-end ом? Какой overhead на бинарную трансляцию? И сколько уровней трансляции и где хранить собираются базу оттранслированного кода?
Дьявол как обычно в деталях. Бинарная трансляция небесплатна и вот эти маленькие детали, связанные с БТ могут испортить всю обедню.
С практической точки зрения было бы лучше пытаться создать местное сообщество в своем городе. Именно в этом и цель всех этих «C++ party» — регулярные встречи местного сообщества
Хотелось бы посмотреть именно на «enterprise xml» с адской вложенностью, чтобы понять где наши ограничения будут упираться в пределы движка.
Можно примерчик (чисто для развития)
Если бы речь была о публичном бенчмарке, типа SPECint, HPC-H, и т.п. то вендор обязан был бы публиковать все подробности конфигураций и скриптов. Но в данном случае это внутренний бенчмарк, созданный Epic в 2002 году и применяемый им все это время для определения потолка производительности системы. Детали раскрывать не могу (да и не знаю многого), но высокоуровневое описание почитал на страницах проекта.
Epic использует ECP для горизонтального масштабирования системы. [Вы, как бывший пользователь Caché, знаете что это такое, для других поясню — это Enterprise Caching Protocol, протокол для передачи данных на удаленные монтировки, со встроенной синхронизацией и когерентностью]
На тестовой системе Epic трафик внешних «пользователей» (в рамках тестирования, конечно, генерируемый) распределяется по «более чем 50» (на начало 2014 года) серверам приложений. Сразу заметим, что максимальное количество ядер на 1 сервере приложений дела не играет, всегда можно рядом поставить еще десяток. В итоге мы имеем, скажем, 3000 тысячи ядер, так или иначе распределенных на машины.
На момент начала проекта Epic заметил, что чтобы они ни делали, сколько бы серверов приложений не ставили, они получают потолок в 7миллионов GloRef в секунду на 2013.1. В лучшем случае получалось увеличение responce time до неприемлемых значений. В рамках работ по оптимизации в 2015.1 было сделано несколько улучшений, больших и малых, но пару стоит упомянуть:
улучшен алгоритм синхронизации на Linux/x64 системах (как собственно для примитивов синхронизации, так и, например, для write daemon); и собственно ускорена работа всех элементов, вовлеченных в ECP взаимодействие, что позволило снять видимые ограничения в 7миллионов GloRef, и достичь 3-хкратного увеличения
В теории могли достичь и больших значений верхнего предела, но:
— этого значения более чем хватает на их прогнозируемые нагрузки на самых больших инсталляциях ; — и у них закончились возможности тестовой лаборатории :)
Т.е. конечно же, эта история больше про все агрегатные улучшения в движке Caché 2015.1 (на всех поддерживаемых аппаратных платформах, а не только x64), чем про специфичные x64 оптимизации. Но и про оптимизации тоже.
Самый большой вызов при проектировании алгоритмов на СУБД и/или сервере приложений (а Caché является одновременно и сервером базы данных и сервером приложений) получить хоть какой выигрыш от дополнительных ядер. В большинстве движков баз данных от добавления ядер вообще ничего не меняется, или меняется на единицы процентов, а с определенного предела даже может стать немного хуже.
На данном графике к порогу еще не приблизились.
Для более детальных комментариев, не руководствуясь догадками, мне нужно больше информации по природе алгоритма Epic EMR, надеюсь получить её вскоре и дать уже обоснованный ответ.
Заранее оговорюсь, что в момент «предыдущего тестирования» (больше чем год назад) я работал на другой стороне и посему дальше комментарии про процессоры, а не базы данных.
Xeon E5-2680 является серверным 8-и ядерным процессором семейства SandyBridge-EP (2 процессора на мамке). Техпроцесс 32 нанометра.
Xeon E7-4890 является серверным 15-ядерным процессором семейства IvyBridge-EX (4 процессора на мамке), со следующим техпроцессом — 22нанометра.
IvyBridge является «компактизацией» SandyBridge, т.е. дизайн ядра процессора почти не менялся, вместо этого просто перешли на новый техпроцесс. И при всех прочих обстоятельствах, переход на новый техпроцесс считается успешным если удается при той же частоте дать 10-15% ускорения (ну или уменьшения потребления электричества при той же производительности).
Таким образом при почти одинаковой частоте, ядро-к-ядру, чисто за счет улучшения техпроцесса, могут давать ускорение 15-20%. Т.е. если при похожем увеличении параллелизма на разных, но близких процессорах, мы видим кривую роста на новой версии СУБД не повторяющую рост на предыдущей версии (пусть и с некоторым сдвигом), а более крутой рост (больше чем ожидаемые 15%), то прирост получен через алгоритмические оптимизации а не через улучшения в железе.
Попрошу показать мне не такой транспонированный график — прокомментирую больше.
И у вас скачан и инсталлирован последний стабильный chrome.
(Я его случайно нашел когда озаботился обновлением редактора Github Atom, в котором не было встроенных служб обновления, но которые посоветовали использовать choco)
Ну и развитием этой идей для первоначальной раскрутки голой установки Windows с применением chocolatey является проект BoxStarter. Видео там очень показательное.
Пару раз переименовывал проект в GitHub — старые ссылки продолжают работать. Главное в них после этого не заливать ничего, будет плохо.
В Интеле с осени прошлого года фактически закрыли эти эксперименты, т.ч. «взоры прогрессивной общественности» устремились в сторону softmachines как последних представителей БТ-школы. Посмотрим, что у них получится.
Множество виртуальных ядер и все подходы очень похожи на последний проект Бабаяна со стрендами, но все еще много недоговоренного и много вопросов. Очень интересует как они будут справлять единым front-end ом? Какой overhead на бинарную трансляцию? И сколько уровней трансляции и где хранить собираются базу оттранслированного кода?
Дьявол как обычно в деталях. Бинарная трансляция небесплатна и вот эти маленькие детали, связанные с БТ могут испортить всю обедню.