LINUX.ORG.RU

Миграционная ГИС переехала с IBM на «Эльбрусы» и СПО

 ,


3

5

Минкомсвязи перевела ведомственный сегмент системы «Мир» с «железа» и софта IBM на серверы на процессорах «Эльбрус». В работе ГИС «Мир» использует PostgreSQL, Apache ActiveMQ, Redis и другие свободные программные решения.

Сумма контракта по первому тендеру составила 49,5 млн рублей, по второму — 195,3 млн рублей.

«Суммарная стоимость закупки отечественного оборудования, внедрения и годовой поддержки данного решения меньше, чем стоимость только годовой поддержки оборудования иностранного производства», — заверяет директор департамента реализации стратегических проектов Минкомсвязи Андрей Черненко.

По условиям старого тендера, ОС должна была поддерживать СУБД PostgreSQL, брокеры гарантированной доставки сообщений Apache ActiveMQ, ПО хранилища данных Redis, Ceph и Librados, балансировщики нагрузки PgBouncer и Nginx, менеджеры ресурсов кластера и средства защиты от сбоев Pacemaker, ПО для обмена сообщениями между узлами кластера Corosync, средства защиты от сбоев Sentinel, ПО резервного копирования Bacula, утилиты для резервного копирования Barman, ПО сетевого мониторинга Zabbix, ПО сервисной поддержки OTRS, средства IP-телефонии Asterisk, среды разработки Java OpenJDK, серверы приложений Apache Tomcat. По данным источника CNews, именно эти решения и были задействованы в «Мире».

>>> Подробности

anonymous

Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от alexanius

Статическая планировка имеет то преимущество

А «бранчи и переходы бьют нам граблями по лбу» - это тоже архитектурное преимущество?

devl547 ★★★★★
()
Ответ на: комментарий от trycatch

Ты что то сгреб все подряд и налил каких то крокодильих слез

Статическая программная планировка ничуть не лучше динамической планировки

Оставь в покое планировку и все остальное, денвер суперскалярный процессор с планировшиком и OoO, но вместо аппаратного декодинга команд там jit компиляция в микрокод. Программная
Что тебе еще не понятно?

Да и посмотри на бенчмарки Эльбруса, выше была ссылка на презентацию оптимизированного порта Джавы на Эльбрус. В разы медленнее x86 10-летней давности

Ни в какие не разы а ядро 4С аналогично по производительности ядру 65нм Core 2 на одинаковой частоте, на самых неудобных для первого задачах.

Без бинарной трансляции VLIW еще более бесполезен за пределами встроенных применений. Трансмета и Денвер хотя бы вылились в какие-то реальные продукты.

Вот этого я вообще не понял, так ты против vliw/вынесения половины процессорной логики в в программу или тебе эльбрус просто не нравится?

uin ★★★
()
Ответ на: комментарий от devl547

А «бранчи и переходы бьют нам граблями по лбу» - это тоже архитектурное преимущество?

А кому они не бьют? :)

И не надо путать статический планировщик инструкций и отсутствие предсказателя переходов. Это разные вещи.

alexanius ★★
()
Ответ на: комментарий от trycatch

У Skylake, например, reordering буфер на 224 микро-операции. Достаточно, чтобы переставлять местами функции целиком. Запускаешь две библиотечные функции последовательно, а они исполняются параллельно. Куда больше?

А теперь, пожалуйста, данные по количеству микроопераций на процедуру.

Сравни обычный код с развернутым и векторизованным (по сути статическая планировка). Разница в разы.

Не понял - сравнить неоптимизированный с оптимизированным? Хотя к данной задаче это вообще никак не относится, но можно. Цифры в студию.

Пока что это всё высказывания в стиле «Ну вот у меня есть представление что это должно работать как-то так, поэтому здесь, здесь и здесь пусть будет хуже в разы. Всё равно никто проверять не будет»

alexanius ★★
()
Ответ на: комментарий от Iron_Bug

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

Xintrea ★★★★★
()
Ответ на: комментарий от uin

