LINUX.ORG.RU

Представлен МП21 — одноплатный компьютер на базе процессора «Эльбрус-2С3»

 , ,


0

4

ИНЭУМ им. Брука (входит в холдинг «Росэлектроника» Госкорпорации Ростех) выложил в разделе промышленных компьютеров информацию о новом одноплатном компьютере на базе процессора «Эльбрус-2С3». Материнская плата имеет размеры менее 10x10 см.

Данная разработка маркируется как МП21 (ТЕГР.467144.004). Работает на базе полноценного двухъядерного процессора «Эльбрус-2С3» с тактовой частотой 1600 МГц. Оперативная память стандарта DDR4 (ECC) объёмом 8 ГБ распаяна прямо на плате, и использует один канал SDRAM. Для удешевления, под нужды заказчика, имеется возможность поставки платы с 4 Гб ОЗУ.

На борту платы находится следующее оборудование:

– Видео — два HDMI (разрешение до 4096х2160 60Гц), двухканальный LVDS (разрешение до 4096х2160 30Гц), аппаратное ускорение DirectX 10, OpenGL 3.2, OpenGL ES 3, Vulkan 1.0, OpenCL 1.2, OpenVX 1.x, — аппаратное ускорение де/кодирования VP9, H.264, H.265, VC1, MJPEG;
– 2 канала Ethernet 10/100/1000 Мбит/с (второй канал через дополнительный разъем XP1);
– 8 портов USB 2.0 с поддержкой скоростей HS, FS и LS;
– 4 порта USB 3.0;
– 2 порта SATA 3.0;
– 2 порта UART (LVTTL уровня);
– интерфейс SPI;
– интерфейс I2C;
– интерфейс SMBus;
– интерфейс PCI Express 3.0*;
– аудио ввод/вывод – HDAudio;
– 8 линий ввода/вывода общего назначения (IO);
— Часы реального времени с возможностью питания от внешней литиевой батареи;
— Сторожевой таймер – внутренний, с возможностью программного управления;
– интерфейс модуля – COM Express Module Type 6.

Заявляются следующие эксплуатационные характеристики:

— Электропитание от источника постоянного тока 12В или +12В/+5В_SB;
— Потребляемая мощность не более 40 Вт;
— Рабочая температура от минус 40 до плюс 55 °С;
— Масса не более 100 г (без теплораспределительной пластины).

МП21 является полностью российской разработкой, прошел весь цикл испытаний и готов к серийному производству. В настоящее время это самое миниатюрное решение на базе процессора «Эльбрус-2С3».

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

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 11)

Ответ на: комментарий от krasnh

Эльбрус-3 был не на кремнии и Cray был не на кремнии. То, что в итоге быстро переключились на кремний очень и очень хорошо. Это реально хороший опыт и развитие отечественных компетенций.

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

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

Условные инструкции конвейер не сбрасывают.

В случае VLIW и подготовленные переходы конвейер не сбрасывают. Но сам переход достаточно дорогой в тактах.

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

И чё? Ограничение даёт железнодорожный габарит.

Расскажете как первая ступень Н1 влезла на ЖД?

Во-первых, не всегда и не так.

На момент разработки Р7 это было так.

Во-вторых, ну увязали четыре камеры в один блок, как это повлияло на облик ракеты? Да никак.

4х камерник вообще то радикально ниже 1но камерника с той же тягой, и это была просьба конструкторов уменьшить верт габарит двигателя, дальше с DDT просто звезды сошлись. Вам не стыдно демонстрировать полное незнание азов истории разработки самого знаменитого РН СССР? И это мы ещё про связь особенностей компоновки и конструкции старта не говорили…

мне как конструктору, абсолютно фиолетово, как устроен двигатель

Если в Ваши обязанности входят только заточка карандашей и заваривание чая то да.

делали и большей тяги и большего размера

