Здравствуйте, PM, Вы писали:
PM>На предсказатель переходов в процессоре это никак не повлияет.
Это если он есть. PM>Может быть, если очень повезет, оптимизатор в компиляторе сможет переупорядочить код, чтобы несколько likely блоков кода были рядом и поместились в кэш инструкций.
Нет, просто оптимизатор вставляет условный джамп так, чтобы likely ветка шла без джампа.
Предполагая, что тупой процессор будет забивать конвеер в предположении, что джамп не случится.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вы, наверное, смеётесь. Ежегодно в тех же штатах выпускаются десятки тысяч людей, которые проходят курсы "разработка компиляторов". Из них процентов 10 разбираются во внутреннем устройстве реального компилятора С.
Речь шла о людях, которые не только курсы прошли, а специализируются конкретно на этом. Т.е. способны что-то осмысленно менять в коде или дописать.
Прослушал курс это не то, как минимум дипломная работа на соотв. тему или кандидатская. Почему 10%, а не 1%?
S>>1) Не уверен; S>>2)даже если итак, то каково будет качество большниства работ при таком кол-ве? S>Качество большинства работ не зависит от количества. В любом случае 80% — это шлак. Именно поэтому нам нужны десятки тысяч статей, чтобы достичь реального прогресса. S>Мы не знаем заранее, какие из статей окажутся полезными и насколько.
Фантастическими мне кажутся эти цифры в области компиляторостроения. Тысячи спецов, которые могут разобрать компилятор по частям, чего-то там оптимизировать,
модифицировать. Речь именно об узких специалистах, а не о "прослушал курс".
Здравствуйте, Sharov, Вы писали: S>Речь шла о людях, которые не только курсы прошли, а специализируются конкретно на этом. Т.е. способны что-то осмысленно менять в коде или дописать.\
Пока нет таких курсов — не будет таких людей. S>Прослушал курс это не то, как минимум дипломная работа на соотв. тему или кандидатская. Почему 10%, а не 1%?
Практические наблюдения. 1% означал бы, что из ста выпускников нашего ФИТ только один способен открыть исходники, скажем, компилятора java и не охренеть.
В реальности — человек 10-15 с каждого курса.
S>Фантастическими мне кажутся эти цифры в области компиляторостроения. Тысячи спецов, которые могут разобрать компилятор по частям, чего-то там оптимизировать, S>модифицировать. Речь именно об узких специалистах, а не о "прослушал курс".
"Прослушал курс" в США — сотни тысяч, в мире — миллионы.
Чтобы из них получилось меньше тысяч человек, которые могут править реальный компилятор, выхлоп должен быть гомеопатическим. Это не так.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
MH>>вообще то был КР580ВМ80А аналог Z80, это только я лично помню. для того времени (это 80-е годы) очень неплох. S>Эмм, вы точно хотите выдать результат реверса примитивненького, по меркам 80х, процессора за достижение отечественной схемотехники?
Опять дерьмеца решить подлить, смотрю? ))
Через реверс-инжиниринг i8080 был разработан AMD Am9080, история известная.
Наш 580ВМ80А был выполнен тупо по спецификации сигналов и опкодов с 0-ля.
Собсно, то, что это была оригинальная разработка и позволило сразу же разработать улучшенный вариант — 580ВМ1.
Аналогично К1810ВМ86 — это разработка по спецификации.
Ты бы хоть голову включил — когда-то по спецификации с 0-ля разработали аналоги IBM 360/370, а там в разы более сложный процессор.
Или как ведущий разраб микропроцессорной технологии Интел ушел от них и создал более продвинутую весию Z80.
Без предыдущих своих наработок запарился бы.
В общем, достал тут уже всех из пальца насасывать.
S>На всякий случай напомню, что на 80е на загнивающем западе — это не только 8080, но и 80386. И даже 80486.
Выпускался с 77-го.
Первые 386-е персоналки на Западе были доступны только относительно богатым людям, которых не было в СССР.
А в плане использования в науке или экономике — та персоналка стоила примерно как мейнфрейм EC-1033, на котором могли одновременно работать 30 человек.
В 80-е годы у нас активно разрабатывались мини-ЭВМ совместимые с PDP-11, и раньше всех в мире выпустили в виде микропроцессоров — вся линейка БК, УКНЦ, ДВК.
Работали они на той же тактовой шустрее 8086, выглядели более перспективными.
Если бы СССР не начал разваливаться примерно с 1987-го и не открыли резко границы для западной бэушной выч.техники в 1989-м, по частоте разгоняли бы эту линейку процов.
Пусть бы отставали лет на 5-7 от Запада в железе — ну и хрен с ним, это не принципиально.
А таких как ты послушали, развалили всё, теперь это отставание гораздо глубже.
Да и утечка кадров из-за развала когда-то даёт себя сейчас знать.
Здравствуйте, Sinclair, Вы писали:
S>Там же в том-то и проблема, что интел со товарищи не просто "где-то взяли чертежи", а имели весь технологический стек. И пока у нас Институт Автоматики и Электрометрии занимался послойным сканированием импортных микросхем при помощи электронных микроскопов, буржуи учились разрабатывать и производить всё более совершенные чипы.
Очередная ложь-гавнецо.
Реверс-инжиниринг i80286-х и выше выполнялся с другой целью — с целью понимания, с чем придётся работать, ведь на них тогда сажали силовиков и спецслужбы.
В т.ч. на предмет поиска закладок.
Никакие результаты для неких наших процов от тех изысканий применены не были.
Да это практически и невозможно — дешевле по спецификации разработать с 0-ля.
Здравствуйте, karbofos42, Вы писали:
K>Советские инженеры не могли свою архитектуру разработать и собственный чип?
Могли.
Для системы команд PDP-11 первыми в мире сделали в виде микропроцессоров, пока у всех еще оно же было в виде мини-ЭВМ.
K>Или дяди на постах решили, что нужно своё всё похоронить, будем копировать буржуйские чипы и тогда можно будет с ПО и программистами не возиться, т.к. его можно тоже пиратить, а не своё разрабатывать?
Да Синклер херню порет из разряда "слышал звон".
Чел ни разу в жизни не разрабатывал железо и плохо себе представляет происходящее.
А так же плохо представляет, что с этим делать дальше, как клепать следующие версии.
Хотя, достаточно было включить хотя бы немного воображение, мол, что проще, написать прогу с 0-ля или через реверс-инжиниринг бинарника?
Любому вменяемому программеру ответ очевиден.
Здравствуйте, vdimas, Вы писали:
V>В 80-е годы у нас активно разрабатывались мини-ЭВМ совместимые с PDP-11, и раньше всех в мире выпустили в виде микропроцессоров — вся линейка БК, УКНЦ, ДВК.
В мире к тому времени рынок "бытовых" ЭВМ был плотно занят 6502 (Apple I/II, Commodore 64, NES/Famicom ...) и переползал на Motorola 68000 (Amiga, Mac, почти все 16-ти битные игровые консоли ...), который существенно превосходил PDP-11 (по сути он его развивал).
V>Работали они на той же тактовой шустрее 8086, выглядели более перспективными.
i8080 на той-же тактовой частоте сливал 6502, и как ни крути выросший из него i8086 перенял эстафету и сливал всем кому не лень. DEC-овская архитектура и система команд просто песня (в хорошем смысле) по сравнению с Intel-ской, а M68K совсем на тот момент был космос.
V>Если бы СССР не начал разваливаться примерно с 1987-го и не открыли резко границы для западной бэушной выч.техники в 1989-м, по частоте разгоняли бы эту линейку процов. V>Пусть бы отставали лет на 5-7 от Запада в железе — ну и хрен с ним, это не принципиально.
На тот момент ПК-шный софт писался преимущественно под x86 и реже M68K (Amiga, Mac), следовательно, велосипедить на разогнанном PDP-11 было просто не разумно, т.к. софт как обычно нужен был еще "вчера".
Здравствуйте, 4058, Вы писали:
V>>В 80-е годы у нас активно разрабатывались мини-ЭВМ совместимые с PDP-11, и раньше всех в мире выпустили в виде микропроцессоров — вся линейка БК, УКНЦ, ДВК. 4>В мире к тому времени рынок "бытовых" ЭВМ был плотно занят 6502 (Apple I/II, Commodore 64, NES/Famicom ...)
Это из класса 8080, а наши процы 1801BMx из класса 8086, т.е. быстрее кратно.
4>и переползал на Motorola 68000 (Amiga, Mac, почти все 16-ти битные игровые консоли ...), который существенно превосходил PDP-11 (по сути он его развивал).
Проц 68k — 32 битный.
И нифига не превосходил в первых версиях.
V>>Работали они на той же тактовой шустрее 8086, выглядели более перспективными. 4>i8080 на той-же тактовой частоте сливал 6502, и как ни крути выросший из него i8086 перенял эстафету и сливал всем кому не лень. DEC-овская архитектура и система команд просто песня (в хорошем смысле) по сравнению с Intel-ской, а M68K совсем на тот момент был космос.
Да нет, система команд 68k сливает дековской.
Откуда ты эту траву берёшь, то насчёт "развивал PDP-11", то система команд лучше? ))
Даташиты ведь доступны.
В общем, в системе команд PDP-11 все регистры равноправны.
Это и плюс и минус одновременно.
Плюс — потому что, для сравнения, в коде для 8080 или 8086 до половины команд — межрегистровые пересылки, т.к. регистры слишком специализированные.
Минус — потому что кодировка команд со специальными регистрами порой короче, система команд может быть разнообразней/высокоуровневей.
68k — это компромисс. В нём регистры, таки, разделены на два файла по типу, но внутри каждого файла равноправны.
V>>Если бы СССР не начал разваливаться примерно с 1987-го и не открыли резко границы для западной бэушной выч.техники в 1989-м, по частоте разгоняли бы эту линейку процов. V>>Пусть бы отставали лет на 5-7 от Запада в железе — ну и хрен с ним, это не принципиально. 4>На тот момент ПК-шный софт писался преимущественно под x86
На тот момент основной ПК-шный софт писался под MacOS.
Для инфы — MS разработала свой первый Excel под MacOS.
И хотя первый Word был разработан под IBM PC, этот Word на тот момент был никто и звать никак, им не пользовались, т.к. конкуренты были лучше.
И, разумеется, они были под мак.
100% профессионального ПО для персоналок было тогда под мак, а под IBM PC большей половины этого ПО даже не существовало.
8086 — это ширпотреб для бухгалтера или для какого-нить лаборанта, в обоих случаях замена программируемому калькулятору. ))
На фоне этой убогости маки смотрелись серьёзными машинками с крутой графикой и прочей мультимедиа.
Мак проиграл гонку сугубо из-за ценовой политики — по нынешним деньгам с хорошим монитором стоил бы под $20 тыс.
А в плане софта Word выиграл лишь тогда, когда его стали продавать в составе пакета для офиса, т.е. опять через ценовую политику.
4>велосипедить на разогнанном PDP-11 было просто не разумно, т.к. софт как обычно нужен был еще "вчера".
Да всё нормально у нас было с софтом.
Антивирусы Лозинского, текстовые и графические редакторы — всё было.
Оно ж понятно, что происходило — заимствованное пиратское ПО убило нашу софтостроительную отрасль.
Единственно в бухгалтерии импорт не канал, поэтому этого добра от наших было полно и до сих пор наше бухгалтерское ПО одно из самых продвинутых в мире.
И почему ты считаешь, что в других областях наше ПО было бы хуже?
У нас подготовка программеров в среднем по палате на голову выше.
Исторические проблемы у нас были не с софтом, проблемы были с железом, а именно — с машинным временем для потенциальных программеров.
Если бы не начавшийся развал от примерно 87-го года, то уже к 91-92-му машинным временем наши программеры должны были быть обеспечены.
К 91-му году уже были:
КМ1801ВМ3
Отличается бо́льшим объёмом адресуемой памяти (до 4 МБ), более высоким быстродействием (сложение регистр/регистр — 1,5 млн оп/с, умножение — 100 тыс. оп/с, деление — 50 тыс. оп/с), а также возможностью подключения сопроцессора арифметики с плавающей запятой.
КА1801ВМ4, КН1801ВМ4
Математические сопроцессоры для КМ1801ВМ3 и КН1801ВМ3. 32/64 разряда, первоначально 6 МГц, после 1991 года — до 8 МГц. Полностью советская разработка. Повышает производительность при работе с числами с плавающей точкой почти на два порядка.
Т.е. это уровень i286-го первого поколения.
Чуть позже пошли модификации обеих чипов под 16 МГц, т.е. это уровень i286-го второго поколения.
И как раз в 91-92 гг что-то более-менее приличное из поставляемой нам б/у или левой техники мы могли позволить себе 286-е.
В общем, да, немного отставание от Запада, но это было не критично, как показало себя наше ПО в незанятых пиратками нишах.
Т.е. за сколько-то лет отставание было бы нивелировано до непринципиального.
А на деле был развал, пиратское ПО и бурная утечка мозгов.
Причём, утекали вовсе не бездари.
Здравствуйте, Sinclair, Вы писали:
S>Ну, в целом у меня скепсис относительно VLIW; я его считаю тупиковой технологией — но ведь можно же и ошибиться.
В качестве числодробилки хорошо работает, ИИ, на больших циклах типа GC Mark-and-Sweep.
Т.е. где не очень много ветвлений, но много вычислений.
Задачи подобного плана самые нагрузочные сегодня.
Остальные задачи уже более десятка лет находятся в нише достаточности производительности.
K>>Чтобы была массовость — тут нужно сначала очень много денег вбухать в разработку более современных чипов. S>Чтобы была массовость — нужна целевая аудитория.
Нужно железо. Много.
Даже если оно дорогое на сейчас — пораскидать по ВУЗ-ам для студней и аспирантуры.
Для задач баловаться/программировать один хост обслужит десяток X-терминалов без проблем (там обычные линуха).
В идеале и вовсе облако — с виртуализацией всё ОК с версии проца 16С, т.е. имеющийся облачный софт поверх KVM работает.
S>Целевой аудитории нужен софт, а не железки.
Необходимая целевая аудитория на данном этапе — потенциальные программеры.
Причём, линукс-программерам традиционно пофик на железо, они не на асме пишут.
Зато наличие железа позволит прямо по месту экспериментировать тем единицам процентов, кому, таки, железо тоже любопытно.
При наличии железа, на эту тему пойдут курсовые, дипломные и кандидатские, впрочем, ты и сам эту кухню знаешь.
S>Чтобы был софт, нужны тулчейны и люди, которые ими владеют.
Это всё было изначально.
Операционная система «Эльбрус Линукс», также известная как ОС «Эльбрус» (OSL) ...
Относится к семейству GNU/Linux, сочетая ядро Linux и прикладные программы GNU, а также более 2000 программных пакетов.
Версия этой же операционки под именем «Эльбрус Линукс для x86» предназначена в т.ч. для виртуалок на твоём компе:
- позволяет ознакомиться и начать работать в среде «Эльбрус Линукс» без использования вычислительной техники Эльбрус;
— может служить площадкой для переноса (портирования) существующего программного обеспечения на платформу Эльбрус в архитектурно-независимой части этого процесса — при переходе на Linux с других операционных систем;
— может служить гостевой операционной системой при запуске программ в машинных кодах x86 на компьютерах архитектуры Эльбрус через двоичный транслятор.
Распространяется свободно и бесплатно.
S>Последние 50 лет развития индустрии об этом не просто говорят, а кричат.
Примерно как тебе часто не просто говорят, а кричат — пройдись в гугл. ))
S>Не можете сами потянуть тулчейн — откройте экосистему.
Экосистема Линухов открыта.
K>>Потом ещё вбухать в производство большой партии этих чипов.
Вооот...
K>>Потом вбухать в их продажу по себестоимости или даже ниже, чтобы они людям были нужны. S>Это телега впереди лошади. Чипы сами по себе никому не нужны. Нужен софт, который решает прикладные задачи.
В экосистеме линухов почти весь софт доступен в исходниках.
S>Айфон взлетел не потому, что Apple вбухал очень много денег в производтство большой партии чипов и продавал дешевле себестоимости. А потому, что была создана экосистема AppStore. Каждый доллар, инвестированный в эту экосистему, вернулся уже много-много раз и продолжает возвращаться.
Продолжайте наблюдения. ))
S>Интел стал интелом не потому, что начали с производства большой партии процессоров и торговли в убыток. S>А потому, что у IBM PC была открыта как софтная, так и хардная архитектура. Ни интел ни микрософт не пытались монополизировать производство компиляторов и прочих средств разработки.
Даташиты процов открыты.
Но без реального железа эти даташиты мало кому интересны.
Ну вот я низкоуровневый программер, мне очень даже интересно погонять некоторые вещи, типа user-space TCP-стека, посмотреть как работают аналоги RDTSC — в прошлых процах из мира x86 (но до сих пор часто встречающихся) были проблемы с этой операцией, которые я в своём коде должен обыгрывать. Без наличия реальной железки я ничего толком не посмотрю. Что мне дадут очередные "просто Линуха" без низкого уровня? Я и так каждый день на них время трачу, мне это не интересно.
Здравствуйте, Sinclair, Вы писали:
S>Теперь данные есть, но разработка требует мгновенных инвестиций в размере по 400к на сотрудника, т.к. нет эмулятора.
Можно эти 400 тыс размазать через коэф примерно 1:5..1:10 через виртуализацию, получится относительно недорого.
Здравствуйте, karbofos42, Вы писали:
K>Смысла в бинарной трансляции .NET никакого, т.к. производительность будет как у калькулятора. Интересна именно нативная реализация .NET под Эльбрус и вот с ней вопросы.
Ну... сырцы дотнета корки открыты, можно прилепить где-то эти сырцы как сабмодуль в своём репозитории, настроив сборку в нужной архитектуре.
K>Линуксоиды же всем этим занимаются и набор приложений соответствующий. Вот Java-машин по-моему даже пару-тройку вариантов под Эльбрусы нативно портировали, а .NET у них не в почёте и вряд ли кто-то ломанулся переносить.
Здравствуйте, vdimas, Вы писали:
4>>В мире к тому времени рынок "бытовых" ЭВМ был плотно занят 6502 (Apple I/II, Commodore 64, NES/Famicom ...)
V>Это из класса 8080, а наши процы 1801BMx из класса 8086, т.е. быстрее кратно.
Насчет быстрее кратно, позволю себе не согласится. У меня в 90-м появился комп как раз на КР580ВМ80А (i8080), а у знакомого БК-0010.01, чуть позднее мы в качестве хобби занимались портированием всякого полезного кода с Синклера и MSX-1 (Z80A). Так вот, КР580ВМ80А слегка подразогнанный до 3-х Мгц по производительности конечно уступал К1801ВМ1 на той-же частоте, но не критично. Показателен был очередной вариант распаковщика LZ77 (передранный с Синклера), который на К1801ВМ1 процентов на 30% работал быстрее по сравнению с КР580ВМ80А (хотя тут еще кривизна рук имеет особое значение).
Вообще писать под i8080 было то еще "удовольствие", ибо заранее не обложившись солидной библиотекой макросов, писать под него было весьма муторным занятием, в то время как под PDP-11 подобного не требовалось, всё и так было просто и удобно.
V>Проц 68k — 32 битный.
Это не совсем так, АЛУ и шина данных у него 16-ти битные (если говорить конкретно про 68000).
V>И нифига не превосходил в первых версиях.
Превосходил.
V>Да нет, система команд 68k сливает дековской. V>Откуда ты эту траву берёшь, то насчёт "развивал PDP-11", то система команд лучше? )) V>Даташиты ведь доступны.
Язык ассемблера M68k схож с ассемблером PDP-11 и VAX. Несмотря на исключение в виде разделения регистров общего назначения на специализированные регистры адресов и регистры данных, архитектура 68000 во многом — 32-битная версия PDP-11.
Собственно массово выпускать PDP-11 за бугром в виде микропроцессора было уже не интересно, т.к. в 79-м появился 68000.
Тем не менее чего-то там всё-таки выпустили:
В 1979 году был разработан процессор DEC J-11 на двух или трёх микросхемах.
V>100% профессионального ПО для персоналок было тогда под мак, а под IBM PC большей половины этого ПО даже не существовало. V>8086 — это ширпотреб для бухгалтера или для какого-нить лаборанта, в обоих случаях замена программируемому калькулятору. )) V>На фоне этой убогости маки смотрелись серьёзными машинками с крутой графикой и прочей мультимедиа.
Amiga по сравнению с Маком был гораздо более доступен, и использовался как раз для мультимедиа. Мне посчастливилось мельком застать его воочию где-то в 93-м, оставило впечатления, по сравнению с Маком, который я увидел в конце 90-х уже в виде Power Macintosh, что было совсем не интересно, ибо к тому времени PC уже всех догнал (и перегнал).
V>Мак проиграл гонку сугубо из-за ценовой политики — по нынешним деньгам с хорошим монитором стоил бы под $20 тыс.
Не только, Мак это вещь в себе, а PC всё-таки конструктор, позволял апгрейдится ...
V>Да всё нормально у нас было с софтом. V>Антивирусы Лозинского, текстовые и графические редакторы — всё было. V>Оно ж понятно, что происходило — заимствованное пиратское ПО убило нашу софтостроительную отрасль.
Доступность заимственного ПО позволила в кратчайшие сроки получить приличное число пусть и доморощенных, но при этом вполне хороших специалистов, причем не только программистов.
V>Единственно в бухгалтерии импорт не канал, поэтому этого добра от наших было полно и до сих пор наше бухгалтерское ПО одно из самых продвинутых в мире. V>И почему ты считаешь, что в других областях наше ПО было бы хуже?
Так никто особо не мешал делать качественное ПО и в других областях, но кроме бухгалтерского ПО и антивирусов дело особо не пошло. Помимо того чтобы делать, еще надо уметь продвигать и развивать, а вот с этим у нас не очень.
V>Исторические проблемы у нас были не с софтом, проблемы были с железом, а именно — с машинным временем для потенциальных программеров. V>Если бы не начавшийся развал от примерно 87-го года, то уже к 91-92-му машинным временем наши программеры должны были быть обеспечены.
Я не совсем понимаю о чём речь, со второй половины 80-х отечественный рынок был завален домашними (и к сожалению плохосовместимыми друг с другом) машинками на базе КР580 (РК-86, Специалист, Вектор, Корвет, Орион ...) и 1801BMx (БК ...), + бесчисленные клоны Синклеров, т.е. машинного времени было предостаточно (в среднем цена подобного компа составляла 700 руб), проблема была в основном в получении знаний.
Здравствуйте, 4058, Вы писали:
V>>Это из класса 8080, а наши процы 1801BMx из класса 8086, т.е. быстрее кратно. 4>Насчет быстрее кратно, позволю себе не согласится. У меня в 90-м появился комп как раз на КР580ВМ80А (i8080), а у знакомого БК-0010.01
Где первый проц достиг своего предела, а второй был лишь началом совместимой линейки.
4>Вообще писать под i8080 было то еще "удовольствие", ибо заранее не обложившись солидной библиотекой макросов, писать под него было весьма муторным занятием, в то время как под PDP-11 подобного не требовалось, всё и так было просто и удобно.
Именно так.
Это почему мне, студентом, виделось каким-то идиотизмом, что x86-я архитектура медленно, но верно брала верх.
Вопрос цены железа стал решающим в деле его распространения.
А под более популярное железо было всё больше и больше софта.
Эта экосистема в итоге выиграла тогда.
V>>Проц 68k — 32 битный. 4>Это не совсем так, АЛУ и шина данных у него 16-ти битные (если говорить конкретно про 68000).
Не важно, система команд содержит опкоды для 32-битной арифметики.
В какой-то из следующих версий проца эта архитектура стала тру 32 бит унутре.
V>>И нифига не превосходил в первых версиях. 4>Превосходил.
На аналогичной частоте — нет.
Стал превосходить позже, когда появился конвейер и суперскалярность.
V>>Да нет, система команд 68k сливает дековской. V>>Откуда ты эту траву берёшь, то насчёт "развивал PDP-11", то система команд лучше? )) V>>Даташиты ведь доступны. 4>
4>Язык ассемблера M68k схож с ассемблером PDP-11 и VAX. Несмотря на исключение в виде разделения регистров общего назначения на специализированные регистры адресов и регистры данных, архитектура 68000 во многом — 32-битная версия PDP-11.
"Схож" не значит "развивал".
Там схожесть была разве что в сравнении с x86, но тогда система команд PIC-процов и MIPS точно так же "схожа" с PDP-11.
Сугубо моё ИМХО — такие системы команд хорошо ложатся на RISC-реализацию.
Однако, с вводом суперскаляности обычный RISC стал сливать, поэтому не принципиально.
А что касается программиста на асме — это всё разные ассемблеры в его глазах, разная философия архитектур, разный набор соглашений, особенно в деле организации IO и прерываний.
4>Собственно массово выпускать PDP-11 за бугром в виде микропроцессора было уже не интересно, т.к. в 79-м появился 68000.
Однако, выпускались.
Правда, изначально в виде двухкорпусной сборки, т.е. в СССР впервые в мире реализовали эту архитектуру на одном кристалле.
Это камушек в огород тех, кто заламывает руки "у нас ничего не могли".
Могли.
Просто шло с задержкой примерно 5-7 лет от передовых технологий Запада.
Т.е. от тех технологий, которые не для всех.
А которые для всех — там отставание было примерно в 1-3 года в 80-е и этот поезд всё более набирал обороты прямо на моих глазах.
Массовые выпуски компов уже начали происходить и планы в этом деле были обширные.
В самых последних захолустьях поставили компьютерные классы буквально за 3 года, с 87-го по 90-й, Западу такая масштабная компьютерная интервенция в школы и не снилась в те годы. ))
А затем всё тупо развалили...
4>В 1979 году был разработан процессор DEC J-11 на двух или трёх микросхемах.
Причём, дальнейшее развитие этот проц не получил, в отличие от 1801BMx, который относительно шустро обновлял версии, сохраняя обратную совместимость.
Я на втором курсе как-то посидел за Квант-4С — проникся.
Какой там в опу IBM PC? ))
Шустрый комп, операционка Демос (советское развитие BSD), в общем, космос...
Запросто могли быть альтернативой i286-м.
V>>100% профессионального ПО для персоналок было тогда под мак, а под IBM PC большей половины этого ПО даже не существовало. V>>8086 — это ширпотреб для бухгалтера или для какого-нить лаборанта, в обоих случаях замена программируемому калькулятору. )) V>>На фоне этой убогости маки смотрелись серьёзными машинками с крутой графикой и прочей мультимедиа. 4>Amiga по сравнению с Маком был гораздо более доступен, и использовался как раз для мультимедиа.
Но видео с эффектами редактировали на Маках.
А Амигу я видел в основном в игровых клубах.
Да, с мультимедией там порядок, как раз для игр.
V>>Мак проиграл гонку сугубо из-за ценовой политики — по нынешним деньгам с хорошим монитором стоил бы под $20 тыс. 4>Не только, Мак это вещь в себе, а PC всё-таки конструктор, позволял апгрейдится ...
Это тоже вопрос экономии денег и ничего более.
У мака, соответственно, вопрос зарабатывания денег.
Их сгубила жадность.
4>Доступность заимственного ПО позволила в кратчайшие сроки получить приличное число пусть и доморощенных, но при этом вполне хороших специалистов, причем не только программистов.
Доморощенные воспитывались на нашем ПО.
На западном ПО пришлось работать по необходимости затем, бо у нас к 93-му всё протухло окончательно, окончательно перепозли на IBM-совместимые компы.
V>>Единственно в бухгалтерии импорт не канал, поэтому этого добра от наших было полно и до сих пор наше бухгалтерское ПО одно из самых продвинутых в мире. V>>И почему ты считаешь, что в других областях наше ПО было бы хуже? 4>Так никто особо не мешал делать качественное ПО и в других областях, но кроме бухгалтерского ПО и антивирусов дело особо не пошло.
Причины я указал.
4>Помимо того чтобы делать, еще надо уметь продвигать и развивать, а вот с этим у нас не очень.
Это в эпоху развала не очень.
4>Я не совсем понимаю о чём речь, со второй половины 80-х отечественный рынок был завален домашними (и к сожалению плохосовместимыми друг с другом) машинками на базе КР580 (РК-86, Специалист, Вектор, Корвет, Орион ...) и 1801BMx (БК ...), + бесчисленные клоны Синклеров, т.е. машинного времени было предостаточно (в среднем цена подобного компа составляла 700 руб), проблема была в основном в получении знаний.
Оно было уровня прошлого дестилетия, увы.
Но да, за 80-е годы мы прошлое десятилетие догнали, с этим всё понятно.
Я и сам паял Ленинград-1 в 89-м, но за единицы месяцев "вырос" из него. ))
Современными нашими были только на основе 1801BM3.
Я много прогал на асме в те годы и после окончания ВУЗ-а тоже еще несколько лет, в багаже архитектуры 8080, z80, x86, 8031/8048, 8051, PDP-11, PIC, AVR, MIPS.
С т.з. программиста вменяемые только 4 последних, остальное ужас-ужас с т.ч. трезвого инженера.
Еще отдельной темой были сигнальные процы, но там заведомо понятно, что это такой программируемый вычислитель, т.е. программирование под сигнальные процы тех времён — это примерно как разработка внутренних ("железных") подпрограмм для публичных опкодов CISC-процов, т.е. классическая разработка автомата, где таблица истинности логической схемы закодирована в широком ПЗУ.
Здравствуйте, vdimas, Вы писали: V>В качестве числодробилки хорошо работает, ИИ, на больших циклах типа GC Mark-and-Sweep. V>Т.е. где не очень много ветвлений, но много вычислений. V>Задачи подобного плана самые нагрузочные сегодня.
Для таких задач ещё лучше работает SIMD. И для него гораздо проще строить компилятор.
V>Нужно железо. Много.
Не обязательно много. V>Даже если оно дорогое на сейчас — пораскидать по ВУЗ-ам для студней и аспирантуры. V>Для задач баловаться/программировать один хост обслужит десяток X-терминалов без проблем (там обычные линуха). V>В идеале и вовсе облако — с виртуализацией всё ОК с версии проца 16С, т.е. имеющийся облачный софт поверх KVM работает.
Да, тоже хороший вариант. Но он всего лишь умножает количество машин на коэффициент оверкоммита. Ноль хостов по-прежнему обслужат ноль терминалов.
Ну, и для более-менее массовости всё же нужно выводить это за пределы лабораторной сетки. Современные реальные студенты разработку ведут не в терминальном классе, а на личных машинах.
Ограничить их только X-терминалами к университетским компьютерам — не шибко хорошая идея. Только на нашем факультете обучается около 700 человек.
Ставить 70 хостов выглядит дороговато — тем более, что собственно исполнение/тестирование программы занимает обычно смешное время, и прекрасно работает через CI/CD системы.
S>>Целевой аудитории нужен софт, а не железки. V>Необходимая целевая аудитория на данном этапе — потенциальные программеры.
Вы смотрите на полшага вперёд. Целевая аудитория — это никакие не программеры. Программеры не будут заносить производителю столько денег, сколько нужно.
Их заносят конечные пользователи. Пользователи заносят деньги в обмен на пользу (однокоренные слова неслучайны).
Пользователи не будут платить деньги за фикции типа "импортозамещение" или "суверенитет" (те, которые будут — тоже есть, но это тупиково-распилочное направление, нам оно неинтересно).
За что они могут платить? За софт, которого а) нету на конкурентах (примеры можно рассмотреть в мире игровых консолей — см. тж. "эксклюзивы") либо б) работает лучше, чем на конкурентах.
За то, чтобы исполнять ровно такой же софт, как на конкурентах, чутка медленнее и существенно дороже, чем на конкурентах, пользователи платить не будут. Увы.
А вот для того, чтобы такой софт появился — уже нужны программисты. Не как самоцель, а как необходимое промежуточное звено. V>Причём, линукс-программерам традиционно пофик на железо, они не на асме пишут.
Эмм, линукс-программеры в широком смысле тут не очень релевантны. Они не дают вклада в популяризацию платформы — потому что их софт так и будет работать чутка медленнее, чем на интеле, за в разы больше денег, чем за интел.
Интересны разработчики компиляторов. А они как раз "пишут на асме", в некотором смысле.
V>Зато наличие железа позволит прямо по месту экспериментировать тем единицам процентов, кому, таки, железо тоже любопытно. V>При наличии железа, на эту тему пойдут курсовые, дипломные и кандидатские, впрочем, ты и сам эту кухню знаешь.
Чтобы ускорить процесс, железо в виде станций, серверов, и облаков, нужно ещё дополнить мотивирующим стимулом. Те самые конкурсы и хакатоны, про которые я тут писал.
Вот тогда — да, попрут и курсовые, и дипломные, и кандидатские.
V>Это всё было изначально.
Чего? V>Версия этой же операционки под именем «Эльбрус Линукс для x86» предназначена в т.ч. для виртуалок на твоём компе: V>
V>- позволяет ознакомиться и начать работать в среде «Эльбрус Линукс» без использования вычислительной техники Эльбрус;
V>- может служить площадкой для переноса (портирования) существующего программного обеспечения на платформу Эльбрус в архитектурно-независимой части этого процесса — при переходе на Linux с других операционных систем;
V>- может служить гостевой операционной системой при запуске программ в машинных кодах x86 на компьютерах архитектуры Эльбрус через двоичный транслятор.
V>Распространяется свободно и бесплатно.
Это всё не о том. Эта операционка никак не поможет, скажем, напилить дотнетный джит в систему команд Эльбруса. "Архитектурно-независимая часть" тут не заслуживает упоминания — линукс на то и линукс, что студент можнт освоить произвольный дистрибутив на своём любимом HP или макбуке, а потом сесть за совершенно другую архитектуру и не путаться, где тут grep, а где cat.
Если дистрибутив не окончательно наркоманский, то освоение "архитектурно-независимых" особенностей займёт пренебрежимо малое время.
V>Экосистема Линухов открыта.
S>>Это телега впереди лошади. Чипы сами по себе никому не нужны. Нужен софт, который решает прикладные задачи. V>В экосистеме линухов почти весь софт доступен в исходниках.
И? Это как-то магически сделает существующий софт дружелюбным к VLIW?
Вот, скажем, про дружелюбность к SIMD известно довольно много. Начиная с автовекторизации, и заканчивая встраиванием в исходники популярных матбиблиотек ветвлений по CPUID и наличию конкретных фич у процессора, внутри которых вставлены платформенно-специфичные интринсики.
Откуда в исходниках какого-нибудь OpenCV возьмутся платформенно-специфичные ветки для Эльбруса, если программистам недоступна ни железка, ни её эмулятор?
Откуда в библиотеках GCC возьмутся интринсики Эльбруса, чтобы разработчики могли внести их в исходники OpenCV?
Чудес-то не бывает.
V>Продолжайте наблюдения. ))
Да уж не первый год в продакт менеджменте работаю.
V>Даташиты процов открыты. V>Но без реального железа эти даташиты мало кому интересны.
Стоило бы начать хотя бы с эмулятора. Ну, чтобы понять, корректен ли вообще порождаемый джитом код, или нет.
V>Ну вот я низкоуровневый программер, мне очень даже интересно погонять некоторые вещи, типа user-space TCP-стека, посмотреть как работают аналоги RDTSC — в прошлых процах из мира x86 (но до сих пор часто встречающихся) были проблемы с этой операцией, которые я в своём коде должен обыгрывать. Без наличия реальной железки я ничего толком не посмотрю. Что мне дадут очередные "просто Линуха" без низкого уровня? Я и так каждый день на них время трачу, мне это не интересно.
Ну, в идеале — конечно да. Реальная железка должна стоять в нескольких экземплярах в каждом IT-вузе. Хотя бы — в топ-10 из этих ВУЗов.
Но на практике вместо этого у нас — вечные новости из будущего.
Отсюда и мой скепсис.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Их заносят конечные пользователи. Пользователи заносят деньги в обмен на пользу (однокоренные слова неслучайны). S>Пользователи не будут платить деньги за фикции типа "импортозамещение" или "суверенитет" (те, которые будут — тоже есть, но это тупиково-распилочное направление, нам оно неинтересно).
почему американские "пользователи" платят за создание своего аналога нашего РД-180, а наши не будут за создание своего аналога процессора?
схема мотивация одна и таже, прям зеркальная ситуация
Здравствуйте, MadHuman, Вы писали: MH>почему американские "пользователи" платят за создание своего аналога нашего РД-180, а наши не будут за создание своего аналога процессора? MH>схема мотивация одна и таже, прям зеркальная ситуация
Хороший вопрос. Сами на него сможете ответить?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>В качестве числодробилки хорошо работает, ИИ, на больших циклах типа GC Mark-and-Sweep. V>>Т.е. где не очень много ветвлений, но много вычислений. V>>Задачи подобного плана самые нагрузочные сегодня. S>Для таких задач ещё лучше работает SIMD.
Эльбрус — это и есть один сплошной SIMD:
— большой файл регистров;
— явный параллелизм;
— есть векторные инструкции;
Но параллелизм операций в Эльбрусе выше, чем у самых последних AVX, поэтому архитектурно обычный SIMD сходу сливает.
Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат: https://habr.com/ru/company/icl_services/blog/558564/
В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца.
SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
ИМХО, сочетание двух подходов может выстрелить, но это дело даже не следующей версии Эльбруса.
S>И для него гораздо проще строить компилятор.
Ес-но.
Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях.
V>>Нужно железо. Много. S>Не обязательно много.
По мне сотни тысяч — это достаточно много.
Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
V>>В идеале и вовсе облако — с виртуализацией всё ОК с версии проца 16С, т.е. имеющийся облачный софт поверх KVM работает. S>Да, тоже хороший вариант. Но он всего лишь умножает количество машин на коэффициент оверкоммита.
Ну да, поэтому не миллионы, как если бы персоналок, а сотни тыщ в облаках.
S>Ну, и для более-менее массовости всё же нужно выводить это за пределы лабораторной сетки. Современные реальные студенты разработку ведут не в терминальном классе, а на личных машинах.
В облаках есть свои преимущества, в т.ч. по уровню доступного железа.
Вопрос тут, как и везде, в удобстве и качестве инфраструктуры.
Будет удобно — будут пользоваться.
S>Ограничить их только X-терминалами к университетским компьютерам — не шибко хорошая идея. Только на нашем факультете обучается около 700 человек. S>Ставить 70 хостов выглядит дороговато — тем более, что собственно исполнение/тестирование программы занимает обычно смешное время, и прекрасно работает через CI/CD системы.
В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
А простое редактирование программы толком не занимает вовсе.
Тем более, что программы на ЯВУ можно редактировать/отлаживать на любых совместимых линухах, т.е. локально на той же amdx64-архитектуре в операцонке Эльбрус для amd_x64.
Речь о принципиальной возможности доступа к железу для целей экспериментов.
S>>>Целевой аудитории нужен софт, а не железки. V>>Необходимая целевая аудитория на данном этапе — потенциальные программеры. S>Вы смотрите на полшага вперёд.
Я просто хорошо помню как развивалась отрасль.
Софтово-железная экосистема должна обладать полнотой, чтобы иметь шанс быть наполненной специалистами.
Мы ж, программеры, люди не просто ленивые, но еще достаточно вредные/предвзятые. ))
S>Целевая аудитория — это никакие не программеры. Программеры не будут заносить производителю столько денег, сколько нужно.
О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему.
Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
Т.е. вопрос заведомо затратный, но неизбежный.
S>Их заносят конечные пользователи. Пользователи заносят деньги в обмен на пользу (однокоренные слова неслучайны).
Пользователями современного топового железа в основном выступают облака.
Современный мир крутится вокруг сервисов.
Собсно, банальности...
S>Пользователи не будут платить деньги за фикции типа "импортозамещение" или "суверенитет" (те, которые будут — тоже есть, но это тупиково-распилочное направление, нам оно неинтересно).
Но будут платить за хостинг сервисов.
S>За что они могут платить? За софт, которого а) нету на конкурентах (примеры можно рассмотреть в мире игровых консолей — см. тж. "эксклюзивы") либо б) работает лучше, чем на конкурентах.
Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
Т.е. вопрос будет в цене аренды и ни в чём больше.
S>За то, чтобы исполнять ровно такой же софт, как на конкурентах, чутка медленнее и существенно дороже, чем на конкурентах, пользователи платить не будут. Увы.
Ес-но, если дороже.
А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.
S>А вот для того, чтобы такой софт появился — уже нужны программисты. Не как самоцель, а как необходимое промежуточное звено.
ИМХО, из экосистемы бесполезно пытаться выкидывать отдельные элементы или пытаться рассуждать о сравнительной важности отдельных элементов.
V>>Причём, линукс-программерам традиционно пофик на железо, они не на асме пишут. S>Эмм, линукс-программеры в широком смысле тут не очень релевантны. Они не дают вклада в популяризацию платформы — потому что их софт так и будет работать чутка медленнее, чем на интеле, за в разы больше денег, чем за интел.
Не факт, что за большие деньги.
Дотации от гос-ва еще никто не отменял.
IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно.
S>Интересны разработчики компиляторов. А они как раз "пишут на асме", в некотором смысле.
Об этих долях процентов я и говорил, что возможность "поиграть" должна быть в шаговой доступности.
Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных.
Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё.
Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить".
V>>При наличии железа, на эту тему пойдут курсовые, дипломные и кандидатские, впрочем, ты и сам эту кухню знаешь. S>Чтобы ускорить процесс, железо в виде станций, серверов, и облаков, нужно ещё дополнить мотивирующим стимулом.
Небанальность — тоже неплохой стимул. ))
Всегда интересно резвиться в той области, где еще не всё изъезженно.
S>Те самые конкурсы и хакатоны, про которые я тут писал.
Мои дети выигрывали хакатоны, но там всегда на ЯВУ, конкретное железо не принципиально.
S>Вот тогда — да, попрут и курсовые, и дипломные, и кандидатские.
Например, в такой отсталой в деле IT стране, как РФ, разработаны одни из лучших систем в мире в области ИИ.
И в этой области оно продолжает набирать обороты.
Т.е., академический подход в научноёмких областях себя оправдывает.
Тут нам и карты в руки.
S>Это всё не о том. Эта операционка никак не поможет, скажем, напилить дотнетный джит в систему команд Эльбруса.
Эээ...
Ты думал, джит для ARM писали на ARM-ах? ))
Для задач навроде разработки джита нужен вменяемый эмулятор и кросс-компиляция.
S>"Архитектурно-независимая часть" тут не заслуживает упоминания — линукс на то и линукс, что студент можнт освоить произвольный дистрибутив на своём любимом HP или макбуке, а потом сесть за совершенно другую архитектуру и не путаться, где тут grep, а где cat.
Таки, особенности есть в каждой архитектуре Linux.
Семейства Debian, RHEL или openSUSE — это как разные вселенные...
Почти ежедневно с ними работаю, там хватает особенностей в деле настройки рабочего окружения.
S>Если дистрибутив не окончательно наркоманский, то освоение "архитектурно-независимых" особенностей займёт пренебрежимо малое время.
Верно.
Именно поэтому за основу Эльбрус ОС было взято самое массовое семейство — Debian.
Хотя еще есть достаточно уникальная, но популярная у нас сборка ALT, они тоже поддерживают Эльбрус.
S>>>Это телега впереди лошади. Чипы сами по себе никому не нужны. Нужен софт, который решает прикладные задачи. V>>В экосистеме линухов почти весь софт доступен в исходниках. S>И? Это как-то магически сделает существующий софт дружелюбным к VLIW?
Это задача компилятора.
S>Откуда в исходниках какого-нибудь OpenCV возьмутся платформенно-специфичные ветки для Эльбруса
Ниоткуда, компиляция пойдёт по дефолтной ветке.
Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
S>Откуда в библиотеках GCC возьмутся интринсики Эльбруса, чтобы разработчики могли внести их в исходники OpenCV?
Зачем?
Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
А у Эльбруса весь код, считай, SIMD.
S>Чудес-то не бывает. V>>Продолжайте наблюдения. )) S>Да уж не первый год в продакт менеджменте работаю.
Ты уже не первый год делаешь громкие заявления, не удосужившись хотя бы поверхностно пройтись по вопросу.
V>>Даташиты процов открыты. V>>Но без реального железа эти даташиты мало кому интересны. S>Стоило бы начать хотя бы с эмулятора. Ну, чтобы понять, корректен ли вообще порождаемый джитом код, или нет.
Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты.
Но, согласен, для полного цикла разработки нужно или железо или эмулятор.
Внутренний эмулятор МЦСТ для этих нужд непригоден, он для внутренних целей разработки.
Опенсорсный эмулятор для QEMU разрабатывают прямо сейчас.
Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд.
Т.е., задачи подобного рода у нас решать умеют и умеют неплохо.
V>>Ну вот я низкоуровневый программер, мне очень даже интересно погонять некоторые вещи, типа user-space TCP-стека, посмотреть как работают аналоги RDTSC — в прошлых процах из мира x86 (но до сих пор часто встречающихся) были проблемы с этой операцией, которые я в своём коде должен обыгрывать. Без наличия реальной железки я ничего толком не посмотрю. Что мне дадут очередные "просто Линуха" без низкого уровня? Я и так каждый день на них время трачу, мне это не интересно.
S>Ну, в идеале — конечно да. Реальная железка должна стоять в нескольких экземплярах в каждом IT-вузе. Хотя бы — в топ-10 из этих ВУЗов. S>Но на практике вместо этого у нас — вечные новости из будущего.
Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми.
S>Отсюда и мой скепсис.
И мой многолетний, хотя одному из сыновей я дал год назад совет продолжать работать в МЦСТ (разрабатывает этот проц), т.к. достойная реализация этой темы просто неизбежна, у РФ нет другого выхода. И этот рынок труда явно не натоптан, там не тесно, таких спецов в стране напересчёт.
Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD.
Ну вот сейчас зашевелятся.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну тут прям противоречие. По сути "интеловский out-of-order execution" это и есть тот самый "оптимизирующий компиятор", но реализованный в железе.
НС>Увы, но нет. Подход VLIW — он статический, компилятор все должен предсказать все заранее, в лучшем случае на базе PGO. А вот железный транслятор — он динамический, опирается на статистику реального выполнения.
Что "статистика реального выполнения"?
Как ты думаешь, что такое "статистика реального выполнения",
и как она может повлиять на работу процессора и распараллеливание команд?
Ты что думаешь, что необходимые действия для вычислений как-то со временем меняются?
Здравствуйте, MadHuman, Вы писали: MH>почему американские "пользователи" платят за создание своего аналога нашего РД-180, а наши не будут за создание своего аналога процессора? MH>схема мотивация одна и таже, прям зеркальная ситуация
американские "пользователи" платят деньги тем, кто может в наш аналог РД-180 и знают зачем он им нужен
если целеполаганием является "устаревшее говно, но свое" за безразмерные казенные деньги, то не нужно удивляться результату
как и его отсутствию
Здравствуйте, vdimas, Вы писали: V>Эльбрус — это и есть один сплошной SIMD: V>- большой файл регистров; V>- явный параллелизм; V>- есть векторные инструкции;
Ну всё таки нет. у SIMD есть офигенное преимущество — single instruction. То есть тайминг всей команды одинаковый. Не бывает так, что пять блоков уже вычислились, а три ещё тупят.
V>Но параллелизм операций в Эльбрусе выше, чем у самых последних AVX, поэтому архитектурно обычный SIMD сходу сливает.
Это какая у него разрядность вектора? V>Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат: V>https://habr.com/ru/company/icl_services/blog/558564/
Это значит, что в кодеген компилятора встроили автовекторизацию простых циклов.
V>В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца.
Ну, так я понял, что идея к тому и сводится, чтобы недостатки технологии обойти достоинствами архитектуры.
V>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
Чего там высокоуровневого? FMADD? V>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось. V>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
Взамен давая серъёзные преимущества. V>ИМХО, сочетание двух подходов может выстрелить, но это дело даже не следующей версии Эльбруса.
V>Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях.
Это если вручную. Но вручную и VLIW выписывать не шибко удобнее.
V>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.
V>Будет удобно — будут пользоваться.
Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Но желания, как видим, никакого нет.
V>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы. V>А простое редактирование программы толком не занимает вовсе.
Редактирование программы нужно делать в нормальной IDE. Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.
V>Тем более, что программы на ЯВУ можно редактировать/отлаживать на любых совместимых линухах, т.е. локально на той же amdx64-архитектуре в операцонке Эльбрус для amd_x64. V>Речь о принципиальной возможности доступа к железу для целей экспериментов.
Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.
V>О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему.
Очень малая у неё инерция. Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
Или там — вот у нас суперновый чип A1, экзотический язык программирования и среда разработки — и хооп! сотни тысяч программ в аппсторе, миллиарды оборота.
V>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д. V>Т.е. вопрос заведомо затратный, но неизбежный.
Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.
V>Пользователями современного топового железа в основном выступают облака.
Облака тоже не являются никакой самоценностью. Облака — всего лишь инструмент. Они востребованы настолько, насколько востребован софт, крутящийся в облаках.
V>Но будут платить за хостинг сервисов.
Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Например — более быстрый рендер графики, или более быстрый тренинг НС.
Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике. Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.
В итоге мы опять упираемся в академические исследования и фундаментальные разработки.
V>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями". Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле. Пока что таких задач — исчезаюше мало.
Ровно потому, что людей, умеющих оптимизировать софт под VLIW, единицы штук в мире.
V>Ес-но, если дороже. V>А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.
Расскажите про это тем, кто обучает НС.
V>Дотации от гос-ва еще никто не отменял.
Но и никто не видел V>IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно.
Жаль, что кроме нас с вами, это мало кто понимает.
V>Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных. V>Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё. V>Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить".
Повторюсь: чтобы он выстрелил, нужны некоторые предварительные шаги. Прямо сейчас, как и в последние 10 лет, я этих шагов не наблюдаю.
V>Небанальность — тоже неплохой стимул. )) V>Всегда интересно резвиться в той области, где еще не всё изъезженно.
Конечно. Но для начала нужна возможность. По факту в ВУЗах нет ни железок, ни эмуляторов. Отсюда имеем эти полторы статьи в год по интересующей теме.
V>Мои дети выигрывали хакатоны, но там всегда на ЯВУ, конкретное железо не принципиально.
Хакатон — он про то, про что организовали. Там есть про всё. Есть такие, где ЯВУ непринципиален, а принципиально использование конкретного API. Есть такие, где принципиально использование ограниченного объёма памяти. В общем — целиком зависит от фантазии авторов и поставленных ими целях.
V>Например, в такой отсталой в деле IT стране, как РФ, разработаны одни из лучших систем в мире в области ИИ. V>И в этой области оно продолжает набирать обороты. V>Т.е., академический подход в научноёмких областях себя оправдывает. V>Тут нам и карты в руки. V>Для задач навроде разработки джита нужен вменяемый эмулятор и кросс-компиляция.
Вы повторяете то же самое, что я писал, только другими словами.
V>Почти ежедневно с ними работаю, там хватает особенностей в деле настройки рабочего окружения.
С точки зрения устройства компилятора и академического интереса — несущественные мелочи.
V>Это задача компилятора.
Повторю вопрос: кто напишет компилятор?
V>Ниоткуда, компиляция пойдёт по дефолтной ветке. Тогда и производительность будет дефолтная. V>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
Спасибо, я в курсе, как работают макросы в С
V>Зачем?
Эмм, чтобы обойти тупость компилятора. V>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено. V>А у Эльбруса весь код, считай, SIMD.
В том-то и дело. Вот в оракле закопали довольно много труда в автовекторизатор джавы. И что? Выхлоп по-прежнему очень слабый; шаг вправо-влево — и упс, приплыли.
Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
V>Ты уже не первый год делаешь громкие заявления, не удосужившись хотя бы поверхностно пройтись по вопросу. Ну, вот я прошёлся. Если из ваших ответов выбросить нерелевантные рассуждения, то вы в целом подтверждаете мои "громкие заявления".
V>Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты. Для этого нужно знать, какие байты корректны, а какие — нет.
Если у вас нет эмулятора, то байты вы выписываете вручную. И при ошибке в выписывании ваш компилятор тестируется ошибочным тестом.
V>Но, согласен, для полного цикла разработки нужно или железо или эмулятор. V>Опенсорсный эмулятор для QEMU разрабатывают прямо сейчас.
Есть ссылки на этот проект?
V>Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд.
Он практически бесполезен для обсуждаемой задачи.
V>Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми.
Я вот этого вот "сейчас зашевелятся" жду с 2008. Продолжаем принимать новости из будущего.
V>Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD. V>Ну вот сейчас зашевелятся. Ждём с нетерпением.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Речь именно об узких специалистах, а не о "прослушал курс".