Что тебе еще не понятно?

Мне-то все понятно. А вот тебе, судя по всему, понятно очень мало чего. Денвер - это VLIW процессор без OoO, но с аппаратным декодером ARM-команд, который используется в качестве фоллбека, если софтовый бинарный транслятор не успел перекомпилировать ARM код.

Ни в какие не разы а ядро 4С аналогично по производительности ядру 65нм Core 2 на одинаковой частоте, на самых неудобных для первого задачах.

Смешно. Эльбрус медленнее в 3.6 раза. При разнице в частоте 800МГц против 2.5ГГц. При этом специально оптимизированный под Эльбрус JIT уж никак не является самой неудобной для него задачей.

trycatch ★★★
()
Ответ на: комментарий от alexanius

А теперь, пожалуйста, данные по количеству микроопераций на процедуру.

Лол, какие тебе нужны данные? x86-инструкция - это обычно 1-2 микрооперации. Точнее можешь посмотреть у Агнера: http://www.agner.org/optimize/instruction_tables.pdf Компилируешь в x86 нужную тебе функцию, смотришь число x86 инструкций. Если не знаешь, как обращаться с x86 ассемблером, воспользуйся http://gcc.godbolt.org/

Не понял - сравнить неоптимизированный с оптимизированным?

Это я понял, что ты не понял. Если бы ты разбирался в предметной области хоть немного, то ты понимал бы, о чем идет речь.

Цифры в студию.

Да, сейчас побежал собирать статистику, потому что какой-то гражданин с лора ее потребовал.

Пока что это всё высказывания в стиле «Ну вот у меня есть представление что это должно работать как-то так, поэтому здесь, здесь и здесь пусть будет хуже в разы. Всё равно никто проверять не будет»

Если ты не собираешься доказывать свои собственные утверждения, то ты не можешь требовать большего от собеседника. Это же ты сказал, что «Статическая планировка имеет то преимущество, что может планировать гораздо более далёкие инструкции и высоко закидывать LD операции.» Вперед, доказывай это с цифрами.

trycatch ★★★
()
Ответ на: комментарий от trycatch

Мне-то все понятно. А вот тебе, судя по всему, понятно очень мало чего. Денвер - это VLIW процессор без OoO

Ой да неужели

Смешно. Эльбрус медленнее в 3.6 раза. При разнице в частоте 800МГц против 2.5ГГц. При этом специально оптимизированный под Эльбрус JIT уж никак не является самой неудобной для него задачей.

Я говорил вообще про архивацию, JIT это вообще не задача.

uin ★★★
()
Ответ на: комментарий от uin

Ой да неужели

Под «OOO execution without the power» они подразумевают их софтовый JIT-оптимизатор, который выполняет роль планировщика, меняет порядок инструкций и так далее. Это in-order процессор.

trycatch ★★★
()
Последнее исправление: trycatch (всего исправлений: 1)
Ответ на: комментарий от Feonis

Представь себе,оказывается нужно делать dump/restore при смене архитектуры с 32 на 64, т.к. информация пишущаяся на диск, внезапно зависит от архитектуры процессора. Нашел в списке рассылки да и на SO тоже с этим согласны.

einhander ★★★★★
()
Ответ на: комментарий от trycatch

Лол, какие тебе нужны данные? ... Компилируешь в x86 нужную тебе функцию, смотришь число x86 инструкций.

facepalm. И потом эти люди строят из себя умных.

Немного поясню как подобные исследования проводятся. Берётся набор каких-нибудь признанных бенчмарков, компилируется, после чего смотрятся горячие функции. А далее самое интересное - понять что мы хотим померить. Можно было бы посмотреть количество операций, которые были подняты вверх, но технически это не удастся сделать достаточно точно. Если говорить про перестановку операций - то даже примерно не представляю как это сделать.

Это я понял, что ты не понял. Если бы ты разбирался в предметной области хоть немного, то ты понимал бы, о чем идет речь.

Да, сейчас побежал собирать статистику, потому что какой-то гражданин с лора ее потребовал.

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

