стань автором. присоединяйся к сообществу!
Добавить новость можно всем, без премодерации, только регистрация
Лого Сделано у нас
205
kerosene 02 июля 2017, 06:07 Электроника, электротехника и приборы

Эльбрус-8С: результаты теста SPEC CPU 2006

Следи за успехами России в Телеграм @sdelanounas_ru

На стратегической сессии «РОССИЙСКИЕ АППАРАТНО-ПРОГРАММНЫЕ РЕШЕНИЯ» представитель МЦСТ Константин Трушкин представил результаты теста SPEC CPU 2006 для микропроцессора «Эльбрус-8С».

SPEC INT 2006: 13.03

SPEC FP 2006: 17.02

Так же докладчик осветил текующие разработки микропроцессоров в МЦСТ:

В 2018 году ожидается выход SPARC-совместимого 8-ядерного микропроцессора МЦСТ-R2000 с частотой 2 ГГц и микропроцессора «Эльбрус-8СВ» (Эльбрус-8С2) с частотой 1,5 ГГц и увеличенной вдвое разрядностью блоков операций с плавающей точкой.

В 2020 году планируется выход 2-ух микропроцессоров:

2-ядерного Эльбрус-2С3 с тактовой частотой 2 ГГц, встроенным 3D-GPU и пониженным энергопотреблением.

А так же 12-ядерного микропроцессора «Эльбрус-12С» для настольных систем.

В 2021 году планируется выход 16-ядерного микропроцессора «Эльбрус-16С» с тактовой частотой 2 ГГц, встроенным южным мостом с поддержкой интерфейсов PCI-Express 3.0, USB 3.0, SATA 3.0 и контроллером памяти с поддержкой DDR4-3200. Пиковая производительность нового микропроцессора 768 Гфлопс на двойной точности и 1536 Гфлопс на одинарной. Предполагаемое энергопотребление не выше 100 Вт.

Кстати, а вы знали, что на «Сделано у нас» статьи публикуют посетители, такие же как и вы? И никакой премодерации, согласований и разрешений! Любой может добавить новость. А лучшие попадут в телеграмм @sdelanounas_ru. Подробнее о том как работает наш сайт здесь👈
Источник: https://www.youtube.com/watch?v=efTEB5ija0c

Вступай в наши группы и добавляй нас в друзья :)


Поделись позитивом в своих соцсетях

Другие публикации по теме


МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
  • 46
    Holso Stitchred Holso Stitchred
    02.07.1709:03:00

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

    #928149 ↑
    • Комментарий удален
  • Комментарий удален
  • 20
    Нет аватара guest
    02.07.1709:33:30

    Эльбрус-8С (1300 MHz, 8 cores) — 13,03/17,02

    Уровень производительности соответствует (int/fp):

    Intel Xeon processor X5355 (2667 MHz, 8 cores) — 16.0/16.9 (2006г)

    AMD Opteron 6164 HE (1700 MHz, 12 cores) — 14.2/19,5 (2010г)

    Fujitsu SPARC Enterprise M3000 (2750 MHz, 4 cores) — 13,6/15,2 (2010г.)

    Отредактировано: ksey~09:36 02.07.17
    #928156 ↑
    • Комментарий удален
    • 35
      Нет аватара Евгений Медвежонков
      02.07.1711:05:34

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

      #928174 ↑
      • 0
        Нет аватара login_nigol
        05.07.1719:26:12

        Я живу «быстро» и «тупняки» разныx платформ просто убивают иногда. Бывает так: Оффис+firefox и не важно что i7+4гб — кавОто думает там по 10 минут. Что там не так с тактами? Кофе можно попить…7-ка, 8.1, CentOS, Linux…Какая разница спотыкания те же… Процессор AMD вообще ненавижу — «костыли» какие то постоянно. Так что вся надЁжа на восстановление нашиx старыx добрыx КР580!!!

        #929357 ↑
        • 0
          shigorin shigorin
          26.10.1820:51:08

          Это, скорее всего, «заслуга» 4 Гб памяти, а не i7. С аппетитами нынешних браузеров своп на SSD тоже не шибко спасает при недостатке памяти, да и флэшке он страшен…

          PS: у меня альт на e2k и x86_64    

          #1080142 ↑
    • 28
      Сергей Галин Сергей Галин
      02.07.1711:29:51

      У меня вот работает Athlon 64 с производительностью порядка 10 этих попугаев и на нём до сих прекрасно работает офисный и графический софт, и игрушки середины-конца нулевых, и для файлопомойки или внутреннего вебсервера тоже мощности навалом. Или можно под Линуксом запустить две виртуалки с виндами и всё это нормально шевелится. По сути, мощнее числогрызка нужна только для C+±программистов и для современных игрушек. А для больших серверов и суперкомпьютеров мощность может наращиваться увеличением числа процессоров. Так что можно сказать, что Эльбрус, в теории, уже удовлетворяет потребностям большей части пользователей. Вот бы ещё доступность железки подтянуть, чтобы её можно было за углом в каком-нибудь ДНС купить и по цене того же порядка, что и Интел (ну пусть даже будет вдвое дороже за камень той же мощности).

      #928178 ↑
      • Комментарий скрыт по причине низкого рейтинга. показать
        • 1
          Нет аватара nik.f
          03.07.1706:58:14

          Windows XP и 1024×756 у меня бегало еще на Пентиум 2 300МГц.

          #928446 ↑
          • 2
            krotozer krotozer
            03.07.1710:09:03

            У меня — на Pentium III 650 MHz, разогнанном по шине со 100 MHz на 133 MHz, что автоматом погнало т.н. «эффективную» частоту до 866 MHz. Ко всему этому стояли не самые «тухлые» кингстоновские планки по показателям таймингов суммой на 512 MB. Всё дальнейшее — оптимизация настроек ОС. Windows XP была всех вариаций ServicePack по очереди. Вполне хватало для всех задач, включая виртуалки. На этой машине успешно имитировался домен ActiveDirectory на базе Windows 2000 с одним сервером и тремя клиентами.

            .

            Тогда же ещё не было такого идолопоклонничества перед интерпретируемыми языками, серьёзное ПО писалось на C/C++, «дельфисты» ещё не лезли в ВЕБ, а нынешние помешанные плебеи-раздолбаи (свидетели «ВЕБДВАНОЛЯ») ещё в школу ходили и мир IT ещё не замусоривали своими поделками под браузер на интерпретируемых языках любых разновидностей.

            .

            Это всё — к вопросу о производительности «Эльбрусов». ИМХО, они уже пригодны для большинства задач. А если за бугром DE затачиваются под топовые процессоры Intel, то это — благодатный повод для наших доработать любое «легковесное» DE.

            #928487 ↑
            • 0
              Нет аватара nik.f
              03.07.1721:21:32

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

              Кстати книжка «Интернет разработка в Delphi 2.0» у меня до сих пор где-то на полке валяется, на cgi/isapi/nsapi был в свое время бум, как-то раз пришлось даже переписывать с нуля труды какого то сишника). Ныне приходится писать на сях включая объектные (embedded и mac), до сих пор плююсь).

              .

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

              #928702 ↑
              • -1
                krotozer krotozer
                03.07.1722:31:08

                Действительно из разных миров. Я сочетание C++ и MFC вообще не воспринимаю за программирование GUI никоим образом! Никаких, Боже упаси, корявых недостроев от «мелкомягких»! Про MFC вообще только в страшном сне вспоминать. Даже УбогоШарп лучше. Нормальный серьёзный софт на C/C++ должен быть кроссплатформенным.

                скриптовые языки разного рода ибо позволили создавать продукт в разы быстрее, а значит и дешевле
                — РОЗГАМИ ПОРОТЬ!!! Р-О-З-Г-А-М-И-!!! От этой философии бизнеса — все проблемы современного софта! Вот бизнесменов, пропихивающих жирные средства разработки под лозунгами «быстрее и дешевле», розгами пороть надо, как «сидоровых коз»! А то, ишь, распоясались!)

                Кстати книжка «Интернет разработка в Delphi 2.0» у меня до сих пор где-то на полке валяется

                У меня на полке стоит книга «Руководство по программированию под управлением MS-DOS». В ней программисту приведён даже справочник прерываний ОС, позволяющий максимально гибко распоряжаться ресурсами системы. В идеале — из-под Assembler-а. А кто не жалеет ресурсы, того… РОЗГАМИ!!!

                Ныне приходится писать на сях включая объектные (embedded и mac), до сих пор плююсь).

                Может тогда это не Ваше (программировать)? Может вообще тогда не стоит? Эх… Как же нехватает жёсткого планового контроля, чтоб НАХРЕН запретить всё это МРАКОБЕСИЕ, что нынче творится в сфере разработки ПО…

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

                А потом оно жрёт как трактор… Блин, этот бизнес лечить надо касторкой в причинное место! И, ведь, каждый горазд оправдывать свою лень словами, вроде, «быстро и дёшево».

                Собственно благодаря подобным вещам и произошло такое взрывное развитие отрасли.

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

                Отредактировано: krotozer~22:35 03.07.17
                #928724 ↑
              • 1
                krotozer krotozer
                03.07.1722:53:33

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

                .

                Я и в самом деле горько сожалею, что чистое, максимально приближенное к платформе программирование на «сях» теперь загоняют «за Можай». Даже ОС кинулись писать на языке go… Печаль, в общем…

                .

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

                .

                Но нет, детки выросли, детки привыкли, что у компа есть Гигагерцы и Террабайты. Они уже и незнают, что «модем» — это не 3G/4G-донгл, а устройство, модулирующее цифровой сигнал в телефонную линию по голосовому каналу.

                .

                Вот это всё печалит. Очень сильно печалит…

                #928732 ↑
                • 0
                  Нет аватара nik.f
                  06.07.1700:58:58

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

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

                  Раньше тоже было нытье, что писать на фортране не тру, вот когда ты с помощью перфокарты контролируешь каждый регистр… А до этого тоже было нытье, ведь можно было собрать любую схемы на логике, куда эффективнее, чем все эти ваши универсальные процессоры…

                  Зы.

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

                  #929473 ↑
                  • 0
                    krotozer krotozer
                    06.07.1713:43:35

                    Вы мыслите как кодер, выдумывая байки про лень… [до конца абзаца]

                    Ох… Ну вот я и получил ярлык, не соответствующий правде. Неужели трудно догадаться, что речь идёт не праве языков на жизнь, а о способе решения проблем? JavaScript — хорош как… скрипт. Java — хорош, как язык для управляющей логики. C++ - хорош для системного программирования и решения ресурсокритичных задач. C — хорош как язык для расчётов и процедурного программирования на уровне драйверов. Так же можно рассказать и про другие языки.

                    .

                    Но мода нынешнего поколения — брать мейнстрим и ВСЁ переводить на него. Такие решения, ведь, принимаются больше на амбициях и желании выпендриться, чем от высокого ума. В итоге они изобретают велосипеды… А потом порождают целый стек велосипедов… И так до тех пор, пока не появится новый язык программирования, и его адепты не начнут тянуть одеяло на себя.

                    .

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

                    .

                    Я работаю над достаточно нагруженным проектом, задача которого нормально работать на не самом свежем «железе». Объём данных через ПО проходит отнюдь не малый. Приходится реализовывать и сжатие, и своп и другие механизмы, больше свойственные ОС, чем прикладному ПО. Аккуратная абстракция, ограничение уровней вложенности, деление кода по задачам, и… C++ превосходно подходит для всего этого! Тот же самый проект писать, скажем, на Java — это материться десятиэтажным матом, т.к. в языке нету нормального контроля за памятью. Это страшно неудобно!

                    .

                    Если Вы так выступаете за современность, то покажите мне язык, на котором я могу контролировать каждый байт и не плодить объекты, если они уже есть в памяти? Уж поверьте: это критично!

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

                    Какраз-таки C/C++ и компилируется LCC. А всё остальное садит Эльбрус к чертям, т.к. порождает уйму процессов переключения контекста, что является его «ахилесовой пятой». Тот же Python на нём тормозит довольно сильно, тогда как код, написанный на «сях» работает быстрее остального.

                    в случае си — ограничения языка не предназначенного для подобного

                    Ну надо же))) А какой язык на Эльбрусе не требует костылей? Это же довольно нестандартная архитектура. И если речь о производительных библиотеках от МЦСТ, то суть решения проблемы — добавление их кода реализации по соответствующим функциям «стоковых» библиотек std. Чего не сделаешь с интерпретируемыми языками или завязанными на виртуальную машину. Там надо саму VM затачивать под Эльбрус, тогда как с «сями» этого делать почти не приходится.

                    Товарищ, ну Вы хоть почитайте, что ли…

                    перфокарты контролируешь каждый регистр

                    Задача переложена на Assembler.

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

                    Это до сих пор актуально. Спросите у разработчиков процессоров. Не универсальных, а узко заточенных решений. Там вся логика влезает в один чип, который потребляет в РАЗЫ меньше, чем любой универсальный чип с его обвязкой. Просто теперь это делается для решений, что продаются большим тиражом. Раньше это делалось почти для всего. Изменилась технология изготовления, сменился градус доступности рукоделия, которое теперь заменено на проектирование схем в специальных программных эмуляторах.

                    Отредактировано: krotozer~13:43 06.07.17
                    #929678 ↑
      • 2
        Нет аватара guest
        02.07.1718:40:27

        за углом в каком-нибудь ДНС купить

        Так приходит мирская слава.     Я ещё помню ДНС, когда это был подвальчик на Красного Знамени 59, в котором крутились двое бандитов и двое студентов.    

        #928286 ↑
        • 0
          Нет аватара guest
          03.07.1712:12:35

          Не бандиты, а коммерсанты    

          #928519 ↑
          • 0
            Нет аватара guest
            03.07.1715:36:29

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

            #928585 ↑
            • 0
              Нет аватара guest
              03.07.1715:40:22

              Да я в курсе)))

              #928587 ↑
    • 0
      RadiantConfessor RadiantConfessor
      03.07.1705:45:35

      Производительность указана на 1 физическое ядро!

      Отредактировано: Zveruga~05:46 03.07.17
      #928436 ↑
      • 2
        Нет аватара segfault
        03.07.1707:55:42

        Она для всех процессоров в этом тесте относится к одному ядру. Ибо тест отражает производительность на единичных заданиях. Чтобы оценить производительность процессора в целом, нужно брать SPECint_rate и SPECfp_rate.

        #928458 ↑
      • 0
        Нет аватара guest
        03.07.1708:43:54

        Разумеется. Вот цитата с сайта spec. org:

        The SPECspeed® metrics (e.g., the SPECint® 2006 ) are used for comparing the ability of a computer to complete single tasks.

        Данные для других процессоров я приводил для указанного теста.

        #928469 ↑
        • 1
          Нет аватара segfault
          03.07.1709:16:11

          Кстати, очень плохо, что МЦСТ не приводит данные о том, сколько ядер было задействовано при проведении теста. Ибо результаты SPECint и SPECfp при одном задействованном ядре всегда будут выше, чем на полной системе.

          #928474 ↑
        • 1
          Нет аватара guest
          06.07.1722:25:01

          Однако одна задача не означает одно ядро. Практически все результаты в режиме speed идут с разрешенным Auto Parallel, а это значит, что компилятор может задействовать сколько угодно ядер:

          Auto Parallel: Whether any bench marks are automatically optimized to use multiple threads, cores, and/or chips. Set this field to «yes» if at least one does so, and disclose in the flag descriptions or notes section which s and/or libraries are parallelized.

          Note 1: It is acceptable for library functions (e.g. math functions, strcmp, memcpy, memset, std:__find) to be used in a manner that allows them to spread their work across multiple hardware threads, cores, or chips. If one or more library functions are used in this manner, that counts as auto parallelization, for purposes of this field.

          Конечно, неизвестно был ли он включен в тесте Эльбруса

          Отредактировано: trawler~22:26 06.07.17
          #929918 ↑
    • 0
      Нет аватара vlTepes
      03.07.1709:31:47

      Ну приведите данные новых процессоров. Уже много лет производительность не растет.

      Потому и догнали.

      #928477 ↑
  • -8
    Alexander V Alexander V
    02.07.1710:54:26

    Почему от x86 архитектуры отказались? Intel и AMD как-то выпускают свои процессоры.

    Отредактировано: Alexander V~11:02 02.07.17
    #928170 ↑
    • 15
      Сергей Галин Сергей Галин
      02.07.1711:38:42

      x86 у нас последний раз делали, кажется, в первой половине девяностых, а потом сами знаете, что случилось. Эльбрус всегда поддерживал x86 только в режиме эмуляции. А вообще x86 сложная и неэффективная архитектура, которая тащит кучу наследия ещё с конца 70х и с приходом Windows 10 на ARM её будущее в долгосрочной перспективе под вопросом. Я бы задал другой вопрос, почему наши не делают ARM, которая на 2017 год является, наверное, самой массовой архитектурой в мире — ИМХО это бы позволило запрыгнуть в массовый рынок процессоров и поднять производство, а там уже можно и с Эльбрусом заходить.

      #928180 ↑
      • -3
        Alexander V Alexander V
        02.07.1711:43:48

        В режиме эмуляции сильно проседает производительность. Я так понимаю и Linux запускается в режиме эмуляции.

        #928181 ↑
        • 4
          Сергей Галин Сергей Галин
          02.07.1711:47:59

          Пишут, что есть порт Линукса на Эльбрус, который работает нативно. Но по интернетам не понятно, доведён ли он до годного к использованию состояния.

          Отредактировано: Сергей Галин~11:52 02.07.17
          #928183 ↑
          • 1
            Alexander V Alexander V
            02.07.1711:52:41

            Ну они говорили про совместимость х86 на 90%. Поэтому пришлось перепелить 10% кода ядра. Вот и закрались сомнения.

            #928185 ↑
            • 4
              krotozer krotozer
              02.07.1723:34:09

              На плате (слева снизу) имеется слот для CF-карты. На ней располагается байт-код, необходимый для бинарной трансляции кода x86 на собственный набор микрокоманд процессора. Макрокоманды он не тянет, этим занимается компилятор LCC. В общем-то, решение перевалить работу блока предвыборки на компилятор — это тот самый метод, что позволил процессору уверенно «плыть» в условиях ограниченного бюджета. Переделывать ПО — дешевле и проще, чем сам проц. Думаю, когда-то в будущем в составе процессора может появиться блок предвыборки. Научить компилятор собирать под такие процессоры — задача не сложная. Компиляция заметно ускорится. А может они напаяют на плату сопроцессор под эту задачу, кто знает…

              #928370 ↑
              • Комментарий удален
                • 0
                  Андрей Степанов Андрей Степанов
                  03.07.1707:13:42

                  Эльбрус на экспорт не идет, так что Интел не может ничего запретить.

                  #928448 ↑
                • 0
                  krotozer krotozer
                  03.07.1707:49:16

                  Частично программная поддержка трансляции. Сам процессор не содержит ничего, попадающего под американские патенты. Да и вообще, поддержка x86_64 — лишь вынужденная мера.

                  #928455 ↑
          • 3
            Нет аватара guest
            02.07.1718:42:34

            Давно доведён.

            #928290 ↑
            • 2
              krotozer krotozer
              02.07.1723:27:05

              Я бы так не сказал… Единого тулкита дистрибутива в нём всё ещё нет. Это — самосборный дистрибутив. Но МЦСТ тяготеет к «экосистеме» Debian, так что упомянутое «доведение» — дело времени, которого у МЦСТ не так уж и много. Хотите ускорить их работу? Сорганизуйте каутфайдинг в отношении МЦСТ. Они смогут нанять дополнительный персонал.

              #928364 ↑
              • 0
                Виктор Гюго Виктор Гюго
                03.07.1710:35:13

                Что такое «единый тулкит дистрибутива»? Что за зверь такой?

                #928492 ↑
                • 0
                  krotozer krotozer
                  03.07.1712:20:18

                  Самодумный термин. Как иначе обозвать весь инструментарий дистрибутива, навёрнутый поверх GNU/Linux, который отличает его от других дистрибутивов?

                  .

                  На т.н. «Эльбрус ОС» из пакетных менеджеров есть и Aptitude, и RPM, но своего репозитория нет, по крайней мере в открытом доступе. Так что, задача установки какого-либо пакета сводится к его сборки из исходников.

                  Отредактировано: krotozer~12:23 03.07.17
                  #928522 ↑
              • 0
                Нет аватара guest
                03.07.1711:30:28

                Думаю краудфандинг должны организовывать сами МЦСТ. Во первых потому что это их бизнес, а во вторых что бы не было варианта «собрал для МЦСТ и купил дачу на канарах».

                #928507 ↑
                • 0
                  krotozer krotozer
                  03.07.1712:27:11

                  У них нет специалистов в этой области. Иначе вопрос бы уже муссировался. А по поводу «дачи на Канарах»: ничто не запрещает заключить с крауд-менеджером договор об обязательствах и предъявить его электронную копию вкладчикам. Ясное дело, что это — договор на английском и русском языках, причём английский первичен, т.к. в РФ пока ещё нет законодательства, регламентирующего крауд-финансовые операции. Впрочем, не мне по этому поводу напрягаться-то)

                  Отредактировано: krotozer~12:27 03.07.17
                  #928526 ↑
                  • 1
                    Нет аватара guest
                    03.07.1712:55:37

                    ))) Ну мы все по этому поводу напрягаемся ))) переживаем потому что за них ) надеемся на их успех.

                    #928538 ↑
              • 1
                Нет аватара guest
                03.07.1715:41:28

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

                #928589 ↑
                • 0
                  krotozer krotozer
                  03.07.1718:00:46

                  Унификация, Сэр! Если предположить «полный юзерлэнд» военного назначения на основе Debian, то это значит, что «гражданские» скрипты и рецепты будут применимы для «починки» данной ОС. А так же все debian-зависимые узконаправленные scripted-tools, коих для «Бубунты» написали выше крыши. «Военная, в сущности, ось» уж слишком зависима от гражданских наработок)

                  #928651 ↑
                  • 0
                    Нет аватара guest
                    03.07.1718:43:45

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

                    #928663 ↑
                    • 0
                      krotozer krotozer
                      03.07.1722:06:41

                      Я? Ничего от этой «дистры» не хочу) Лишь рассуждаю на тему заданного выше вопроса. МЦСТ пусть делает так, как считает нужным. Да и вообще не являюсь ярым поклонником Дебиана, как могло бы показаться. Я — гентушник) Компиляция с флагами — наше всё)   

                      .

                      А с комрадом Шигориным мы ранее уже обсуждали дистру от МЦСТ. Надо сказать им спасибо за то, насколько дистрибутив сейчас является приближенным к стандартным. Всё не так уж плохо, в общем.

                      Отредактировано: krotozer~22:08 03.07.17
                      #928716 ↑
          • 6
            shigorin shigorin
            02.07.1722:57:28

            Работает, вполне доведён. Хотя недавно удалось воспроизвести для ребят багу в новых наработках по ядру на многопроцессорной конфигурации (мы купили сервер 4.4), но такие косяки и на интеле порой вылазят…

            #928346 ↑
          • 1
            Виктор Гюго Виктор Гюго
            03.07.1710:34:00

            Порт официальный, у Горшенина ролики выложены. www.youtube.com/channel/UC6pnRoVljXKpo5bgkVyQMJg/videos

            Так же Шигорин собирает ALT Linux под эльбрус. Никакой эмуляции, native, свой компилятор.

            #928491 ↑
            • 0
              shigorin shigorin
              26.10.1820:55:04

              Также Шигорин собирает ALT Linux под эльбрус

              Собственно, технически уже есть выпуск дистрибутивов Альт Рабочая станция и Альт Сервер ;-)

              #1080143 ↑
        • -4
          Нет аватара devorg
          02.07.1712:06:27

          Такого быть не может, просто потому что такого не может быть.

          #928189 ↑
        • 8
          Нет аватара kerosene
          02.07.1712:16:48

          Там не эмуляция, а система динамической трансляции кода x86 в родной код Эльбруса. Это сделано для обеспечения совместимости с тем софтом, для которого нет аналога в исходных кодах под Линукс. Сами же Эльбрусы работают под ОС «Эльбрус», в основе которой лежит ядро Линукс 3,14 и пакеты от Дебиан.

          #928193 ↑
        • 6
          Нет аватара guest
          02.07.1718:42:21

          Неправильно понимаете по обоим пунктам. Во-первых, совершенно необязательно, а во-вторых Линукс давным давно портирован на «родную» архитектуру.

          #928289 ↑
        • 5
          shigorin shigorin
          02.07.1722:56:26

          x86 не лицензируется (ответ со слов сотрудников МЦСТ).

          #928344 ↑
          • 0
            RadiantConfessor RadiantConfessor
            03.07.1705:47:55

            А что слова, в мире ещё кто-нибудь х86 производит? Нет.

            #928437 ↑
        • 1
          krotozer krotozer
          02.07.1723:21:02

          Компилятор LCC по формату управления является тем же GCC, потому он легко встраивается в окружение GNU. Собственно, сам GNU/Linux компилируется именно под этот процессор и работает на нём «нативно». Конечно стоит упомянуть ещё некоторые вспомогательные утилиты от МЦСТ и модули для ядра Linux. Но в основе своей это — такой же «Линух», как и все остальные дистрибутивы. Кстати, сейчас он пока что самосборный, а в будущем МЦСТ тяготеет к «экосистеме» Debian. Ещё надо упомянуть, что нативно под ним стартуют Astra Linux (Debian) и Alt-Linux (в некоторой степени — наследие «Mandrake», не «Mandriva»!).

          #928361 ↑
      • -5
        Нет аватара guest
        02.07.1712:59:39

        «x86 сложная и неэффективная архитектура"

        Хватит раздувать эти байки, х86 хорошая архитектура, как и АРМ, они ничем друг другу не уступают, если бы х86 был такой неэффективный, то АРМ бы его легко обошел, чего мы не наблюдаем, скорее они поделили рынок: x86 огромная производительность(странно да для «неэффективной» архитектуры), АРМ низкое энергопотребление.

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

        #928200 ↑
        • Комментарий удален
        • 7
          Михаил Усоцкий Михаил Усоцкий
          02.07.1716:26:49

          На самом деле данная архитектура действительно сложная. В новостях можно не раз увидеть статьи о серьёзных ошибках в декодере команд. Надо сказать, что декодер команд у x86/x86-64 самый большой из всех известных нам. Именно они расходуют очень много энергии. Снизить энергопотребление в таких процессорах зачастую прибегают к сохранению декодированных команд в кэше, либо снижением частоты, либо уменьшением техпроцесса. Но такие процессоры действительно производительные. Но зачастую это из-за особенностей систем команд RISC (ARM) и CISC(x86/x86-64). RISC-процессорам порой требуется больше действий за единицу времени, чтобы достать или положить в памяти данные.

          #928250 ↑
          • 8
            Нет аватара kerosene
            02.07.1717:24:12

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

            Отредактировано: kerosene~17:24 02.07.17
            #928262 ↑
            • 5
              Михаил Усоцкий Михаил Усоцкий
              02.07.1717:31:45

              Да, согласен, это тоже. Видел блок-схемы, где планировщик занимал значительное место после декодера. У Эльбруса ещё называется статическим планированием. Поэтому компилятор для Эльбруса довольно продвинутый. А у Intel, соответственно, динамическое.

              #928266 ↑
          • 0
            shigorin shigorin
            26.10.1820:56:30

            В новостях можно не раз увидеть статьи о серьёзных ошибках в декодере команд

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

            Да, мельдоний и спектр спектров…

            #1080145 ↑
        • 5
          Нет аватара guest
          02.07.1718:46:31

          Вообще-то примерно 2/3 площади кристалла у х86/х64 процессоров занимают схемы преобразования команд из входной архитектуры во внутреннюю RISC-систему. Причём они намертво связаны в единый блок с диспетчером, отвечающим за спекулятивное исполнение и набивку конвейеров, так что даже чтобы открыть внутреннюю систему команд, процессор надо полностью перепроектировать с нуля. У Эльбруса же исполнение строго последовательное, а расстановкой команд занимается компилятор, так что из всей этой машинерии там стоит только ассоциативный кэш с системой управляемой подкачки.

          #928292 ↑
          • 0
            RadiantConfessor RadiantConfessor
            03.07.1705:49:47

            У Эльбруса же исполнение строго последовательное, а расстановкой команд занимается компилятор

            И это главное преимущество Эльбруса. В итоге потреблять Эльбрус будет меньше чем х86 при той же производительности и на той же топонорме.

            #928438 ↑
            • 0
              Нет аватара guest
              03.07.1715:45:52

              Ну да, но всё упирается в эффективность компилятора. Неспособность Штеуда сделать нормальный компилятор, не забивающий конвейеры НОПами, и привела к кошмару Итаника.

              #928592 ↑
              • 0
                RadiantConfessor RadiantConfessor
                03.07.1718:38:35

                Дак и от эффективности аппаратного блока тоже всё зависит. Его тоже нужно сначала придумать, потом «откомпилировать» в Verilog и реализовать в железе.

                #928662 ↑
        • 7
          shigorin shigorin
          02.07.1722:59:41

          Это хреновая архитектура, которая держится исключительно «на штыках» огромного наследия приложений и передовой технологии (не путать с архитектурой) интела. Все x86 «в душе» уже много поколений как RISC с прилепленным сверху транслятором из CISC.

          #928349 ↑
      • 12
        Нет аватара guest
        02.07.1713:58:24

        Наши вполне делают ARM, Байкал Электроникс делает процессоры Baikal на архитектуре ARM.

        #928220 ↑
        • 0
          shigorin shigorin
          26.10.1820:58:45

          По факту в прошлом году Байкал всё-таки не выпустил армовый вариант (М на v8), но уже шёл мипсовый (T1). А так-то армами (v7) ещё несколько лавок занимаются -- Элвис, сосед вон мой…

          #1080146 ↑
      • 9
        Михаил Усоцкий Михаил Усоцкий
        02.07.1716:14:27

        Наши делают ARM-процессоры. Поищите про процессор Байкал. Только читайте внимательно. Байкалы могут носить как MIPS, так и ARM, в зависимости от модели.

        #928249 ↑
        • 5
          shigorin shigorin
          02.07.1723:01:29

          Я пока не видел даже инженерников Байкал-М (ARM64), в отличие от вполне существующего Байкал-Т1 (MIPS32).

          #928350 ↑
      • 4
        Нет аватара guest
        02.07.1718:41:28

        С конца?!! Там куча хвостов ещё от 8008/4004 висит на самом деле, а это 72 год.

        #928287 ↑
      • 0
        Виктор Гюго Виктор Гюго
        03.07.1711:23:56

        > почему наши не делают ARM

        Делают и MIPS и ARM. Но ARM специфическая архитектура, на ниве серверов и десктопов у неё очень небольшая полянка.

        #928504 ↑
    • Комментарий скрыт по причине низкого рейтинга. показать
      • 4
        Alexander V Alexander V
        02.07.1712:08:50

        С софтом, как быть?

        #928190 ↑
        • 5
          Нет аватара guest
          02.07.1714:36:29

          x86 эффективно работает благодаря многочисленным расширениям инструкций, которые являются собственностью Интел. Почитайте про то как Интел протестует против попыток Микрософт запускать x86-программы на ARM-процессорах. Так что если уж делать что-то свое, так свое. А софт — надо делать свой в первую очередь.

          Если уж развивать потребительский сектор, сейчас как раз самое важное — это не собственный процессор, а собственная ОС с поддержкой Windows-программ типа ReactOS, которую все пытаются на госуровень пробить и все как-то глухо.

          #928228 ↑
          • 4
            shigorin shigorin
            02.07.1723:02:26

            Хохма в том, что такая запускалка (exagear) уже сделана… бывшими сотрудниками МЦСТ. И да, работает    

            #928351 ↑
          • 2
            shigorin shigorin
            02.07.1723:03:13

            PS: попробуйте реактос. Серьёзно. А потом уже топите глупости в поддержку клона того, чему стоило сдохнуть в зародыше.

            #928352 ↑
          • 1
            krotozer krotozer
            02.07.1723:42:26

            Нынче появились методики, но этим нужно заниматься профессионалам в этой области. Т. е. каждый — своим делом. А вообще, тот ещё вопрос, нужно ли поддерживать Windows-приложения, если уже не всё старое ПО запускается под новыми версиями Windows? Может Вы не знали, но сейчас бухаются отнюдь не малые средства в разработку средств реинжениринга ПО при помощи нейронных сетей в исходный код.

            #928373 ↑
            • 1
              Виктор Гюго Виктор Гюго
              03.07.1711:28:39

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

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

              #928506 ↑
      • 13
        Сергей Галин Сергей Галин
        02.07.1712:41:23

        Странное противопоставление, ведь VLIW это развитие RISC, причём имеющее вполне определённые плюсы (железо проще и потребляет меньше энергии). Кроме того, VLIW прекрасно идёт по миру в GPU, DSP и прочих ембедах. CISC уже сдано много позиций RISC (точнее, ARM) именно из-за более сложного и прожорливого железа, а VLIW — ещё один шаг в том же направлении. Откуда такая уверенность, что это тупик?

        #928199 ↑
        • Комментарий скрыт по причине низкого рейтинга. показать
          • 9
            Дмитрий Тёмный Дмитрий Тёмный
            02.07.1716:08:28

            так умер Itanium, а не VLIW.

            Вон Silicon Graphics со своим MIPS (который вполне себе RISC) умер, PA RISC умер, Alpha умерла. Все они уступили x86, то есть можно сделать выводы что RISC — тупиковая ветка?

            #928246 ↑
            • Комментарий скрыт по причине низкого рейтинга. показать
              • 5
                shigorin shigorin
                02.07.1723:04:04

                Ох уж мне эти Данилы, ни хрена обобщать не научились.

                #928353 ↑
              • 1
                krotozer krotozer
                02.07.1723:43:53

                Вы, главное, верьте в это!    

                #928375 ↑
          • 8
            Нет аватара sarvizir
            02.07.1717:19:11

            Читайте про Itanium и поймете почему VLIW умер.

            Главное, Данила, чтобы вы читали.

            #928260 ↑
            • Комментарий скрыт по причине низкого рейтинга. показать
              • 8
                Нет аватара azurel
                02.07.1718:24:30

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

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

                 http://mcst.ru/files/5757...izatsii_predskazaniya.pdf 

                 http://www.mcst.ru/doc/130621/Shabanov.pdf 

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

                #928281 ↑
                • 0
                  krotozer krotozer
                  02.07.1723:48:57

                  Спасибо за целевые ссылки на материалы!

                  #928378 ↑
                • -1
                  Нет аватара guest
                  03.07.1710:20:35

                  Какие еще переходы? Это вообще не о том.

                  #928489 ↑
                  • 1
                    Нет аватара azurel
                    03.07.1710:58:47

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

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

                    #928498 ↑
              • 8
                shigorin shigorin
                02.07.1723:13:08

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

                #928357 ↑
                • 0
                  RadiantConfessor RadiantConfessor
                  03.07.1705:54:39

                  Более того, компилятор тратит энергию 1 раз, а специальный блок железки постоянно, при каждом исполнении программы.

                  По этому VLIW всегда будет энергетически выгоднее RISC.

                  Отредактировано: Zveruga~05:55 03.07.17
                  #928439 ↑
                • 0
                  Нет аватара segfault
                  03.07.1709:07:16

                  Миша, ну ты-то уж не перегибай палку! Архитектура VLIW безусловно хороша, когда речь идет о вычислительных задачах. В таких задачах достаточно мало динамических зависимостей по данным, и хорошо соптимизированное приложение будет показывать отличную производительность. Но как только мы имеем много динамических зависимотей, ситуация оказывается гораздо печальнее, а большинство современных приложений именно таковы. Именно поэтому последние интеловские Итаниумы (Пулсон и Китсон) уже out-of-order. Плюс к этому VLIW не очень хорош, когда мы имеем дело с приложениями, требующими малого времени отклика. Ну и головную боль с оптимизацией приложений, даже при наличии хорошего компилятора, никто не снимал.

                  Собственно, Итаниум умер ровно тогда, когда алгоритмы динамического планировщика команд по эффективности превысили планирование в компиляторе.

                  Я ни в коей мере не призываю отказаться от «Эльбрусов», но давайте все-таки трезво оценивать сильные и слабые стороны любой технологии.

                  #928471 ↑
                  • 2
                    Нет аватара kerosene
                    03.07.1709:31:59

                    Аппаратный динамический планировщик никогда не превысит по эффективности статическое планирование. Это как бы очевидно всем. x86 выигрывает только за счет высокой тактовой частоты и быстрого переключения контекста. Если же вы приведете попугаи SPEC к одному знаменателю, то увидите, что интеля имеют меньшую логическую скорость чем Эльбрусы. Беда Эльбруса — низкая тактовая частота. Но это не проблема VLIW, а проблема конкретных реализаций микроархитектуры и отсутствия full-custom дизайна блоков ядра.

                    #928478 ↑
                    • 0
                      Нет аватара segfault
                      03.07.1711:02:00

                      Уважаемый kerosene, я прекрасно понимаю Ваше желание представить «Эльбрус» с самой лучшей стороны, но давайте будем немного честнее в отношении читателей, которые не обладают достаточной глубиной познаний в микропроцессорных архитектурах. Поверьте, «Эльбрус» от этого только выиграет. Давайте по-порядку.

                      1) Относительно статического и динамического планировщиков. Основная задача и того и другого — обеспечить выполнение кода, когда какая-либо процессорная команда не может завершиться в силу зависимостей по данным. На сегодняшний день бОльшая часть работы, связанная с разрешением зависимостей по данным решается компиляторами уже на уровне преобразования семантического графа программы, по сути на долю собственно планировщика инструкций остается не так уж и много. Кстати, появлению современных методов высокоуровневой оптимизации в компиляторах мы в немалой степени должны быть благодарны и VLIW-архитектурам в том числе. С другой стороны, есть множество случаев, в которых статический планировщик абсолютно бессилен.

                      2) Что касается тестов: если судить по поиведенным данным, то «Эльбрус» по производительности на ядро проигрывает современным интеловским процессорам в 7.5 раз, по производительности на мегагерц — в 4 раза. Это ни плохо, ни хорошо, это голые цифры, и хорошо, что на этих тестах отставание уже меньше, чем на порядок. Что касается «логической скорости», то я не очень понимаю, что Вы имеете в виду? Если количество потенциально выполняемых за такт инструкций, то это и так очевидно, на то она и VLIW архитектура.

                      3) Что касается тактовой частоты, то здесь вы тоже немного лукавите. Я не стану сейчас ничего утверждать, не имея конкретных цифр перед глазами, но есть два ключевых момента, препятствующих увеличению частоты: длина конвейера (а он не должен быть слишком длинным, иначе вся прелесть VLIW теряется) и необходимость иметь многопортовый регистровый файл. Еще раз повторюсь, не имея каких-то деталей по «Эльбрусу», оценить его потенциал в плане повышения тактовой частоты сложно, нл в целом у VLIW-архитектур он ниже, чем у других.

                      4) Это уже к следующему комментарию: интеловские процессоры не будут иметь меньшую тактовую частоту, она на протяжении последних лет постоянна и таковой будет оставаться. А рост количества ядер происходит за счет совершенствования технологического процесса и (не слишком больших) архитектурных оптимизаций. Кстати, цифр по энергопотреблению «Эльбруса» я нигде не видел. Только цифры желательно не абстрактные, а снятые с реальной системы, с указанием теста на котором они получены; а то интел много чего пишет про TDP, а вы PTU запустите, много интересного узнаете на тему того, как процессор разогреть можно    

                      #928501 ↑
                      • 0
                        Нет аватара azurel
                        03.07.1711:35:52

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

                        Если в каких-то задачах, статический планировщик бессилен, то какие преимущества у так сказать полустатического ?

                        Какие процессоры опережают Эльбрус-8С в 7.5 раза ?

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

                        #928509 ↑
                        • 1
                          Нет аватара segfault
                          03.07.1713:02:24

                          Еще раз, компилятор не может разрешить динамические зависимости между данными. И VLIW здесь не помогает никак.Именно поэтому бОльшая часть современных процессоров — out-of-order. Компилятор выполняет ту часть работы, которую можно сделать на основе анализа кода, процессор — остальное. Сюда, помимо динамического планирования, еще добавляется динамическая предвыборка данных.

                          #928540 ↑
                          • 0
                            Нет аватара azurel
                            03.07.1713:43:33

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

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

                            #928552 ↑
                            • 0
                              Нет аватара segfault
                              03.07.1714:31:30

                              Это когда «Эльбрус» вдруг стал out-of-order? Вы не путаете часом out-of-order с возможностью параллельного использования нескольких коевейеров?

                              Что касается ответа на Ваш вопрос: компилятор хорошо справляется с переоупорядочиваним инструкций в соответствии с графом зависимостей. Это работает и в случае VLIW, и в случае других процессорных архитектур. На этом этапе разница лишь в том, что эльбрусовский компилятор еще и разложит независимые команды по VLIW-инструкциям, а тот же интеловский процессор просто будет автоматически в несколько конвейеров их обрабатывать. Реальная разница начинается тогда, когда мы захотим понять, а когда у нас те или иные данные будут готовы? Время выполнения инструкций чтения/записи на этапе компиляции не определено. Никто не может сказать, попадем мы в кэш или промахнемся, если попадем, то в кэш какого уровня и т. д. Динамический планировщик может «кормить» арифметические конвейеры инструкциями по мере готовности данных, внн зависимости от того, как эти инструкции расставил статический планировщик.

                              Отредактировано: segfault~14:32 03.07.17
                              #928564 ↑
                              • 0
                                Нет аватара azurel
                                03.07.1715:47:21

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

                                Тут как не крути если вы статически все распланировали у вас код будет выполняться быстрее.

                                #928593 ↑
                                • 0
                                  Нет аватара segfault
                                  03.07.1716:44:00

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

                                  #928613 ↑
                                • 1
                                  Нет аватара segfault
                                  03.07.1716:52:53

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

                                  Отредактировано: segfault~16:53 03.07.17
                                  #928618 ↑
                                  • 0
                                    Нет аватара azurel
                                    03.07.1717:13:24

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

                                    В среднем выигрыш оказывается положительным.

                                    Отредактировано: azurel~17:13 03.07.17
                                    #928630 ↑
                                    • 0
                                      Нет аватара segfault
                                      03.07.1718:21:17

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

                                      А вот второе утверждение (что «Эльбрус» обходит другие процессоры), к сожалению, пока является неправдой, хотя очень хотелось бы, чтобы было наоборот. Приведите хоть одну цифру честного сравнения «Эльбруса» с тем же Intel Xeon E5 v4, которая показала бы превосходство «Эльбруса». Без разницы, в сравнении систем целиком, в пересчете на одно ядро или на мегагерц — все равно.

                                      Я очень высоко ценю труд коллектива МЦСТ и их достижения, но, пожалуйста, не надо заниматься шапкозакидательством, поверьте мне, это очень плохо влияет на имидж «Эльбруса» в ИТ-отрасли

                                      #928659 ↑
                      • 0
                        Нет аватара kerosene
                        03.07.1711:36:47

                        MCST Elbrus-8C, 1.00 GHz:

                        SPEC CPU 2006: 10

                        SPEC FPU 2006: 13

                        Sandy Bridge, 1.00 GHz (GCC):

                        SPEC CPU 2006: 8.6

                        SPEC FPU 2006: 10

                        #928510 ↑
                        • 0
                          Нет аватара segfault
                          03.07.1712:42:51

                          Intel Xeon E5-2699A v4, 2,4GHz: SpecFP 2006 — 128.

                          Итого, 128/17 = 7.53

                          С приведением по частоте (128/2.4)/13 = 4.1

                          #928532 ↑
                          • 1
                            Нет аватара kerosene
                            03.07.1712:54:52

                            Я писал про SPEC INT, а не FP.

                            И к тому же: ark.intel.com/products/96899/Intel-Xeon-Processor-E5-2699A-v4-55M-Cache-2_40-GHz

                            2 сокета — SPEC FP — 1120 — ЭТО НА 2-СОКЕТНОЙ СИСТЕМЕ С 44 ЯДРАМИ!

                            А для Эльбруса даны показатели для 1 ядра!

                            1120 / 44 = 25,45

                            Для 1 ядра на 1 ГГц будет 10,6 попугаев, а у Эльбруса на 1 ГГц будет 13.

                            Отредактировано: kerosene~13:01 03.07.17
                            #928537 ↑
                            • 0
                              Нет аватара segfault
                              03.07.1713:08:49

                              Уважаемый kerosene, не путайте теплое с мягким. Тесты SPECfp и SPECfp_rate — это *разные* тесты. Мы говорим про SPECfp, который показывает производительность применительно к одному ядру. А результатов теста SPECfp_rate для «Эльбруса» Вы не приводили.

                              #928542 ↑
                              • 1
                                Нет аватара kerosene
                                03.07.1713:11:44

                                Я вам привел тест SPECfp_rate для 2-сокетной системы на Intel® Xeon® Processor E5-2699A v4. 1120 попугаев.

                                #928544 ↑
                                • 0
                                  Нет аватара segfault
                                  03.07.1713:17:05

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

                                  Отредактировано: segfault~13:17 03.07.17
                                  #928546 ↑
                                • 1
                                  Нет аватара segfault
                                  03.07.1713:21:32

                                  P. S. Если на двухпроцессорной системе с Эльбрус-8С Вы получите на SPECfp_rate хотя бы 200, я первый скажу, что это круто.

                                  #928547 ↑
                              • 0
                                Федор Синицын Федор Синицын
                                06.07.1702:04:35

                                На сайте www.specbench.org/cpu2006/results/ я не нашел результатов SpecFP2006 для систем на Sandy Bridge близкие к 37,68 как в статье и видео. Там вообще для двузначных результатов нет сотых долей, только десятичные. А сами результаты значительно выше от 40 до 70, если не ошибаюсь. Я к тому, что вообще непонятно как тестировали, и с чем сравнивали. Могу предположить, что тест проводился на своем компьютере, в конфигурации схожей с Эльбрусом.

                                Отредактировано: Иван Смирнов~02:08 06.07.17
                                #929488 ↑
                  • 2
                    Нет аватара kerosene
                    03.07.1709:34:07

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

                    #928479 ↑
                  • 0
                    shigorin shigorin
                    30.07.1720:22:17

                    Спасибо!

                    #938433 ↑
                • -1
                  Нет аватара guest
                  03.07.1710:28:07

                  Потому что есть 100500 вариантов развития событий. Данные могут поступать в разное время, переходы и т. д.

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

                  #928490 ↑
                  • 2
                    Нет аватара kerosene
                    03.07.1718:15:14

                    Во-первых, тебе уже сказали, что в Эльбрус запросто можно встроить предсказатель переходов. Его и должны были встроить в модель Эльбрус-1С+, но не успели чисто по времени. Во-вторых почитай уже наконец книгу про Эльбрус в PDF на сайте МЦСТ. А то похоже, что ты не имеешь никакого представления о том, что такое архитектура Эльбрус. Это не просто процессор с VLIW, это VLIW/EPIC с кучей крутых функций типа спекулятивного исполнения, условного исполнения, асинхронной предподкачки данных в РФ минуя кэш, некоторой аппаратной поддержки для трансляции x86-кодов (формат данных с плавающей точкой совместимый с Интел, сегментные регистры, указатель команд и стека, арифметические команды совместимые с x86 по флагам операций и т. д.), поддержки конвейеризованных циклов, 3 стеков из которых 2 защищенных аппаратных, режима защищенного исполнения, когда все данные в памяти тегируются, а обращение к структурам и данным идет только через 128-битные дескрипторы и т. д.

                    Отредактировано: kerosene~18:19 03.07.17
                    #928657 ↑
                    • 0
                      Нет аватара guest
                      03.07.1718:49:02

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

                      #928664 ↑
    • 4
      Михаил Усоцкий Михаил Усоцкий
      02.07.1716:11:57

      Intel будет бить по почкам, то есть затаскает вас по судам, чтобы содрать с вас как можно больше денег за нарушение собственности на x86. С AMD немного другая история сложилась, из-за того со своими сверхдорогими Itanium Intel села в лужу. А AMD просто усовершенствовала x86 до x86-64. Intel использует наработки AMD, хотя и старается всем объяснять, что это их технология и они сами сделали. А разрабатывать процессоры на базе x86 как-то бессмысленно. Костыль на костыле работает. Что ни новость, то баги и ошибки в декодере команд, которые надо исправлять прошивками и заплатками.

      #928247 ↑
      • 0
        Alexander V Alexander V
        02.07.1716:45:28

        Есть еще VIA

        #928255 ↑
        • 3
          Михаил Усоцкий Михаил Усоцкий
          02.07.1717:00:14

          Есть, конечно. Но они не могут соперничать с монстрами в лице Intel Core iX или AMD Athlon / Ryzen. Максимум, что они могут соперничать — с Celeron / Pentium. Любой ARM легко уделает VIA. А тут как раз речь про самые быстрые процессоры, которые очень нужны всем нам. Особенно для разработчиков, занимающиеся в САПР или моделирование. Суперкомпьютеры в России, использующие зарубежные процессоры, контролируются американцами, чтобы мы не могли сделать что-то прорывное. А уж китайцам и вовсе запретили продавать. Таки появились у них собственные процессоры Гудзоны. И к тому же, VIA уже давно присутствует на рынке. Ещё до появления Pentium (появление данной торговой марки обязано судебному разбирательству на x86). Конечно, часть патентов уже перестала действовать за сроком годности. Но на некоторые части всё равно действуют патенты.

          Отредактировано: Михаил Усоцкий~17:15 02.07.17
          #928256 ↑
          • 4
            Нет аватара guest
            02.07.1718:01:34

            Процессоры у китайцев не совсем собственные, а сделаны на основе архитектуры MIPS в сотрудничестве с STMicroelectronics. Вообще с микроэлектроникой у китайцев(имеется в виду континентальный Китай) так себе, Тайвань — другое дело, но у них с самостоятельностью совсем плохо, приходится проворачивать схемы типа «организуем компанию в Китае, она заказывает разработку и производство компонентов на Тайване"(например мобильные «системы на чипе» MTK стоящие в подавляющем большинстве дешёвых телефонов и планшетов продаются от лица китайской компании, однако её хозяева, разработка и производство находятся на Тайване).

            #928276 ↑
            • 0
              Нет аватара segfault
              03.07.1709:10:15

              У китайцев есть и полностью собственные процессоры, посмотрите информацию о ShenWei.

              Отредактировано: segfault~11:34 03.07.17
              #928473 ↑
    • 5
      Нет аватара silicoid
      02.07.1717:50:12

      Интел очень жестко лицензирует свою систему команд.

      а между интелом и амд сужествует договор о корсслицензировании. скажем так интеловская 64-битная система команд есть, фактически, АМД64. вот так и живут.

      а всех остальных этот двуликий янус мочит в судах нещадно

      единственное, у кого еще осталась лицензия на х86. это виа. но сама виа скорее мертва чем жива

      #928270 ↑
      • 2
        Нет аватара guest
        02.07.1718:48:32

        Спасибо IBM, хихикс.    

        #928295 ↑
    • 0
      Олег Бахарев Олег Бахарев
      02.07.1722:54:32

      Потому что на архитектуру SPARC — очень дешевая легальная лицензия.

      #928342 ↑
      • 0
        Alexander V Alexander V
        02.07.1722:59:19

        На SPARC кроме Oracle кто-нибудь работает? Debian 8 уже не поддерживал SPARC, а на дворе Debian 9. Уж Debian всегда славился своей коллекцией поддерживаемых архитектур.

        #928348 ↑
        • 2
          Олег Бахарев Олег Бахарев
          02.07.1723:13:28

          А причем здесь Debian? На процессорах Эльбрус действует ОС Эльбрус или МСВС. Но поскольку это разновидность Linux, вы можете широко кастомизировать ее, там работает менеджер пакетов RPM и имеется список поддерживаемых пакетов.

          #928358 ↑
          • 0
            Alexander V Alexander V
            02.07.1723:18:03

            Вы представляете, что такое поддерживать экзотический дистрибутив?

            #928360 ↑
            • 0
              Виктор Гюго Виктор Гюго
              03.07.1711:20:26

              Да. Команды из толковых 5-6 человек вполне хватает.

              #928503 ↑
              • 0
                shigorin shigorin
                26.10.1821:03:53

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

                #1080147 ↑
        • 0
          RadiantConfessor RadiantConfessor
          03.07.1705:59:17

          На SPARC работают процессоры российских систем ПВО.

          #928442 ↑
      • 4
        shigorin shigorin
        02.07.1723:09:02

        Ну и собсно МЦСТ -- Московский Центр SPARC-Технологий, ага.

        PS@20181026: кстати, недавно выяснил, что это была историческая расшифровка, а теперь МЦСТ -- это просто МЦСТ.    

        Отредактировано: shigorin~21:04 26.10.18
        #928355 ↑
      • 0
        RadiantConfessor RadiantConfessor
        03.07.1705:58:48

        Архитектура SPARC не имеет отношение к архитектуре Эльбрус.

        #928440 ↑
    • 0
      Нет аватара superriva
      03.07.1710:41:23

      -> Почему от x86 архитектуры отказались? Intel и AMD как-то выпускают свои процессоры.

      Посмотрите википедию x86 уже по сути нету [ссылки отключены]

      «Наиболее широко используемые в настольных компьютерах процессоры архитектуры x86 ранее являлись CISC-процессорами, однако новые процессоры, начиная с Intel Pentium Pro (1995 г.), являются CISC-процессорами с RISC-ядром[10]. Они непосредственно перед исполнением преобразуют CISC-инструкции x86-процессоров в более простой набор внутренних инструкций RISC.

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

      Отредактировано: superriva~10:43 03.07.17
      #928495 ↑
  • 16
    Нет аватара guest
    02.07.1713:03:05

    Люблю читать комменты под такими новостями, сам ничего не понимаю, но явно пишут люди умные))). Не знаю, что там в сравнении с 2010 годом, но у меня комп такого возраста и со всем справляется))). В игры не играю из-за отсутствия времени.

    #928201 ↑
    • 5
      Нет аватара guest
      02.07.1713:50:28

      Такая же «печенька». ))) Древний комп. intel 2,4 ГГц х 2×86, 2 ГБ память. Всё что нужно прекрасно работает(«летает»).))) Раньше видео конвертеры — «медленныё газ», а сейчас они не нужны. ТВ всё читает…)))

      #928217 ↑
    • 2
      krotozer krotozer
      02.07.1723:58:03

      Как человек понимающий, скажу, что тут случился натуральный «спор у костра под горячительное») Если что-то непонятно, попробуйте спросить — может сумеем объяснить просто о сложном.

      #928382 ↑
  • 1
    Нет аватара guest
    02.07.1715:03:40

    К сведенью автора!

    Наращение (буквенное падежное окончание) используется в записи порядковых числительных: 10-й класс «Б»; ученик 11-го класса; 1-й вагон из центра; 5-й уровень сложности; занять 2-е и 3-е места; в начале 90-х годов, 12-й маршрут.

    Наращение не используется:

    1. В записи количественных числительных: словарь в 4 томах; работа 2 сотрудников; серия из 12 упражнений.

    2. При записи календарных чисел: 22 марта 2003 года, 1 апреля, 10 января.

    3. Если число обозначено римской цифрой: II Международная олимпиада школьников по русскому языку; IX конгресс, XXI век, Людовик XIV.

    4. В номерах томов, глав, страниц, иллюстраций, таблиц, приложений и т. п., если родовое слово (том, глава) предшествует числительному: на с. 196, в т. 5, в табл. 11, в прил. 1 (но: на 196-й странице, в 5-м томе, в 11-й таблице, в 1-м приложении).

    #928239 ↑
  • -7
    Нет аватара guest
    02.07.1716:43:44

    +++ В 2021 году планируется выход 16-ядерного микропроцессора «Эльбрус-16С» с тактовой частотой 2 ГГц, встроенным южным мостом с поддержкой интерфейсов PCI-Express 3.0, USB 3.0, SATA 3.0 и контроллером памяти с поддержкой DDR4-3200 +++

    В 2021 году это всё сильно устареет…

    #928254 ↑
    • 8
      Нет аватара azurel
      02.07.1717:07:40

      С тем приростом производительности на ядро, которое демонстрируют остальные компании не сильно устареет.

      #928258 ↑
    • 6
      Михаил Усоцкий Михаил Усоцкий
      02.07.1717:37:59

      Если в плане производительности, то первые Intel Core iX не сильно отличаются в плане производительности от последних моделей, если не брать в расчёт всяких расширений. Любит Intel сдирать с потребителей огромное количество денег за каждый 5% прироста производительности. А стандарты интерфейсов не так быстро сменяются и остаются обратносовместимыми.

      #928267 ↑
    • 4
      Нет аватара guest
      02.07.1718:09:50

      С софтом, как быть?

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

      если это устареет тогда что такое новое? для меня вот это вышеперечисленное, уже внушает тихий ужас.

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

      #928279 ↑
      • Комментарий удален
      • 5
        krotozer krotozer
        03.07.1700:03:13

        Как раз-таки «Эльбрусы» в этом отношении куда более стойкие, как и «Байкалы». У меня опыт работы только с «4С», но у него и вовсе частота на ядро — 800 МГц, а тянет где-то на уровне «Core2Duo», при этом практически «холодный».

        #928383 ↑
        • 1
          goryachee_leto goryachee_leto
          03.07.1701:19:50

          У меня опыт работы только с «4С», но у него и вовсе частота на ядро — 800 МГц, а тянет где-то на уровне «Core2Duo», при этом практически «холодный».

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

          #928410 ↑
          • 5
            krotozer krotozer
            03.07.1701:46:10

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

            .

            Сейчас я вижу вполне приемлемую скорость вычислений, но всё-таки задумчивую работу Xorg-сервера, а может это QT втормаживает так. Ну и скрипты на Python-е не так уж быстро шевелятся, как на Intel-е, но надо помнить, что частота у него — как у Pentium III, а тот возился бы с теми же расчётами значительно дольше.

            .

            Недавно посещали МЦСТ, тестировали сборку у них на машине с «С8» — 1,3 ГГц, 8 ядер. На «С4» наш продукт компилируется около трёх часов. На «С8» — примерно полтора. Я не помню такой разницы в производительности между соседними сериями процессоров от Intel. И это при том, что у «С8» при компиляции задействовались только четыре ядра!

            Отредактировано: krotozer~01:48 03.07.17
            #928418 ↑
      • 0
        Нет аватара guest
        04.07.1719:03:48

        Зайдите на сайт Теркон-КТТ. Довольно интересные решения по системам охлаждения.

        Отредактировано: Василий Горбатюк~19:04 04.07.17
        #929002 ↑
  • Комментарий удален
  • 3
    Иван Иванов 2 Иван Иванов 2
    02.07.1720:57:20

       

    #928319 ↑
  • 3
    shigorin shigorin
    02.07.1723:10:41

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

    #928356 ↑
  • 0
    Нет аватара guest
    03.07.1712:45:19

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

    #928534 ↑
    • 0
      krotozer krotozer
      03.07.1716:29:52

      Никто Вам не даст майнить на «Эльбрусе», по крайней мере ближайшие года три — точно! Этот ЦП разрабатывался для серьёзных дел, а не для угождения халявщикам. Были в 80-ых такие же, «фарцовщиками» назывались. Где они сейчас? Половины в живых нет…

      #928604 ↑
      • 0
        Нет аватара guest
        05.07.1710:24:51

        Эти халявщики создали дефицит видеокарт на рынке.

        #929164 ↑
        • 0
          Нет аватара guest
          05.07.1718:54:28

          Эти халявщики целые кластеры для майнинга ставят и ASIC выпускают. Видать стоит овчинка выделки. Посмотрите компанию BitFury например. Они майнят биткоины в промышленных масштабах.

          Отредактировано: Антон Смоленский~18:54 05.07.17
          #929346 ↑
    • Комментарий удален
  • 2
    Нет аватара guest
    04.07.1712:57:20

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

    Вопрос: работают ли наши над каким-то аналогом GPU-архитектуры для параллельных вычислений типа CUDA? Видеокарта нынче — очень мощная вещь по сравнению с многоядерными процессорами общего назначения. Пример: ускорение матричных вычислений на видеокарте 70 раз! по сравнению с одним ядром.

    Очень хочется иметь российский аналог (или что-то совсем своё).

    #928856 ↑
  • 0
    shigorin shigorin
    02.11.1817:32:01

    Для коллекции -- забеги с 7za b на разных эльбрусах зафиксированы на opennet.ru, а со счётными задачами -- и на СуН.

    #1082074 ↑
Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,