Но не на момент проектирования Р7! Тут Вы уже традиционно демонстрируете полное незнание матчасти, неумение следить за ходом дискуссии и вообще неумение логически мыслить, поскольку путаете причинно-следственные связи. Хотя о чем я, все время забываю что Вы циклограмму не асилили:-(

Привет Вам из родных пенатов - корпуса РКК Энергия видны из окна моей кухни, бггг.

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

Для начала я бы тебе посоветовал не использовать слово «совок».

По существу не хочешь обсудить проблему?

Но ты можешь подумать почему.

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

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

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

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

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

Что будем делать с твоими кулсторями про аварийность Сатурна, знаток?

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

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

Разница в том, что копировали машины целиком и перестали вкладываться в НИОКР. Я предлагаб вообще другое: взять архитектуру, а микроархитектуру разработать свою. Получится НИОКР с совместимостью.

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

Во вливе вам не нужны переходы и подготовки к ним.

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

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

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

monk ★★★★★
()

Вкину-ка еще немного занятных ссылок о том, как действительно обстоят дела с перспективами эльбрусов:

Мы думали: ну, сделать 32 цуга – и будет у нас настоящий параллелизм! Но я допустил тогда ошибку. Я подумал, что это очень сложно, а ведь есть подход попроще – подход широкой команды. Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…

Собственно, на этом в спорах о перспективности VLIW общего назначения можно ставить точку.

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

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

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

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

Шкафы - это и не общее назначение. Бабаян говорит об ошибке, сразу сравнивая подход с итаниумом, то есть речь шла именно о кремниевом чипе.

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

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

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

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

Мне кажется все (как обычно) идёт по пути наименьшего сопротивления - оказалось что повышать производительность железа проще чем писать хороший код, ну и мы оказались там где оказались…

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

Здесь бывший сотрудник МЦСТ поясняет за проблемы текущего подхода

Он вообще странный. Заявляет, что Эльбрус-8СВ медленнее, чем Эльбрус-R2000 несмотря на реальность.

как действительно обстоят дела

Это не как обстоят, а что думают люди по поводу того, как обстоят дела.

А Дональд Кнут говорит о том, что подходящий компилятор для VLIW общего назначения вообще невозможно написать

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

Ведь мы тогда минусов не знали этой широкой команды…

Так у него единственный заявленный минус:

Мы поработали с этим и поняли, что это тоже не блестяще, потому что используется статическое планирование.

Разгромное мнение Линуса Торвальдса по поводу VLIW вообще и Itanium в частности.

У него два безосновательных утверждения:

The whole damn architecture was entirely based off the basic incorrect premise that OoO is expensive.

because even a small instruction scheduling window would have done a better job than what you can do statically (because of dynamic behavior wrt any control flow what-so-ever, even unconditional branches like function calls).

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

Чем не общее? Самое что ни на есть, когда другого и нет.

Интел вообще пророчил, что 64 разряда станут итаником, если бы амд не подсуетилось, так бы оно и было. Опплевались бы на влив раньше, раньше пересели бы на арм.

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

Заявляет, что Эльбрус-8СВ медленнее, чем Эльбрус-R2000

Процитируй.

Это не как обстоят, а что думают люди по поводу того, как обстоят дела.

Факты перечислены, выводы сделаны. Особенно занятно про закат солнца вручную.

Приведи пожалуйста, цитату.

I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the «Itanium» approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.

Мы поработали с этим и поняли, что это тоже не блестяще, потому что используется статическое планирование.

Это буквально краеугольный камень VLIW.

У него два безосновательных утверждения:

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

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

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

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

Чем не общее? Самое что ни на есть, когда другого и нет.

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

Опплевались бы на влив раньше, раньше пересели бы на арм.

Вряд ли. Я думаю, оно бы само умерло естественным путем, потому что коммерсы не съели бы тормоза и дороговизну адаптации софта под итаниум даже взамен на 64 бита.

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

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

Процитируй

Вот:

Как видно, VLIW-процессоры на тех же нанометрах, имеют меньшие тактовые частоты, при этом имеют более высокое тепловыделение и больше транзисторов.

В итоге VLIW процессоры проигрывают не только по микроархитектурной скорости в пересчёте на Герцы, но и по самим частотам.

В таблице R2000 на 2ГГц и 8СВ на 1,5ГГц. При этом скорость на ядро у 8СВ вдвое выше.

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

Это буквально краеугольный камень VLIW.

Это так. Но у МЦСТ достаточно хороший компилятор Си удалось написать. Поэтому не «невозможно», а «Intel не смог» (скорее всего, денег на побочный проект зажал).

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

Опплевались и умерло бы, только гораздо громче и в масштабе всего мира.

Так или иначе, Бабаян…

Старый человек, у которого несмотря на все свои недостатки, все дома. Он же у нас в ответе за всё, как пионер. Если бы он сказал, что тогда подход был правильным, его бы сейчас со всеми специями съели. Вот и возводит на себя напраслину. Ошибкой был не влив, а то, что его вовремя не закопали. Только альтернативы долго не было. Спарк тоже проблемный по производительности, где-то читал об этом, но не воспроизведу. Риск5 возник только сейчас, своих аналогов не сделали.

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

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

В случае VLIW и подготовленные переходы конвейер не сбрасывают. Но сам переход достаточно дорогой в тактах.

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

Вообще, я думаю, если высокую латентность памяти ещё можно победить, например, тем же vectorized instruction pointer, то вот узкую шину, без увеличения кешей, в текущих реалиях непонятно как побеждать (всякие там HBM и пр - это да, но это не сегодняшний день). Соответственно, можно попробовать свести вопрос к тому, что лучше: потратить место на кристалле на аппаратные планировщики, или потратить его же на доп кеши…

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

В таблице R2000 на 2ГГц и 8СВ на 1,5ГГц. При этом скорость на ядро у 8СВ вдвое выше.

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

Но у МЦСТ достаточно хороший компилятор Си удалось написать. Поэтому не «невозможно», а «Intel не смог» (скорее всего, денег на побочный проект зажал).

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

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

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

При этом проц целиком жрет в три раза больше

Так мы скоростью или ваттами меряемся. Лучшие чипы это АРМ и Атом?

и у него всё хуже с параллелизмом, чем у R2000

С чего это? На 8 потоках всё то же опережение на распаковке больше чем в два раза при меньшей тактовой частоте.

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

Вот и возводит на себя напраслину.

Дедушка умеет признавать ошибки :)