alexanius ★★
()
Ответ на: комментарий от alexanius

Языком трепать тут все горазды, а вот попросишь хоть одну цифру привести, так ахинею несут

Ты сам-то много цифр привел?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ты сам-то много цифр привел?

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

Просто я не делаю категоричных утверждений без пруфов (да и с ними тоже), и уж тем более не пытаюсь выставить тех кто со мной не согласен идиотами (см. обсуждение предикатов и спекулятивности).

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

alexanius ★★
()
Ответ на: комментарий от alexanius

Ты сам-то много цифр привел?

Из того что помню свои утверждения я не подкрепил ссылками

Ссылки? Я спрашивал о цифрах. Хотя ссылок от тебя тоже не вижу.

Но если есть что-то что я упустил - можешь напомнить

alexanius> Статическая планировка имеет то преимущество, что может планировать гораздо более далёкие инструкции и высоко закидывать LD операции.

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

alexanius> Статическая планировка имеет то преимущество, что может планировать гораздо более далёкие инструкции и высоко закидывать LD операции.

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

Ну смотри, сам факт того что статическая планировака смотрит шире довольно очевиден, но вот, например, ссылка на слайды университета Дюка, например. Смотри слайд 13:

Scheduling: Compiler or Hardware?

  • compiler
    • + large scheduling scope (full program), large “lookahead”
    • + enables simple hardware with fast clock
    • – low branch prediction accuracy (profiling? see next slide!)
    • – no information on latencies like cache misses (profiling?)
    • – pain to speculate and recover from mis-speculation (h/w support?)
  • hardware
    • + better branch prediction accuracy
    • + dynamic information on latencies (cache misses) and dependences
    • + easy to speculate & recover from mis-speculation
    • – finite on-chip instruction buffering limits scheduling scope
    • – more complicated hardware (more power? tougher to verify?)
    • – slower clock

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

alexanius ★★
()
Ответ на: комментарий от alexanius

Немного поясню как подобные исследования проводятся. Берётся набор каких-нибудь признанных бенчмарков, компилируется, после чего смотрятся горячие функции.

О чем это ты вообще, какие еще исследования? Я отвечал на следующую твою реплику (цитирую ее целиком, никакого контекста там нет): «А теперь, пожалуйста, данные по количеству микроопераций на процедуру.» Откуда ты выдумал какое-то исследование? На всякий случай поясню, что я не проводил для поста на лоре никаких исследований и делать это точно не собираюсь, тем более ради тебя.

А далее самое интересное - понять что мы хотим померить.

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

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

Самокритично, особенно сразу после «facepalm. И потом эти люди строят из себя умных.»

Ну смотри, сам факт того что статическая планировака смотрит шире довольно очевиден, но вот, например, ссылка на слайды университета Дюка, например.

Поздравляю с первой ссылкой, которую ты привел в этом треде. Впрочем никаких цифр, которые ты так настойчиво просил от меня, там нет. И кстати, статическая и динамическая планировка - это вещи не взаимоисключающие. Сравнивать нужно не статическую vs динамическую, а статическую vs статическую+динамическую планировку. Компиляторы вполне себе проводят планировку в том числе и для out-of-order процессоров. LLVM даже учитывает размер reorder буфера в своей модели машины для планировщика: http://llvm.org/docs/doxygen/html/MCSchedule_8h_source.html#l00142 VLIW здесь не получает ни малейшего преимущества. Он только потеряет достоинства.

trycatch ★★★
()
Последнее исправление: trycatch (всего исправлений: 1)

Товарищи, дорогие мои товарищи!

Это Победа!

anonymous
()
Ответ на: комментарий от trycatch

execution

jit исполняет и команды в очередь на исполнение перестраивает? Может у них тогда сразу там программа в кэше вместо процессора? А блок схема это так - просто так нарисовали, чтоб было чего на слайдах показывать.
И 7-way суперскаляр ты как интерпритируешь, мне интересно?

uin ★★★
()
Ответ на: комментарий от uin

