Почти каждый год на рынок выходит новое поколение центральных процессоров Intel Xeon E5. В каждом поколении попеременно меняются сокет и технологический процесс. Ядер становится всё больше и больше, а тепловыделение понемногу снижается. Но возникает естественный вопрос: «Что даёт новая архитектура конечному пользователю?»
Для этого я решил протестировать производительность аналогичных процессоров разных поколений. Сравнивать решил модели массового сегмента: 8-ядерные процессоры 2660, 2670, 2640V2, 2650V2, 2630V3 и 2620V4. Тестирование с подобным разбросом поколений является не совсем справедливым, т.к. между V2 и V3 стоит разный чипсет, память нового поколения с большей частотой, а самое главное — нет прямых ровесников по частоте среди моделей всех 4-х поколений. Но, в любом случае, это исследование поможет понять в какой степени выросла производительность новых процессоров в реальных приложениях и синтетических тестах.Читать полностью »
Рубрика «высокая производительность» - 100
Сравнение производительности процессоров Intel разных поколений
2017-03-02 в 7:03, admin, рубрики: 1c, 3ds max, 7zip, cinebench, E5-2620V4, E5-2660, E5-2670, EX217.3-004LH, EX227.3-008LH, EX240.3-008LH, IT-стандарты, PerformanceTest, stss, Блог компании STSS, высокая производительность, поколения процессоров, процессоры Intel Xeon, Системы Флагман, тест процессоров, Тестирование IT-систем, тестирование производительности, метки: 7zip, cinebenchДизайн REST API для высокопроизводительных систем
2017-03-01 в 16:19, admin, рубрики: rest api, Анализ и проектирование систем, архитектура, высокая производительность, нагрузка, построение систем, тестирование, фронтенд
Александр Лебедев выражает всю нетривиальность дизайна REST API. Это — расшифровка доклада Highload++ 2016.
Всем здравствуйте!
Поднимите руку те, кто фронтенд разработчик в этом зале? Кто мобильный разработчик? Кто бэкенд разработчик?
Бэкенд разработчиков большинство в этом зале сейчас, что радостно. Во-вторых, почти все проснулись. Чудесная новость.
Пару слов о себе
Кто я такой? Чем занимаюсь?
Я фронтенд team lead компании «Новые Облачные Технологии». Последние 5 лет я писал веб фронтенд, который работает с REST API и который должен для пользователя работать быстро. Я хочу поделиться опытом о том, какие API должны быть, которые позволяют этого добиться.
Несмотря на то, что я буду рассказывать со стороны фронтенда, принципы — они общие более-менее для всех. Я надеюсь и бэкенд разработчики, и разработчики мобильных приложений так же найдут для себя в этом рассказе полезные вещи.
Читать полностью »
Страх и ненависть в распределённых системах
2017-02-28 в 15:48, admin, рубрики: jepsen, sql, Анализ и проектирование систем, высокая производительность, нагрузочное тестирование, отказоустойчивость, проектирование систем, распределенные системы, метки: проектирование систем, распределённые системы
Роман Гребенников объясняет сложность построения распределённых систем. Это — доклад Highload++ 2016.
Всем привет, меня зовут Гребенников Роман. Я работаю в компании Findify. Мы делаем поиск для онлайн-магазинов. Но разговор не об этом. В компании Findify я занимаюсь распределенными системами.
Что же такое распределённые системы?
Читать полностью »
Смотрим внутренности отечественного 28нм MIPS процессора — Baikal-T1
2017-02-28 в 15:43, admin, рубрики: 28нм, Baikal-T1, fpga, imagination technologies, mips, Блог компании Zeptobars, высокая производительность, гигпорн, Правило 34, программирование микроконтроллеров, реверс-инжиниринг
Думаю многие уже слышали про реализованный московскими разработчиками Байкал Электроникс процессор Байкал-Т1 — с двумя ядрами Imagination Technologies P5600 MIPS 32 r5 и набортным 10GbE. Байкал оказался первым, кто реализовал в кремнии это ядро.
Терзал этот процессор я с перерывами больше года — но наконец под катом могу поделиться результатами.Читать полностью »
История одного толстого бинарника
2017-02-28 в 15:01, admin, рубрики: embedded, Go, IoT, бинарные файлы, Блог компании Badoo, высокая производительность, Программирование
Привет. Меня зовут Марко (я системный программист в Badoo). И я представляю вашему вниманию перевод поста по Go, который мне показался интересным. Go действительно ругают за толстые бинарники, но при этом хвалят за статическую линковку и за удобство выкладки единственного файла. Если на современных серверах толстые бинарники – не проблема, то на встраиваемых системах – еще как. Автор описывает свою историю борьбы с ними в Go.
ClickHouse: очень быстро и очень удобно
2017-02-27 в 17:01, admin, рубрики: clickhouse, olap, sql, Анализ и проектирование систем, высокая производительность, СУБД
Виктор Тарнавский показывает, что оно работает. Перед вами расшифровка доклада Highload++ 2016.
Здравствуйте. Меня зовут Виктор Тарнавский. Я работаю в «Яндексе». Расскажу про очень быструю, очень отказоустойчивую и супермасштабируемую базу данных ClickHouse для аналитических задач, которую мы разработали.
Пару слов обо мне. Я Виктор, работаю в «Яндексе» и руковожу отделом, который занимается разработкой аналитических продуктов, таких как «Яндекс.Метрика» и «Яндекс.AppMetrica». Я думаю, многие из вас пользовались этими продуктами и знают их. Ну, и в прошлом, и по-прежнему пишу много кода, а раньше еще занимался разработкой железа.
Читать полностью »
Архитектура растущего проекта на примере ВКонтакте
2017-02-25 в 15:11, admin, рубрики: memcached, mysql, nginx, php, Анализ и проектирование систем, Вконтакте, высокая производительность, высокие нагрузки
Алексей Акулович объясняет жизненный путь высоконагруженного проекта на PHP. Это — расшифровка Highload ++ 2016.
Меня зовут Лёша, я пишу на PHP.
К счастью, доклад не об этом. Доклад будет про ретроспективу развития сети — того, как проект развивался. Какие решения капитанские или весьма специфические для нашей нагрузки мы применяли, что можно использовать в других проектах, которые испытывают нагрузки.
Начнём.
Читать полностью »
MySQL и MongoDB — когда и что лучше использовать
2017-02-24 в 16:56, admin, рубрики: mongodb, mysql, высокая производительность, выступления, доклады, Пётр Зайцев
Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.
Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.
Читать полностью »
Система BBR: регулирование заторов непосредственно по заторам
2017-02-23 в 5:48, admin, рубрики: B4, BBR, cubic, Google, Google Cloud Platform, IT-стандарты, make-tcp-fast, rtt, tcp, WAN, YouTube Edge, Алгоритмы, бутылочное горлышко, высокая производительность, двоичный поиск, затор, макс-плюс, нестандартная алгебра, потеря пакетов, Разработка систем передачи данных, системы управления, сотовая связь, теории оценивания, узкое место, метки: BBRИзмерение пропускной способности узких мест по времени двойного прохода пакета
По всем параметрам, сегодняшний интернет не может перемещать данные так быстро, как должен. Большинство пользователей сотовой связи в мире испытывают задержки от нескольких секунд до нескольких минут: публичные точки WiFi в аэропортах и на конференциях ещё хуже. Физикам и климатологам нужно обмениваться петабайтами данных с коллегами по всему миру, но они сталкиваются с тем, что их тщательно продуманная многогигабитная инфраструктура часто выдаёт всего несколько мегабит в секунду на трансконтинентальных линиях. [6]
Эти проблемы возникли из-за выбора архитектуры, который был сделан при создании системы регулирования заторов TCP в 80-е годы — тогда потерю пакетов решили интерпретировать как «затор». [13] Эквивалентность этих понятий была справедливой для того времени, но только из-за ограничений технологии, а не по определению. Когда NIC (контроллеры сетевых интерфейсов) модернизировали с мегабитных до гигабитных скоростей, а микросхемы памяти — с килобайт до гигабайт, до связь между потерей пакетов и заторами стала менее очевидной.
В современном TCP регулирование заторов по потере пакетов — даже в наиболее совершенной технологии такого рода CUBIC [11] — основная причина этих проблем. Если буферы узких мест слишком большие, то система регулирования заторов по потере пакетов держит их полными, вызывая излишнюю сетевую буферизацию. Если буферы слишком маленькие, то система регулирования заторов по потере пакетов неверно интерпретирует потерю пакета как сигнал затора, что ведёт к снижению пропускной способности. Решение этих проблем требует альтернативы регулированию заторов по потере пакетов. Для нахождения этой альтернативы следует разобраться, где и как возникают заторы.
Читать полностью »
Как я сделал самый быстрый ресайз изображений. Часть 1, общие оптимизации
2017-02-21 в 13:12, admin, рубрики: C, pillow, pillow-simd, python, sse, uploadcare, x87, высокая производительность, обработка изображений, оптимизация, производительность, ресайзВ пилотной части я рассказал о задаче как можно подробнее. Рассказ получился долгим и беспредметным — в нем не было ни одной строчки кода. Но без понимания задачи очень сложно заниматься оптимизацией. Конечно, некоторые техники можно применять, имея на руках только код. Например, кешировать вычисления, сокращать ветвления. Но мне кажется, что некоторые вещи без понимания задачи просто никогда не сделать. Это и отличает человека от оптимизирующего компилятора. Поэтому ручная оптимизация все еще играет огромную роль: у компилятора есть только код, а у человека есть понимание задачи. Компилятор не может принять решение, что значение "4" достаточно случайно, а человек может.
Напомню, что речь пойдет об оптимизации операции ресайза изображения методом сверток в реально существующей библиотеке Pillow. Я буду рассказывать о тех изменениях, что я делал несколько лет назад. Но это не будет повторение слово-в-слово: оптимизации будут описаны в порядке, удобном для повествования. Для этих статей я сделал в репозитории отдельную ветку от версии 2.6.2 — именно с этого момента и будет идти повествование.