Ошибкой был не влив, а то, что его вовремя не закопали.

Вот да.

Только альтернативы долго не было.

Верно, но RISC-V появился еще в 2010. Даже если взять какой-то временной гэп, то МЦСТ продолжал долбиться лбом в стену почти десять лет.

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

Зато я воспроизведу, пушто люблю спарки, у меня дома даже вот такая штука стоит для души. Если кратко, то у них низкая производительность на одно ядро, как в принципе и у многих RISC. А софт в те времена писался в основном однопоточный, и средства параллелизма были не особенно развиты. В итоге их воспринимали как тормозные печки. В современном мире софт пишется иначе: все что можно бьется на потоки, поэтому слабость отдельного RISC-ядра уже не является такой большой проблемой. Пример выше про сравние эльбрусов R2000 и 8СВ наглядно это демонстрирует.

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

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

Так мы скоростью или ваттами меряемся. Лучшие чипы это АРМ и Атом?

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

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

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

Вот на актуальной версии:

.L278:

        {
          subs,0,sm     %r9, 0x1, %g16
          stw,2 %dr0, %dr5, %r8 ? ~%pred0
          stw,5 %dr0, %dr2, %r10 ? ~%pred0
          pass  %pred0, @p0
          pass  %pred1, @p1
          landp ~@p0, ~@p1, @p4
          pass  @p4, %pred3
        }

        {
          ldw,0,sm      %dr0, %dr4, %g17
          pass  %pred2, @p0
          pass  %pred3, @p1
          movep @p1, @p0, @p4
          pass  @p4, %pred1
        }

        {
          cmplsb,0,sm   %g16, 0x0, %pred2 ? %pred3
          addd,1,sm     0x0, %dr7, %dr5 ? %pred3
          adds,2,sm     0x0, %g16, %r9 ? %pred3
          addd,3,sm     0x0, %dr4, %dr2 ? %pred3
          addd,4,sm     %dr6, 0x4, %dr7 ? %pred3
          addd,5,sm     0x0, %dr6, %dr4 ? %pred3
        }

        {
          adds,0        %r3, 0x1, %r3 ? ~%pred3
          subd,3,sm     %dr6, 0x4, %dr6 ? %pred3
        }

        {
          cmplesb,0,sm  %g17, %r10, %pred0 ? %pred3
          adds,1,sm     0x0, %g17, %r8 ? %pred3
        }

        {
          ct    %ctpr1 ? %pred3
        }

Уже 6 тактов. А не 13.

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

Дедушка умеет признавать ошибки :)

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

Верно, но RISC-V появился еще в 2010.

Были и другие, но выстрелил он. И предвидеть подобное сложно и большие проекты так не работают. Начало в 20м было бы очень хорошим и не сказочным вариантом. Остаются надежды благодаря двум другим отечественным конторам с риском.

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

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

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

Уже 6 тактов. А не 13.

Это уже не имеет значения. Важен сам подход.

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

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

Имеет смысл отношение производительности на транзистор. Кристалл конечен, а электростанцию и построить можно

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

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