Может ты уже просто прочитаешь уже статью про Денвер, а не будешь продолжать гадать по слайду? http://www.anandtech.com/show/8701/the-google-nexus-9-review/3

И 7-way суперскаляр ты как интерпритируешь, мне интересно?

Суперскалярный процессор не обязан быть с внеочередным исполнением. Например, Пентиум - это in-order суперскалярный процессор. https://en.wikipedia.org/wiki/Superscalar_processor

trycatch ★★★
()
Ответ на: комментарий от trycatch

прочитаешь уже статью про Денвер
http://www.anandtech.com

В которой гадают по слайдам NVIDIA, лол

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

Все не могу понять ты или туп или зелен, ты вначале чесал про то что он vliw и что OoO суперскаляр быстрей, теперь выворачиваешься так будто не отрицал что он суперскаляр а имел в вивиду что у него просто отсутствует внеочередное исполнение.
Но оно таки присутствует и указано в слайде прямо, что именно подразумевается под «without power» я лично не знаю, а вот ты как раз гадаешь на кофейной гуще да еще какую то бредятину про то что это типа про jit написано.
Если он ему программно там что то подсказывает что это позволяет избавится от лишних телодвижений - окей, но таки аппаратура умеет внеочередное исполнение.

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

В которой гадают по слайдам NVIDIA, лол

Лол. Поразительная упругость и тугость мышления, тут и жирафы бы давно ошибку просекли. Хорошо, еще одна статья, теперь в Microprocessor Report. http://webcache.googleusercontent.com/search?q=cache:crjXYZlN4ZAJ:www.linleyg...

The Denver microarchitecture is a strictly in-order design, eliminating the need for reorder buffers or similar hardware structures. All instruction bundles, whether they come from the ARM decoder or the microcode decoder, are handled in the same way once they reach the scheduler. The scheduler merely checks the micro-ops to ensure that all operands are available; if any operand is delayed (owing to an unexpected cache miss, perhaps), execution stalls until the dependency is resolved. These stalls happen more often in ARM mode, because the optimizer attempts to arrange the microcode to avoid stalls.

STRICTLY IN-ORDER DESIGN

Тебе перевести? Через сколько сообщений до тебя наконец дойдет, что Денвер - это in-order VLIW?

ты вначале чесал про то что он vliw и что OoO суперскаляр быстрей, теперь выворачиваешься так будто не отрицал что он суперскаляр а имел в вивиду что у него просто отсутствует внеочередное исполнение.

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

trycatch ★★★
()

Кстати, в той же статье про раздувание кода:

The optimizer analyzes the indicated ARM code and translates it into the CPU’s native microcode (micro-ops). Each ARM instruction converts to 1.8 micro-ops on average. ARM’s own CPUs also use microcode but generate about 1.1 or 1.2 micro-ops per instruction; Denver’s micro-ops are simpler and more general purpose than in ARM’s designs. The Denver micro-ops have a variable length but average about 5.7 bytes. Taking into account Thumb encodings, the average ARM instruction contains 3.1 bytes and converts to 10.3 bytes of micro-ops, increasing code size by 3.3x. (These figures are based on SPECint2000 and will vary somewhat by application.)

trycatch ★★★
()
Ответ на: комментарий от trycatch

reorder buffers
The scheduler merely checks the micro-ops to ensure that all operands are available;

до тебя наконец дойдет, что Денвер - это in-order VLIW?

В голос

uin ★★★
()
Ответ на: комментарий от alexanius

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

Ну смотри, сам факт того что статическая планировака смотрит шире довольно очевиден

Вопрос в том, насколько хорошо она видит.

вот, например, ссылка на слайды университета Дюка, например. Смотри слайд 13:

Там не сказано, что статический планировщик лучше. Сказано, что у каждого преимущества и недостатки.

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

Пока не сравнил - не делай заявлений вроде «имеет преимущество». Может оказаться, что преимущества нет.

Расскажешь как - сделаю.

