Дима daimor, наверное Женя тут намекает что он поставит демку на демо-сервер, как только разберется как «это готовить».
(Что, кстати, не очень очевидно, и, в свое время, с первого пинка не удалось — пришлось массажировать REST конфиг и вроде даже исходник(и) обработчиков)
(Должен сразу признаться — я большой фанат этого проекта с самого его начала, и думаю он окажет большое влияние на всю программу преподавания Caché по всему миру)
И мы постараемся перевести на английский весь этот цикл статей — наличие такого простого визуального инструмента для просмотра структуры данных и аллоцированных блоков (ждите следующую часть статьи) позволяет легко и наглядно рассказать о деталях реализации движка. Это может быть очень интересно и за пределами российского сообщества. IMVHO.
С другой стороны, отходя от ткущего топика, да «блокировщики против версионщиков» важная тема, и её при случае надо рассмотреть. И, конечно же, над уметь правильно использовать глобалы и CacheSQL реализацию на оных.
А давайте Вы, Александр smagen попытаетесь написать такую статью, с Вашим пересечением экспертизы и в Caché и PostgreSQL?
Хотелось бы подчеркнуть, что Дима DAiMor не является сотрудником InterSystems и, реализовав отличный инструмент просмотра структуры глобалов и карты распределения блоков, он пишет о том как можно изучать внутренности текущей реализации с использованием его внешнего инструмента. Ни больше и не меньше.
В следующих двух его постах он покажет (в картинках! :) ) как использовать его просмотрщик, и, боюсь там ни слова не будет про MVCC.
Отличная новость, обязательно постараюсь приехать!
И озвучу это здесь (может он сам откликнется) — очень хочется послушать про GSL (Guidelines Support Library) и кажется что оптимальным было бы пригласить Сергея Зубкова который, похоже, принимал участие в его (GSL) разработке.
Ну почему же гадать? Процессоростроение — очень строгая дисциплина, с кучей полезных инструментов, даже когда кристалл появится лет через 7, и у Интела всегда есть пара тузов в загашничке, чтобы померить изменения в производителности для измененного или планируемого new instructions set.
(И sde здесь очень важный инструмент, т.к. им занимается ровно тот же человек, участвующий во всех совещаниях по расширению instruction set, и пишуший декодер XED, используемый во всех ну или в большинстве интеловских симуляторах разного уровня подробности)
В данном случае flow предполагается таким: вы переделываете код с применением расширений (расширяя свой компилятор или через assembler), убеждаетесь на sde что все работает, запускаете там же его с PIN-LIT, записываете измененные трассы (LIT) исполнения, и уже эти трассы изучаете (не вы, скорее всего, а специально обученный performance engineer или microarchitecture engineer) в потактовом симуляторе типа keiko.
Если вы большой и важный клиент, типа Microsoft, то такое низкоуровневое взаимодействие давно налажено, и все инструменты у нужных людей уже есть, но если же пока нет настолько близкого контакта и у вас какой high-profile проект, то можно через SSG DRD запросить помощь и выйти на нижегородскую команду performance инженеров. Они помогут.
P.S.
Я уже пару лет не в Intel, т.ч. детали могли слегка измениться
Добавлю свои пять копеек — да, Вы правы что EM64T есть Intel-овская реализация AMD64 расширения, и был впервые реализован в P4/Prescott вполне по-честному (т.е. и регистровый файл 64-разрядный, и 64-разрядные адреса в 48-разрядном логическом пространстве). Но и оригинальный автор тоже прав по поводу эмуляции. Частично.
Главное отличие EM64T от AMD64 в поддержке набора инструкций VMX (VT-x1.x) для виртуализации вместо AMD-шной Pacifica. И VMX был со всех сторон проблемой: мало того что автоматическая трансляция страниц (EPT) там появился только к Nehalem (2 tock-а позже), так и в первоначальных реализациях VMX делался полностью на микрокоде. [Потому и простой VMENTRY/VMEXIT в Prescott занимал около тысячи тактов]
Ну т.е. в P4/Prescott x64 (тогда называвшаяся EM64T) реализация вполне родная, 64-разрядная, но, да, там были большие куски микрокода, и нет, EM64T не идентичен AMD64.
P.S.
А выпустить реализацию AMD64 под своим именем EM64T Интелу позволяет кросс-лицензионное соглашение с AMD. Копировать instructions set могут в обе стороны (и Intel у AMD, что было в случае с AMD64 расширением, так и AMD у Intel, что было во всех остальных случаях, и последний случай с AVX)
Да, именно так. Я даже могу очертить численную границу перехода в состояние BigData…
[Не люблю самоцитирований, но здесь это имеет смысл] habrahabr.ru/post/267697/#comment_8590875
Я полностью согласен с Девидом Кантором в его утверждении, что BigData начинаются там, где уже невозможно весь набор данных поместить в память сервера. Для текущих конфигураций 2х-сокетных серверов это где-то в районе 3ТБ twitter.com/thekanter/status/559034352474914816
т.е. если, допустим, использовать dd из /dev/zero для создания заполненного фала, а не sparse файла, то будет честнее и ближе к жизни. Так получилось, что в данном случае наткнулись на странный баг в ext4. И пока не знаем почему grep с файлами медленнее. Если это действительно так.
P.S.
Моё персональное IMHO, но более эпохальны собственно предлагаемые guidelines, и соответствующие артефакты в виде GSL [guideliens support library] и статического анализатора по (смотри презентации Бъярна и Герба). Они кардинальным образом отразятся на качестве C++11/14/17 программ.
Да, согласен, это подходит если уже есть распараллеленый алгоритм на утилитах (что у нас было, когда добавляли стадию reduce дополнительным awk-ом) и при дальнейшей необходимости расширять счетные ресурсы вширь, то можно это запустить на Joyen Manta, ранее озвученном GNU parallel или каком другом классическом grid планировщике.
Не очень хороший пример с пересчетом рейтинга. Как часто у нас в данном примере надо пересчитывать его: при каждом запросе, каждую секунду, каждую минуту, каждый час?
Или только по завершении партии?
(Ответ: Рейтинги надо хранить подсчитанными и пересчитывать их только при изменении данных, которые меняются не чаще чем Н секунд/минут (как функция средней продолжительности партии и среднего количества параллельно активных партий — ср.длина/ср.параллелизм)
Я бы очень не рекомендовал пытаться пересчитывать рейтинг по каждому запросу, обеспечивая «реал-тайм рейтинг». Зря только электроны гонять)
А будет ли это эффективно с финансовой точки зрения? Нет, я серьезно. Можно конечно запустить 1000 виртуализированных Sandy Bridge ядер, которые при сравнении лов-в-лоб, конечно, работают в 5 раз медленнее физического Haswell ядра, но навалившись, гуртом и большой компанией дающих выигрыш в 100 раз (при условии бесконечно параллелизуемого алгоритма). Но какой ценой будет это достигнуто? Сколько денег за электричество вы заплатите для обслуживания такой виртуализированной фермы? Будет ли такое решение предоставлять результат быстрее накладных расходов на планировщик и задержек на возврат результата?
Ведь по большому счету вся история про облака и кластеры началась с основной идей — не платить миллионы$ за большой сервер а поставить 100 commodity server-ов и получить решение эффективное с точки зрения стоимости Ватта. Если в вашем Hadoop решении, для того чтобы его сделать в 10 раз, надо заплатить, скажем, в 100 раз больше на инфраструктуру, то может ну его на фиг? Может и по старинке иногда? Задумываясь об алгоритмах и задержках, и не всегда полагаясь на волшебство BigData?
Спасибо, Борь dolphin278 за ссылку на Манта. Не знал. Сразу не понял каким образом это можно применить к нашему случаю, но там есть хорошие, и я бы даже сказал классические примеры, и стало понятно. Это довольно типичный сервис grid вычислений, с распределенным планировщиком задач, но обернутый в модный JSON.
Очень сильно напомнил мне NetBatch который в Intel-е используют для тестирования в своих серверных фермах (не думаю, что он известен за пределами Intel). Там не было модного JSON, но все остальное как и здесь.
P.S.
Одна проблема с такими грид средами — накладные расхода на формирование контекста, постановку в очередь, разворачивание контекста. запуск, сбор результата, и возврат данных — ООЧЕНЬ большие. Для таких элементарных заданий как описана здесь, когда сам прогон несколько минут, такие накладные расходы на планировщик и инфраструктуру чрезмерны.
Спасибо Komzpa за ссылку — не слышал. Посмотрел, и штука дейтсвительно интересная. Если надо удобно параллелить/распределять скрипты между узлами/ядрами. Есть где поиспользовать уже в ближайшее время
Но в данном случае `parallel` думаю не дал бы никакого выигрыша т.к. автор сам распараллеливал на все имеющиегося у него ядра через опцию -P 4 у xargs.
(Что, кстати, не очень очевидно, и, в свое время, с первого пинка не удалось — пришлось массажировать REST конфиг и вроде даже исходник(и) обработчиков)
Короче, да, нужен правильный README
И мы постараемся перевести на английский весь этот цикл статей — наличие такого простого визуального инструмента для просмотра структуры данных и аллоцированных блоков (ждите следующую часть статьи) позволяет легко и наглядно рассказать о деталях реализации движка. Это может быть очень интересно и за пределами российского сообщества. IMVHO.
А давайте Вы, Александр smagen попытаетесь написать такую статью, с Вашим пересечением экспертизы и в Caché и PostgreSQL?
В следующих двух его постах он покажет (в картинках! :) ) как использовать его просмотрщик, и, боюсь там ни слова не будет про MVCC.
И озвучу это здесь (может он сам откликнется) — очень хочется послушать про GSL (Guidelines Support Library) и кажется что оптимальным было бы пригласить Сергея Зубкова который, похоже, принимал участие в его (GSL) разработке.
(И sde здесь очень важный инструмент, т.к. им занимается ровно тот же человек, участвующий во всех совещаниях по расширению instruction set, и пишуший декодер XED, используемый во всех ну или в большинстве интеловских симуляторах разного уровня подробности)
В данном случае flow предполагается таким: вы переделываете код с применением расширений (расширяя свой компилятор или через assembler), убеждаетесь на sde что все работает, запускаете там же его с PIN-LIT, записываете измененные трассы (LIT) исполнения, и уже эти трассы изучаете (не вы, скорее всего, а специально обученный performance engineer или microarchitecture engineer) в потактовом симуляторе типа keiko.
Если вы большой и важный клиент, типа Microsoft, то такое низкоуровневое взаимодействие давно налажено, и все инструменты у нужных людей уже есть, но если же пока нет настолько близкого контакта и у вас какой high-profile проект, то можно через SSG DRD запросить помощь и выйти на нижегородскую команду performance инженеров. Они помогут.
P.S.
Я уже пару лет не в Intel, т.ч. детали могли слегка измениться
Главное отличие EM64T от AMD64 в поддержке набора инструкций VMX (VT-x1.x) для виртуализации вместо AMD-шной Pacifica. И VMX был со всех сторон проблемой: мало того что автоматическая трансляция страниц (EPT) там появился только к Nehalem (2 tock-а позже), так и в первоначальных реализациях VMX делался полностью на микрокоде. [Потому и простой VMENTRY/VMEXIT в Prescott занимал около тысячи тактов]
Ну т.е. в P4/Prescott x64 (тогда называвшаяся EM64T) реализация вполне родная, 64-разрядная, но, да, там были большие куски микрокода, и нет, EM64T не идентичен AMD64.
P.S.
А выпустить реализацию AMD64 под своим именем EM64T Интелу позволяет кросс-лицензионное соглашение с AMD. Копировать instructions set могут в обе стороны (и Intel у AMD, что было в случае с AMD64 расширением, так и AMD у Intel, что было во всех остальных случаях, и последний случай с AVX)
[Не люблю самоцитирований, но здесь это имеет смысл]
habrahabr.ru/post/267697/#comment_8590875
Я полностью согласен с Девидом Кантором в его утверждении, что BigData начинаются там, где уже невозможно весь набор данных поместить в память сервера. Для текущих конфигураций 2х-сокетных серверов это где-то в районе 3ТБ twitter.com/thekanter/status/559034352474914816
Все что меньше по размеру — «не очень Big Data»
т.е. если, допустим, использовать dd из /dev/zero для создания заполненного фала, а не sparse файла, то будет честнее и ближе к жизни. Так получилось, что в данном случае наткнулись на странный баг в ext4. И пока не знаем почему grep с файлами медленнее. Если это действительно так.
Но презентация по модулям уже выложена на GitHub arge Scale C++ With Modules: What You Should Know (Gabriel Dos Reis)
P.S.
Моё персональное IMHO, но более эпохальны собственно предлагаемые guidelines, и соответствующие артефакты в виде GSL [guideliens support library] и статического анализатора по (смотри презентации Бъярна и Герба). Они кардинальным образом отразятся на качестве C++11/14/17 программ.
Или только по завершении партии?
(Ответ: Рейтинги надо хранить подсчитанными и пересчитывать их только при изменении данных, которые меняются не чаще чем Н секунд/минут (как функция средней продолжительности партии и среднего количества параллельно активных партий — ср.длина/ср.параллелизм)
Я бы очень не рекомендовал пытаться пересчитывать рейтинг по каждому запросу, обеспечивая «реал-тайм рейтинг». Зря только электроны гонять)
Ведь по большому счету вся история про облака и кластеры началась с основной идей — не платить миллионы$ за большой сервер а поставить 100 commodity server-ов и получить решение эффективное с точки зрения стоимости Ватта. Если в вашем Hadoop решении, для того чтобы его сделать в 10 раз, надо заплатить, скажем, в 100 раз больше на инфраструктуру, то может ну его на фиг? Может и по старинке иногда? Задумываясь об алгоритмах и задержках, и не всегда полагаясь на волшебство BigData?
Очень сильно напомнил мне NetBatch который в Intel-е используют для тестирования в своих серверных фермах (не думаю, что он известен за пределами Intel). Там не было модного JSON, но все остальное как и здесь.
P.S.
Одна проблема с такими грид средами — накладные расхода на формирование контекста, постановку в очередь, разворачивание контекста. запуск, сбор результата, и возврат данных — ООЧЕНЬ большие. Для таких элементарных заданий как описана здесь, когда сам прогон несколько минут, такие накладные расходы на планировщик и инфраструктуру чрезмерны.
Но в данном случае `parallel` думаю не дал бы никакого выигрыша т.к. автор сам распараллеливал на все имеющиегося у него ядра через опцию -P 4 у xargs.
P.S.
Какая хорошая аудитория в Хабре, в оригинальной статье никто за год не нашел такие расхождения
P.P.S.
Его сайт отвечает через раз, похоже, Хабра-эффект в действии.