Тогда бы вместо ксеонов на серверах стояли бы кластеры из Intel Atom.

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

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

А я не считаю это ошибкой.

Будешь спорить с Бабаяном, который сам уже поставил крест на VLIW? :)

Как говориться - если бы я был такой же умный, как моя жена потом.

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

Были и другие, но выстрелил он. И предвидеть подобное сложно и большие проекты так не работают.

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

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

Что-то микроархитектурное наверняка.

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

а электростанцию и построить можно

Я помню, как еще в начале десятых ДЦ-держатели выли в Москве от недостатка электропитания. Не забывай о стоимости всего этого предприятия, и о стоимости железа, а еще плотности упаковки в ДЦ. При сходной производительности может вполне получиться так, что датацентр на RISC будет в два раза меньше, чем на VLIW.

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

Тогда бы вместо ксеонов на серверах стояли бы кластеры из Intel Atom.

Ты уверен, что твой кластер из атомов будет кушать столько же, сколько ксеон, при схожей производительности? :)

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

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

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

Зачем спорить? Он хитрый армянин, и я понимаю о чем и почему он говорит.

Конечно можно открыть вакансию пророка, но кандидатов с успешным опытом маловато, закрыть сложно.

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

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

Уже сейчас есть код, для которого статическая оптимизация лучше динамического OoO от интел.

#include <stdio.h>
#define REP 100000
#define N 10000 

void f0(int*p) 
{ 
  *p = (*p)* (*p) + 1; 
} 

void f1(int*p)
{ 
  *p = (*p)/ ((*p) * (*p) + 1); 
} 

void f2(int*p) 
{ 
  *p = (*p)<<((*p) & 31); 
} 

void f3(int*p) 
{ 
  *p = (*p)+ (*p)<<1 + (*p)<<7 +(*p)<<4; 
} 

void f4(int*p)
{ 
  *p = (*p)^ (int)( (*p) * 0.42); 
} 

void f5(int*p) 
{ 
  *p = (*p)% 17; 
} 

int r[N]; 

void sample(int i) 
{ 
  f0(&(r[i])); 
  f1(&(r[i+1])); 
  f2(&(r[i+2])); 
  f3(&(r[i+3])); 
  f4(&(r[i+4])); 
  f5(&(r[i+5])); 
} 

int main() 
{ 
  int i,k; 
  for (i=0; i<N;i++) 
    r[i]=i; 

  for (k=0; k<REP; k++) { 
    for (i=0; i<(N-5); i+=6) { 
      sample(i); 
    } 
  } 
  printf("%10i\n",r[0]);
  return (int)r[0];
}

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

Но вариантов синтаксических конструкций не так уж и много.

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

Уже сейчас есть код, для которого статическая оптимизация лучше динамического OoO от интел.

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

То есть это буквально подтверждает мои тезисы, и тезисы экс-МЦСТшника по ссылкам.

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

Сразу видно, вы не участвовали в циклопических проектах. Сделать можно всё, пока не пошатнуться физические принципы. На этом этапе подумать и сделать ещё чуть больше. Деньги это фигня. ДЦ частники

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

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

Его забросили не просто так.

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

Сразу видно, вы не участвовали в циклопических проектах.

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

Деньги это фигня. ДЦ частники

Для частников как раз деньги - это главное.

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

Главное, чтобы потом вот так не получилось. А то там тоже строили-строили, и достроились до того, что уже сами не знают, как из этого неуправляемого болота вылезти.

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

А десятый когда будет? Или уже был?

ya-betmen ★★★★★
()
Ответ на: комментарий от liksys

С каждой новой версией компилятора, доля кода, который эффективно компилируется без переписывания вообще, растёт.

Тот же PostgreSQL, который тестировали Сберовцы, был с изначальными исходниками. Работал достаточно эффективно.

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

С каждой новой версией компилятора, доля кода, который эффективно компилируется без переписывания вообще, растёт.

Как я и говорил, это бесконечный процесс. См. Кнута и остальных.

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

Нет. Обычные компиляторы не занимаются настолько глубокими оптимизациями, потому что это делает процессор.

А вот еще одна занятная статья:

Спикеры от МЦСТ заявляли, что предсказатель ветвлений планируется к реализации в новых версиях Эльбруса, а аппаратный префетчер чуть ли не уже реализован (правда, никакого упоминания об этом в публичных спецификациях я не нашёл). Ну и не могу не отметить, что озвученные улучшения – это первый шаг к отходу от концепции статического планирования, сделанного «умным» компилятором.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.