Если бы я очень хотел доказать вышеприведенное утверждение - взял бы фрагмент кода, странслировал в x86, и разложил бы на микрооперации. Но я не вижу смысла - реализации VLIW раз за разом доказывали, что в реальности выигрыш сомнителен. Вот Denver: http://www.anandtech.com/show/8701/the-google-nexus-9-review/5 и http://www.anandtech.com/show/8701/the-google-nexus-9-review/6

tailgunner ★★★★★
()
Ответ на: комментарий от uin

Объясни где ты тут увидел vliw.

Да перестань ты тупить уже. Тебе дали ссылку, по которой ясно написано:

The Denver microarchitecture is a strictly in-order design

Или ты внезапно забыл, что Denver - это VLIW?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от uin

As in a VLIW design, micro-ops are grouped into bundles such that all micro-ops in a bundle can be executed in the same cycle. To minimize code expansion, the optimizer suppresses any unused slots, resulting in variable-length bundles. Each bundle can contain up to seven micro-ops but is capped at 32 bytes. Because of this cap, even a maximum-size bundle typically contains five or six micro-ops. The average bundle size is three or four micro-ops (18 to 24 bytes).

Или ты постепенно переходишь к спору о словах, что это неправильный VLIW и так далее?

trycatch ★★★
()
Ответ на: комментарий от trycatch

As in a VLIW

И нигде ни в одном месте не написано что это VLIW
, а в микрокод декодирует и интел если ты не знал.
В каком месте тут vliw если он просто бинарный код гоняет через jit и все?

uin ★★★
()
Ответ на: комментарий от uin

Пока что товарищ trycatch производит впечатление человека, который больше разбирается в предметной области.
В денвере нет хардварного планировщика, планированием занимается jit. И, боюсь, делает он это не слишком хорошо, иначе оверхед перебьет любой выигрыш в производительности.

Deleted
()
Ответ на: комментарий от Deleted

В денвере нет хардварного планировщика

Sheduler

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

И он говорит тебе:

Денвер - это VLIW процессор без OoO, но с аппаратным декодером ARM-команд, который используется в качестве фоллбека, если софтовый бинарный транслятор не успел перекомпилировать ARM код.

А vliw потому, что в какой то одной статье (удаленной) написали что похоже.

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

На пальцах: запускается армовый код на денвере, пока код холодный, армовый декодер конвертит армовые инструкции в инструкции денвера и пихает их на исполнительные блоки. Думаю, на самом низком уровне у них реализован интерпретатор, а не транслятор, тк декодинг хардварный и дешевый. Когда код нагревается, его профилируют, перегоняют в промежуточное представление, оптимизируют jitом, который в итоге генерит нативный код. Нативный код кидается в кеш трансляций.
На шедулер с его reservation stations нужно много транзисторов с его CAM, поэтому шедулинг jit - приемлемое решение.

Deleted
()
Ответ на: комментарий от alexanius

> В разы медленнее x86 10-летней давности на том же техпроцессе,
> причем медленнее в пересчете на мегагерц.

Потому что портирование java на Эльбрус длится не несколько
десятков лет. Да и данные по замерам уже устарели.

ты вглядись насолько *извращёнными* являются эти их «оптимизации»..

...КОСТЫЛИЩИ НЕВИДАННОГО МАШТАБА!

например самый ярый :FACEPALM: уменя вызвала ниньзятехника — когда для того чтобы не писать лишнее ветвление if{}else{} — они опускаются то того чтобы умышленно сделать segfault и перехватить его так как что-то самой-сабой разумеещееся..

что-то у меня после этого сразу возникло стойкое отвращение к написанию программ под Эльбрус. видетели медленный у них if{}else{} (как я понял — в ситуации когда на этапе компиляции нельзя выявить в какую ветвь вереход будет чаще? или вообще любой if{}else{} ?)

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

например самый ярый :FACEPALM: уменя вызвала ниньзятехника — когда для того чтобы не писать лишнее ветвление if{}else{} — они опускаются то того чтобы умышленно сделать segfault и перехватить его так как что-то самой-сабой разумеещееся..

