Место, скорее всего, хорошее было. Я предположу, что раз это мейнфреймы, то возможно zOS или AIX или HP-UX какой-нибудь. Когда я в 2012-2013 писал под такое дело софт, они очень и очень были за бугром еще востребованы.
Но если программист не в состоянии учиться каждый день, он профессионально непригоден
Я не в состоянии учиться каждый день, вот правда. Время от времени - да, но на каждый день меня не хватит. За всю карьеру 4 раза менял стек и 5 раз область, мне 34.
Если вы знаете теорию вероятностей, но не можете ею стабильно зарабатывать на бирже – это иллюзия.
Предсказал - купил - проиграл. Предсказал - купил - проиграл. Предсказал - деньги кончились. Значит ли это, что человек не знает теорию вероятностей? Нет. Мог и знать, просто не повезло, потому как это это тоже вероятно. Также можно набросить "если знаете тервер, но не зарабатываете в казино - то вы не знаете тервер", что тоже заблуждение (и подозреваю, именно знание тервера не дает людям играть в казино).
Если вы знаете психологию, но не можете с её помощью занять наиболее комфортное положение в обществе – это иллюзия.
Можно знать психологию, но быть, например, инвалидом без обеих ног в стране, где без ног не проживешь (Африка и тд). Можно знать психологию, но иметь, например, уродство, или, например, шизофрению, или СДВГ в декомпенсационной стадии, или многолетнюю депрессию, или долг от умершего родственника, на оплату которого будут уходить все деньги на протяжении всей жизни...
это правда, Страуструп по-моему тоже об этом писал (ссылку лень искать). Продуманное владение почти вытесняет shared_ptr, и более того, без продуманного владения shared_ptr не спасет, будут либо циклические ссылки все равно, либо weak_ptr-ы пустые тогда, когда объект еще нужен, и так далее. Однако shared_ptr нужен, если у вас многопоточка, и потоки друг другом не владеют и друг друга не ждут.
в C++ очень сложно сделать так, чтобы ваш код сделал нежелательные вещи
да ладно??
Автор (оригинала) видимо до STL еще не добрался, не удалял текущий итератор, не разыменовывал битый итератор, не забывал проверить итератор на end, не натыкался на виртуальные деструкторы, не забывал копирущий конструктор/оператор, не инициализировал члены класса не в том порядке, не забывал один из shared_ptr-ов сделать weak_ptr-ом, не передавал случайно здоровенный vector по значению, не забывал виртуально отнаследоваться, когда внезапно оба родителя имеют общего предка ...
Хотя это может просто у меня в свое время руки кривоваты были, не знаю.
но почему неконкурентными методами-то? Вполне рыночная борьба за госзаказчика. Перспекивность RISC-V можно сказать доказана, есть вот такой вот прессрелиз (pdf), также как и синтакор доказали, что могут в RISC-V, есть у них продукты на ее базе.
Сейчас в реальном процессоре общего назначения сделан огромный уклон в параллелизм и это самый branch-prediction
Фиксированная длина команды неплохо параллелизму способствует. Можно одновременно читать несколько соседних команд, а не ждать, пока раскодируется предыдущая, чтобы узнать, где начинается следующая.
В современных процессорах интел длинные команды разбиваются на такие же мелкие как и в arm и в risc-v
и жрут электричество на это все.
Производительность критически зависит от работы с памятью, в микроконтроллерах это никак не влияет на производительность и risc-v там крутые, но в пк общего назначений risc-v будет так же как и интел упираться в ожидание чтения из памяти, ибо шина там очень мендленная
поэтому плотность кода и рулит.
В частоте у эльбруса нет проблем, уже работает 1.5 ГГц
У меня 1.5Ггц было в 2003м что ли году на домашнем компе.
именно оптимизации, а не архитектура RISC-V дают прирост в производительности в реальных задачах в разы. И такие оптимизации есть не только внутри архитектуры, они так же содержатся внутри компиляторов, и у Эльбруса лишь чуть больший закос именно в компиляторы.
Не соглашусь. Архитектура можно сказать определяет скорость. Есть такой параметр как плотность кода, и этот параметр также вносит очень существенный вклад в производительность, и зависит он исключительно от архитектуры. И у эльбруса плотность кода низкая, а у RISC-V - высокая (самая высокая из известных архитектур), там используются сжатые команды и макрооперации. Еще огромное преимущество RISC - фиксированная длина команды, а это значит, что подгрузка команд из памяти легко параллелится. Также архитектура влияет на максимальные частоты, и что-то не получается сделать эльбрус с нормальной частотой. А по поводу оптимизаций - какие-то оптимизации можно сделать только аппаратно, например тот же branch prediction. Спекулятивное исполнение тоже можно сделать более экономным с точки зрения потребляемого электричества, если делать его аппаратно. Еще VLIW - это много регистров (192 что ли на эльбрусе), а значит, переключение контекста становится очень долгим процессом, надо же все эти регистры в память как-то сохранить/вычитать.
Короче, архитектура VLIW и эльбруса в частности для процессоров общего назначения - полный отстой, а RISC-V - молодец.
На практике проблемы с подстановкой функций будут встречаться если вызываемая в горячем коде функция располагается в другом модуле, и компилятор не видит её тело. Что ж, я за такой код бил бы линейкой по пальцам независимо от целевой платформы.
Даже если опустить то, что физическое воздействие на человека в принципе в современном мире считается неприемлемым и унизительным, за какой "такой" код вы собрались бить людей по пальцам, да еще и линейкой? Что, из .so-шки уже метод нельзя дернуть? Полиморфизм в рантайме - тоже табу? Ну так как бы и зачем он нужен такой процессор, которому простой косвенный вызов поломает вообще все?
Про проигрыш эльбрусов в производительности:
Добрый день, а это то откуда следует? Ни одной цифры для подобных выводов вообще не приведено в статье.
Есть статьи на хабре с бенчмарками эльбрус vs intel (в том числе core i7 2600), например здесь , и что-то эльбрус мягко говоря не очень, даже если пересчитать производительность хоть на такт, хоть на ватт, хоть на рубль, хоть как, производительность - плоха.
Про то, что нужно будет разобраться в коде, чтобы определить, что не так и что не соптимизировалось:
Я бы мог много написать про то что программистам неплохо бы разбираться в компьютерах
Я разбираюсь в компьютерах, но читать эту вырвиглазную VLIW-простыню с крутящимися регистрами, которая именуется ассемблерным кодом, нет абсолютно никакого желания. Наверное, надо быть совсем слепым, чтобы не видеть фактов, что переход на данную архитектуру - сущий ад.
В момент продвижения архитектуры ARM все дружно двинулись переносить своё ПО на него, никто не говорил что собственная архитектура — это плохо. Сейчас в Европе активно продвигается RISC-V, но никто не плачет о новой несовместимой архитектуре — все дружно берут и переносят своё ПО. Но почему-то как только речь заходит про архитектуру Эльбрус, сразу начинаются стоны о том что своё — это плохо и сложно.
Да, плохо и сложно. И с лицензией непонятно что. На ARM все кинулись переносить ПО, потому что видно было, что это перспективная энергоэффективная архитектура. С RISC-V все хорошо тем, что это открытая архитектура, значит не будет проблем с лицензиями, это раз, и опять же, много кто считает ее перспективной - это 2.
Не, выстрел в момент совпадения траекторий - отстой. Надо маятник на пружинной подвеске запилить под стволом, чтобы можно было, дергая маятник в нужном направлении, доприцеливать ствол, разумеется автоматически. И на спуск автоматически нажимать. А то пользователю это все лень делать - прицеливаться, стрелять еще...
С бумагой, я думаю, не сильно проще и не сильно сложнее делать подтасовки, одного порядка задача. Хотя бы на уровне избирательных участков есть возможность контроля. Но все равно там все в эту ГАС выборы сгружается, и как она подсчитает - одним разработчикам известно (но они не скажут).
ну если сделают действительно так, тогда да, в принципе разумная достаточность присутствует. Зависит еще конечно от программульки. Открытые исходные коды тоже разными бывают, может там из открытого - выкачивание .so-шника и дергание из него методов. Посмотрим, короче. Но немного оптимизма прибавилось, спасибо.
Место, скорее всего, хорошее было. Я предположу, что раз это мейнфреймы, то возможно zOS или AIX или HP-UX какой-нибудь. Когда я в 2012-2013 писал под такое дело софт, они очень и очень были за бугром еще востребованы.
Я не в состоянии учиться каждый день, вот правда. Время от времени - да, но на каждый день меня не хватит. За всю карьеру 4 раза менял стек и 5 раз область, мне 34.
Предсказал - купил - проиграл. Предсказал - купил - проиграл. Предсказал - деньги кончились. Значит ли это, что человек не знает теорию вероятностей? Нет. Мог и знать, просто не повезло, потому как это это тоже вероятно. Также можно набросить "если знаете тервер, но не зарабатываете в казино - то вы не знаете тервер", что тоже заблуждение (и подозреваю, именно знание тервера не дает людям играть в казино).
Можно знать психологию, но быть, например, инвалидом без обеих ног в стране, где без ног не проживешь (Африка и тд). Можно знать психологию, но иметь, например, уродство, или, например, шизофрению, или СДВГ в декомпенсационной стадии, или многолетнюю депрессию, или долг от умершего родственника, на оплату которого будут уходить все деньги на протяжении всей жизни...
Назвали Angular, но не назвали Spring, Hibernate, ... - это точно для джависта список?
Protobuf-а еще нет.
OLTP-базы - это реляционки обычно же. Наверное, OLAP все же имелся в виду.
Хадупово-спарковский стек aka Hadoop/HBase/Spark/... тоже можно было бы до кучи, а что, Angular знать надо, а спаркохадуп - нет?
это правда, Страуструп по-моему тоже об этом писал (ссылку лень искать). Продуманное владение почти вытесняет shared_ptr, и более того, без продуманного владения shared_ptr не спасет, будут либо циклические ссылки все равно, либо weak_ptr-ы пустые тогда, когда объект еще нужен, и так далее. Однако shared_ptr нужен, если у вас многопоточка, и потоки друг другом не владеют и друг друга не ждут.
да ладно??
Автор (оригинала) видимо до STL еще не добрался, не удалял текущий итератор, не разыменовывал битый итератор, не забывал проверить итератор на end, не натыкался на виртуальные деструкторы, не забывал копирущий конструктор/оператор, не инициализировал члены класса не в том порядке, не забывал один из shared_ptr-ов сделать weak_ptr-ом, не передавал случайно здоровенный vector по значению, не забывал виртуально отнаследоваться, когда внезапно оба родителя имеют общего предка ...
Хотя это может просто у меня в свое время руки кривоваты были, не знаю.
del
ну за исключением возможно топовых, да. Я к тому, что нейросетки на эльбрусах также бесперспективно считать.
но почему неконкурентными методами-то? Вполне рыночная борьба за госзаказчика. Перспекивность RISC-V можно сказать доказана, есть вот такой вот прессрелиз (pdf), также как и синтакор доказали, что могут в RISC-V, есть у них продукты на ее базе.
в статье вы высказывали другое мнение
интел чуток споткнется на branch predictor-е, а у эльбруса поломаются все его хваленые оптимизации
Низачотку не забудьте, пожалуйста
Да вроде не копейки, существенная часть от всего, что через процессор проходит
Фиксированная длина команды неплохо параллелизму способствует. Можно одновременно читать несколько соседних команд, а не ждать, пока раскодируется предыдущая, чтобы узнать, где начинается следующая.
и жрут электричество на это все.
поэтому плотность кода и рулит.
У меня 1.5Ггц было в 2003м что ли году на домашнем компе.
Не соглашусь. Архитектура можно сказать определяет скорость. Есть такой параметр как плотность кода, и этот параметр также вносит очень существенный вклад в производительность, и зависит он исключительно от архитектуры. И у эльбруса плотность кода низкая, а у RISC-V - высокая (самая высокая из известных архитектур), там используются сжатые команды и макрооперации. Еще огромное преимущество RISC - фиксированная длина команды, а это значит, что подгрузка команд из памяти легко параллелится. Также архитектура влияет на максимальные частоты, и что-то не получается сделать эльбрус с нормальной частотой. А по поводу оптимизаций - какие-то оптимизации можно сделать только аппаратно, например тот же branch prediction. Спекулятивное исполнение тоже можно сделать более экономным с точки зрения потребляемого электричества, если делать его аппаратно. Еще VLIW - это много регистров (192 что ли на эльбрусе), а значит, переключение контекста становится очень долгим процессом, надо же все эти регистры в память как-то сохранить/вычитать.
Короче, архитектура VLIW и эльбруса в частности для процессоров общего назначения - полный отстой, а RISC-V - молодец.
Ну по коду в примере все заинлайнилось, и цикл внутренний в процедуре square раскуртился, компилятор lcc.
нет, средненький GPU на задачах нейросетки порвет эльбруса по всем фронтам
Даже если опустить то, что физическое воздействие на человека в принципе в современном мире считается неприемлемым и унизительным, за какой "такой" код вы собрались бить людей по пальцам, да еще и линейкой? Что, из .so-шки уже метод нельзя дернуть? Полиморфизм в рантайме - тоже табу? Ну так как бы и зачем он нужен такой процессор, которому простой косвенный вызов поломает вообще все?
Про проигрыш эльбрусов в производительности:
Есть статьи на хабре с бенчмарками эльбрус vs intel (в том числе core i7 2600), например здесь , и что-то эльбрус мягко говоря не очень, даже если пересчитать производительность хоть на такт, хоть на ватт, хоть на рубль, хоть как, производительность - плоха.
Про то, что нужно будет разобраться в коде, чтобы определить, что не так и что не соптимизировалось:
Я разбираюсь в компьютерах, но читать эту вырвиглазную VLIW-простыню с крутящимися регистрами, которая именуется ассемблерным кодом, нет абсолютно никакого желания. Наверное, надо быть совсем слепым, чтобы не видеть фактов, что переход на данную архитектуру - сущий ад.
Да, плохо и сложно. И с лицензией непонятно что. На ARM все кинулись переносить ПО, потому что видно было, что это перспективная энергоэффективная архитектура. С RISC-V все хорошо тем, что это открытая архитектура, значит не будет проблем с лицензиями, это раз, и опять же, много кто считает ее перспективной - это 2.
Не, выстрел в момент совпадения траекторий - отстой. Надо маятник на пружинной подвеске запилить под стволом, чтобы можно было, дергая маятник в нужном направлении, доприцеливать ствол, разумеется автоматически. И на спуск автоматически нажимать. А то пользователю это все лень делать - прицеливаться, стрелять еще...
С бумагой, я думаю, не сильно проще и не сильно сложнее делать подтасовки, одного порядка задача. Хотя бы на уровне избирательных участков есть возможность контроля. Но все равно там все в эту ГАС выборы сгружается, и как она подсчитает - одним разработчикам известно (но они не скажут).
ну если сделают действительно так, тогда да, в принципе разумная достаточность присутствует. Зависит еще конечно от программульки. Открытые исходные коды тоже разными бывают, может там из открытого - выкачивание .so-шника и дергание из него методов. Посмотрим, короче. Но немного оптимизма прибавилось, спасибо.
дело не в наилучшем, а в легитимном кандидате