https://youtu.be/o429h0JoFGo?t=1515
Если ты чего то не понимаешь, это не значит что это костыли
Возможно ты просто слушал жопой, или макака думающая что она великий програмизд.

uin ★★★
()
Ответ на: комментарий от uin

Если ты чего то не понимаешь, это не значит что это костыли

то есть это не костыли (по твоему) ?

или что хотел сказать?

Возможно ты просто слушал жопой, или макака думающая что она великий програмизд.

спасибо за эти 2 версии (кстати версия про макаку и про жопу — они ведь не взаимоисключающие? :-D). будем иметь их ввиду (как версии).. но пока-что вроде версия с КОСТЫЛИЩАМИ кажется более правдоподобной

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 3)
Ответ на: комментарий от user_id_68054

Хотел сказать что если бы ты вместо ерзаний на стуле спокойно бы послушал, то до тебя (возможно) бы дошло что это обычная оптимизация которая применяется в том числе и для x86, SPARC, MIPS, ARM и прочих.
А ты можно сказать только что буквально расписался в том что эталонный говнокодер даже не заморачивающийся насчет оптимизаций и прочего.

uin ★★★
()
Ответ на: комментарий от Deleted

Но ведь он нарисован на блок схеме, и исполнительные блоки там не блоки, а каналы как на интеле и Cortex-е

Когда код нагревается, его профилируют, перегоняют в промежуточное представление, оптимизируют jitом, который в итоге генерит нативный код.

Ну так видимо и есть, а потом их планировщик раскидывает по каналам

The scheduler merely checks the micro-ops to ensure that all operands are available; if any operand is delayed (owing to an unexpected cache miss, perhaps), execution stalls until the dependency is resolved. These stalls happen more often in ARM mode, because the optimizer attempts to arrange the microcode to avoid stalls.

uin ★★★
()
Ответ на: комментарий от uin

А ты можно сказать только что буквально расписался в том что эталонный говнокодер даже не заморачивающийся насчет оптимизаций и прочего

Я даже это не воспринимаю как оскорбление :-) , ведь ни какой разницы нет кто я — относительно решения этого вопроса. Можешь считать так как тебе удобнее :-) ..

А теперь к делу?

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

Где такая «оптимизация» на x86? В каких местах ты её видил?

Есть хоть одна причина не делать явную проверку на 0 (через if), кроме как причины о том что архитектура Эльбруса такая дерьмовая, поэтому желательно на ней всё делать через жопу?

По поводу ARM, SPARK, MIPS — про них вообще говорить незачем.

Эльбрус метит на место x86, а не на место этих ваших полуардуин-полумертвечины :-)

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 3)
Ответ на: комментарий от user_id_68054

Есть хоть одна причина не делать явную проверку

Например частовыполняющийся код? Не пробовал избавлять его от лишних ветвлений вынося их или заменяя на что нибудь, или ты такой код не пишешь?

Где такая «оптимизация» на x86? В каких местах ты её видил?

http://jpbempel.blogspot.ru/2013/09/null-check-elimination.html
Так что закатись откуда выкатился.

uin ★★★
()
Ответ на: комментарий от tailgunner

Там не сказано, что статический планировщик лучше. Сказано, что у каждого преимущества и недостатки.

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

Пока не сравнил - не делай заявлений вроде «имеет преимущество». Может оказаться, что преимущества нет.

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

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

Про Denver - таки это не vliw в чистом виде, он больше на superscalar походит (они его, собственно, так и позиционируют). По ссылкам не понял почему выигрыш сомнителен. Там где SPEC2000 - выигрыш есть, и учитывая характер каждого теста цифры вполне ожидаемы. Но там сравниваются совершенно разные процессоры, так что вообще непонятно как цифры интерпретировать, разве что K1-32 медленнее чем K1-64 на данных тестах. Единственное что - меня низкий IPC смущает. По второй ссылке - вроде неплохо держится. Можешь пояснить что ты имел ввиду?

alexanius ★★
()
Ответ на: комментарий от user_id_68054

Т.к. мне лень смотреть что конкретно они там сделали, просто расскажу про if-else. Они медленные всегда и на всех архитектурах. Просто методы борьбы с этим разные. В Интелах есть OoO и branch prediction, во VLIW - спекулятивность и предикаты.

alexanius ★★
()
Ответ на: комментарий от trycatch

Изначально я указал что нельзя заявлять что динамическая планировка строго лучше статической, все с этим согласились (надеюсь), так что не пойму о чём вообще спор.

И кстати, статическая и динамическая планировка - это вещи не взаимоисключающие. Сравнивать нужно не статическую vs динамическую, а статическую vs статическую+динамическую планировку.

Полностью согласен. Просто мой опыт подсказывает что если компилятор изначально не был заточен на VLIW, то перестановку инструкций он делает гораздо менее агрессивно.

LLVM даже учитывает размер reorder буфера в своей модели машины для планировщика: http://llvm.org/docs/doxygen/html/MCSchedule_8h_source.html#l00142 VLIW здесь не получает ни малейшего преимущества. Он только потеряет достоинства.

Для vliw сделать reorder сложнее чем для superscalar. Не, я на самом деле был бы рад reorder'у для Эльбруса (типа как у итаника), но пока что имеем то что имеем.

alexanius ★★
()
Ответ на: комментарий от alexanius

Пока не сравнил - не делай заявлений вроде «имеет преимущество». Может оказаться, что преимущества нет.

«имеет преимущество» != всегда лучше.

Еще раз: преимущества может не быть.

Про Denver - таки это не vliw в чистом виде

В чистом или грязном, но это VLIW:

«Internally Denver executes instructions using the Very Long Instruction Word (VLIW) format»

А то, что он суперскалярный, работу бинарного транслятора только облегчает.

По ссылкам не понял почему выигрыш сомнителен

Почему - никто точно не знает. Но, судя по измерениям, он сомнителен:

«Unfortunately, even in benchmarks where the DCO should be able to easily unroll loops to achieve massive amounts of performance, we see inconsistent performance in Denver.»

«Consequently we find that Denver’s SunSpider performance is quite poor – underperforming even the A15-based Tegra K1-32 – while Denver passes even the iPad Air 2 in Kraken.

Ultimately this kind of inconsistent performance is a risk and a challenge for Denver.»

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

Программный планировщик просто проще в реализации и, на некоторых задачах, может быть эффективнее динамического. ИМХО этот спор просто не имеет смысла.

anonymous
()
Ответ на: комментарий от uin

http://jpbempel.blogspot.ru/2013/09/null-check-elimination.html
Так что закатись откуда выкатился.

проделал что делается в статье (через java8-openjdk-hsdis ) — но дизасемблированный код получается не такой как в статье.. сходу мне там не всё ясно (есть отсылка к адресам, ассемблерный код по которым не печатается на экран, ды и не ясно что обозначают все эти инструкции :-)) — но есть основание полагать что устаревшая (проприетарная) версия JavaHotSpot работает не так как обычная..

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от Xintrea

Ну с десяток, вернее так - прод 10ток (со всеми балансирами и прочим барахлом), DR - 10ток, Staging - 10ток. Итого куда растолкали 100 машин ?

robot12 ★★★★★
()
Ответ на: комментарий от alexanius

про if-else. Они медленные всегда и на всех архитектурах. Просто
методы борьбы с этим разные. В Интелах есть OoO и branch prediction

вот эти вот out-of-order execution и branch prediction — они ведь работают в динамическом режиме? (то есть код остаётся нормальным кодом — просто Интел выполняет его не совсем так как скомпилировал компилятор? но учитывает atomic_thread_fence )

а в случае Эльбрусов — вся говнооптимизация должна производиться компилятором? либо программистом (когда у компилятора уже не хватит запаса хитрости).. порождая извращения указанных выше маштабов

user_id_68054 ★★★★★
()
Ответ на: комментарий от tailgunner

Вывод о том, что ниша будет расширяться, взят явно из астрала.

так же как и твоё предположение об этом выводе

argin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.