IT в России и мире в реалиях мирового кризиса

Цитата: ps_ от 05.01.2017 17:05:28Я правильно понял, что ядро скомпилировано для "родной" системы команд, а все остальное работает под эмулятором x86?

Нет. Вся система собрана под целевой процессор, ну может быть за вычетом того же openjdk и каких-то мелочей. С openjdk вообще ситуация смешная. По слухам - нативная версия работает медленнее, чем собранная для x86 в режиме эмуляции. Очень уж неудобный оказался код для VLIW, в лоб не дается. Это же (скорее всего) касается и прочих динамических языков, типа javascript.

Цитата: ps_ от 05.01.2017 17:05:28А Вы пробовали скомпилировать какие-нибудь простые тесты в "родной" системе команд и сравнивнить быстродействие с эмулятором и соседней машиной на x86?

Я не спец по тестированию-сборке. Что под руку попалось, то и использовал для получения первичных грубых оценок. Поэтому по данному вопросу самому интересно было бы услышать советы о том, какие тесты стоит собрать и погонять. Если будут дельные мысли - воспользуюсь и результатами поделюсь, в т.ч. в сравнении с x86 серверами.

Цитата: ps_ от 05.01.2017 17:05:28А вообще насколько быстро все работает с точки зрения обычного пользователя? Ну если сидеть в GUI, лазить по интернету и что-нибудь простое писать на OpenOffice?

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

Цитата: TydymBydym от 05.01.2017 15:10:15Год назад наша контора получала на тестирование сервер на Эльбрус-4С. В этом году получили сервер на Эльбрус-8С.
Если камрадам интересно, можем немного на эту тему пообщаться.
В целом, впечатления неоднозначные

Доклад представителя АО «МЦСТ» на НСКФ-2016. "Платформа «Эльбрус»: состояние и перспективы". Ноябрь 2016.

[movie=400,300]https://youtu.be/WLQU3P64Uk0[/movie]
Есть немного информации об архитектуре.
 

Цитата: TydymBydym от 05.01.2017 16:56:45java работа была неудовлетворительной...

Я бы не удивился. А где она работает хотя бы удовлетворительно? На Андроиде- и там не умеет. Все тесты производительности можно производить только на родном коде. Но и там будут глюки компилятора возникать.. Вот их и нужно ловить. Но для этого писать программы нужно для конкретной платформы. Я уж тут писал, что переделка программы с С++ на обычный С дала прирост производительности в 10+ раз на ровном месте (Itanium, VLIV...). А уж эмуляция...

Цитата: Valery от 06.01.2017 00:19:32Я бы не удивился. А где она работает хотя бы удовлетворительно?

Да нормально она работает в среднем по палате. Радиус кривизны кода соответствует среднему по больнице.
Я пишу не спора ради, а по принципу "если что вижу - то и пишу, чего не вижу - о том не пишу".
Движуха на предмет отечественных процессоров мне заметна уже года два на собственном опыте. Тренд на импортозамещение и худо-бедно, но результат будет, насколько я могу судить. Хотя и косяков хватает, но куда же без них в реальном деле?...

ТК Таволга (MIPS), Сервера, ПК и ТК на основе Эльбруса - это только то что к нам попадало. За последний год, если судить по новым моделям, прогресс ощутим. Еще пару лет и с этим можно будет относительно безболезненно работать, кмк.
Сейчас вот, по разной информации, не только мы будем дистр по Эль перетачивать (ну или делать попытки), но и некоторые другие российские производители

Цитата: TydymBydym от 05.01.2017 17:19:38Нет. Вся система собрана под целевой процессор, ну может быть за вычетом того же openjdk и каких-то мелочей. С openjdk вообще ситуация смешная. По слухам - нативная версия работает медленнее, чем собранная для x86 в режиме эмуляции. Очень уж неудобный оказался код для VLIW, в лоб не дается. Это же (скорее всего) касается и прочих динамических языков, типа javascript.

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

Цитата: mrt789 от 06.01.2017 18:49:30Так в режиме эмуляции на эмулируемый-то x86 наверное JIТ отрабатывает, и продуцирует код для x86. А вот собранная и запущенная жаба целиком под эльбрус... ну она интерпретирует чего-то...

Да, конкретно с openjdk так дело и обстоит (с чужих слов). После праздников проверю, отпишусь.

Цитата: TydymBydym от 05.01.2017 17:19:38Нет. Вся система собрана под целевой процессор, ну может быть за вычетом того же openjdk и каких-то мелочей. С openjdk вообще ситуация смешная. По слухам - нативная версия работает медленнее, чем собранная для x86 в режиме эмуляции. Очень уж неудобный оказался код для VLIW, в лоб не дается. Это же (скорее всего) касается и прочих динамических языков, типа javascript.

Я готов вангануть еще раз. Посмотрев известное видео, с бенчмарком из двух циклов на сях, послушав выступающего ("у нас нет предсказания переходов" и "подготовка к переходу начинается за 6 тактов"), а также послушав вопросы, которые резко прервали, я могу предположить что в эльбрусе все не очень хорошо с "ценой" этих самых переходов по сравнению с современными x86'ыми.

А теперь возвращаемся к:

>Это же (скорее всего) касается и прочих динамических языков, типа javascript.

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

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

----------------

https://www.youtube.…LQU3P64Uk0

Цитата: mrt789 от 07.01.2017 15:02:18... послушав вопросы, которые резко прервали, я могу предположить

Вопросы прервали потому, что был очень жесткий регламент. НСКФ имеет интересную особенность -- за редким исключением (у доклада один автор, он заболел и не смог приехать) все заявленные в програме доклады докладываются. В частности, за три дня в этом зале было пропущено всего два доклада. Каждому дается 15 минут на доклад и 5 на вопросы. Как распределит это время докладчик -- его дело. Докладчик из МЦСТ, как можно было заметить, в конце вообще доклад практически свернул, потому что не успевал. Вопросы были по делу, хотя и на некотором агрессивном надрыве. Это был кто-то из конкурирующей фирмы. Там кроме МЦСТ выступали господа москвачи из интел и амд.

Цитата: mrt789 от 07.01.2017 15:02:18"у нас нет предсказания переходов" и "подготовка к переходу начинается за 6 тактов"

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

Цитата: mrt789 от 07.01.2017 15:02:18
Что делает интерпретатор/рантайм? Правильно, бегает по некоему внутреннему представлению исполняемого скрипта ("байт-код") и, в зависимости от того на чем он сейчас находится, передает управление туды (в нативные функции стандартной библиотеки) или сюды (сам переходит на другой участок, меняя порядок выполнения).

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

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

Цитата: TydymBydym от 07.01.2017 23:39:17Пфффф
Конечно у них нет предсказания переходов, это же одна из основных фишек - никаких спекуляций на уровне железа, всё делает компилятор. Это безоценочное суждение, спорить о преимуществах и недостатках не буду.

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

Читаю я это... Смотрю на реальные системы...
Если современные системы переписать на нормальные языки программирования, то компьютеры нынешнего уровня летать уже должны бы. А оказалось, что мои древние Sony S320  и Pocket LOOX (на PalmOs) давали мне такой-же комфорт, как и вполне современные андроиды. И древний Атлон 1800+ работал  не хуже, чем i5 (в игры не играю). Может, программы писать наконец-то руками и головой нужно, а не как сейчас...? И использовать нормальные инструменты для этого (максимально приближенные к архитектуре системы). Тогда и работать будет все быстро. И Эльбрус самый младший избыточным окажется...

Цитата: TydymBydym от 07.01.2017 23:39:17Пфффф
Конечно у них нет предсказания переходов, это же одна из основных фишек - никаких спекуляций на уровне железа, всё делает компилятор. Это безоценочное суждение, спорить о преимуществах и недостатках не буду.



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

Вообще-то так было лишь на заре появления джавы. Но затем к ней был добавлен jit (just-in-time) компилятор который на лету компилирует p-код в нативный и держит его в кэше для повторного исполнения, правда из-за виртуальных классов нативный код им приходится нередко перекомпилировать - это считается недостатком в конструкции джавы, но они старались (компилировать) 

Цитата: adolfus от 01.01.2017 06:23:51Какие-то глупости Вы говорите. Стандарт ISO/IEC 14882 не касается результатов компиляции, а всего лишь синтаксиса языка и того, что каждый элемент его должен делать. Собственно, как и все остальные стандарты на языки программирования. Результатом компиляции является объектный модуль. Форматов объектных модулей несколько и все они жестко стандартизованы. Но формат объектных модулей никакого отношения к стандарту ISO/IEC 14882 не имеет. Объектные модули могут быть организованы в библиотеки, которые опять же имеют разный формат. Одним словом, не несите чепуху, а просто ознакомьтесь со стандартом. В конце концов есть хорошие книги
Другое дело, что некоторые компиляторы не поддерживают некоторые элементы стандарта или поддерживают частично. Этим особенно страдают компиляторы Микрософт. Поэтому у многих из тех, кто пользуется виндовсами возникает такое же впечатление, как у Вас. При этом с++ и с являются самыми переносимыми языками.

Если все так хорошо на бумаге, то почему так хреново на практике ?
Зы. Компилировал на Линуксе.
PSS. Попробовав С++ - не хочу -нафиг нафиг сей геморрой. Преимуществ никаких, а геморра море....

Цитата: adolfus от 01.01.2017 06:45:23Ваш вопрос предполагает, что где-то кто-то должен готовить так на всякий случай нужных именно вам специалистов только для того, чтобы если они вдруг вам понадобятся, вы их тут же нашли и оприходовали. Подход в корне неверный. Предприятие или группа предприятий должны сами для себя готовить те кадры, которые им нужны, а не шаритться на помойках в поисках пусть и плохонького, но готовенького уже сейчас контингента.
В советские времена работали курсы повышения квалификации с отрывом от производства, где куча народу, пришедшая на предприятие молодыми специалистами, в течение шести -девяти месяцев получала достаточно конкретные знания и навыки.
Сегодня тоже нет никаких препятствий тому, чтобы предприятие, которому нужны сильные программисты, такие курсы организовало на постоянной основе. Не может предприятие, сможет министерство, в конце концов. Я сам в свое время, придя молодым специалистом на фабрику, на  таких курсах много чего для себя поднял такого, чего даже за десять лет работы по фирмам и на треть не получить.  Самое главное -- следовать заветам Проповедника -- прежде чем что-то собирать, нужно посеять. По-другому ничего не получится. Вузы могут только дать базовую основу. И только в том случае, если предприятия перебьют влияние аутсорсинговых фирм, которые уже несколько лет прогибают учебные программы под себя.

Проект Буран о чем-то говорит? Самая большая проблема была сделать огромный проект с минимумом ошибок (а точнее - с их отсутствием), но самая большая проблема была - кадры. Кадры решают все. Не было в СССР такого количества программистов со знанием АСМа для решения задачи в установленные временные рамки. В результате чего пришлось проектировать всю систему программирования, в результате чего появился ДРАКОН и под него язык программирования. Система показа себя очень надежной, что до сих пор используется в ракетоносителях.
А для примера, все тот же многострадальный F-35 - и программеров вроде много (наверное), и времени затратили аж целых 20 лет, но "не выходит каменный цветок" (с) Баженов.
Так что проблема в мире не решена, была решена только в СССР, но почему-то не прижилась во всем мире - может из-за капитализма? Кушать то хочется, писать НОРМАЛЬНЫЕ приложения за копеечную себестоимость не интересно, поэтому и был придуман С++ - это просто бесконечная кормушка на поколения программистов

Цитата: adolfus от 01.01.2017 06:25:21Ссылка битая

Интерфейсы транспортных систем:
www.external.pro

Цитата: Superwad от 09.01.2017 11:31:44Если все так хорошо на бумаге, то почему так хреново на практике ?
Зы. Компилировал на Линуксе.
PSS. Попробовав С++ - не хочу -нафиг нафиг сей геморрой. Преимуществ никаких, а геморра море....

На практике хреново только у Вас, а у миллионов все получается и они получают эти самые преимущества в полном объеме безо всякого геморроя. Может проблема не в языке? И бумаги Вы не те читаете? Стандарт у вас есть?

Цитата: adolfus от 09.01.2017 20:17:21На практике хреново только у Вас, а у миллионов все получается и они получают эти самые преимущества в полном объеме безо всякого геморроя. Может проблема не в языке? И бумаги Вы не те читаете? Стандарт у вас есть?

Ну, практика показывает (прогон через IDA некоторых программ), что С++ за счет разных "виртуальных функций" и прочей хрени способен не только похерить все преимущества VLIV, но и массовым ARM и x86/x64 голову свернуть на тему предсказания переходов и проч... То есть, процессор греет воздух вместо того, чтобы радовать меня ростом производительности.
С моей точки зрения, даже С++ конца 80-х годов был гораздо более логичным и предсказуемым.Про Жабы, Шарпы и подобную хрень я вообще молчу. Программист должен понимать, что будет делать железка. Я уже сталкивался со студентом, который не понимал, как работает ввод-вывод на компьютере. Он очень удивлялся, когда его-же программа, слегка поправленная, начинает работать в разы быстрее.

Цитата: Valery от 10.01.2017 01:23:44Ну, практика показывает (прогон через IDA некоторых программ), что С++ за счет разных "виртуальных функций" и прочей хрени способен не только похерить все преимущества VLIV, но и массовым ARM и x86/x64 голову свернуть на тему предсказания переходов и проч... То есть, процессор греет воздух вместо того, чтобы радовать меня ростом производительности.

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

Цитата: AndreyV1970 от 09.01.2017 01:29:16P.S. 
Мощностей по печатным платам класса 5+ в стране образовалось как то вдруг больше чем многим представляется.
В 13-14м литографии покупали больше чем Китайцы.
Дальше не знаю, Китаёзы содрали Принтпроцессовскую машину, швейцарцы рыдали....
Не всё пока гладко получается, но уже думают куда отдать серьёзный гемор - корейцам или самим сделать быстрее получится, на счет дешевле тут пока ОЙ)))))
Еще бы чипы делать научиться....
К стати. Многое из купленного ещё в 12-13 годах стоит не распакованное.
Знаю реальные примеры когда оборудование для целых цехов стоит уже несколько лет, бо нет денег на установку....

В это всё и упирается! Разработка чипа - это одно, его реализация - совсем другое. Или разработка уже какого то функционального устройства. Это можно делать тут, достаточно опытное, дорогое, но не серийное, производство иметь, а для серии заказывать в том же Китае.
По мне уже можно что то подобное :

Разрабатывать и , главное! в массы продавать, а не большими партиями производителям того/сего как тот же "Байкал".

З.Ы. Вот почему до такой нужной и полезной, спрос зашкаливает, безделицы у нас не додумаются никак? тут нет супер-мега технологий ни каких. Никакого 22 нано тех процесса и т.п. Англичане додумались - реализовали при помощи китайцев и бапки зарабатывают!

Цитата: ИвaнычЪ от 10.01.2017 10:11:20Если б Вы писали на линуксе и не просто на лине, а под определённый компилятор, а потом свой код попытались бы скомпилить в другом, то навернякак какие нибудь траблы бы выскочили. На винде то же самое. Код от одной студии на другой с траблами компилится или вовсе не компилится! Допиливать по конкретный компилятор/стандарт/мелкомягкие траблы надо, приведение типов и т.д..
Линукс, Виндовс или ещё что - тут без разницы - версия компилятора, компилятор сам важнее. Он компилирует, а не ось.

Если писать в рамках стандарта, то риск нарваться на проблемы с переносом на другую платформу минимальный. Проблемы возникают там, где специально делается все, чтобы чтобы держать разработчиков на коротком поводке непереносимости кода. В настоящее время основным источником принципиальной непереносимости является работа с файловой системой. Интерфейс, благодаря qt и wxwindows, выскочил из этого капкана. Что касается файловой системы, то проблема имеет место лишь при портировании кода из виндовс в линукс. Но можно просто забить на visual c и работатьс любым другм компилятором, благо их есть. Тем более, что visual c -- самый убогий и глючный среди всех.

Цитата: ИвaнычЪ от 10.01.2017 10:51:35В это всё и упирается! Разработка чипа - это одно, его реализация - совсем другое. Или разработка уже какого то функционального устройства. Это можно делать тут, достаточно опытное, дорогое, но не серийное, производство иметь, а для серии заказывать в том же Китае.
По мне уже можно что то подобное :

Разрабатывать и , главное! в массы продавать, а не большими партиями производителям того/сего как тот же "Байкал".

З.Ы. Вот почему до такой нужной и полезной, спрос зашкаливает, безделицы у нас не додумаются никак? тут нет супер-мега технологий ни каких. Никакого 22 нано тех процесса и т.п. Англичане додумались - реализовали при помощи китайцев и бапки зарабатывают!

Не стоит делать того чего делать не стоит.
Нужны промышленные контроллеры, компьютеры для тех же вояк чтоб совсем с голой жопой не остаться, приборы и комплексы для авиации, армии, кораблестроения, промышленности.
Машиностроение поднимать нужно.
Станки, приборы, оборудование.
В купе такая масса электроники - все наши переразмеренные мощности 24/7 работать будут и захлебнутся.....
А гаджеты, пустое это.
Там иные законы.
YotaPhone как по мне очень интересная идея, но где он?
Не наше это. Ну не сейчас как минимум.
А что касается ценника.
Ну так он достигается просто.
Я сейчас за печатку говорю.
Покупается комплект оборудования на цех потребной мощности.
Литография, мокрые процессы, механичка, контрольное.
Запускается ОДИН децимал, настройка, пристрелка неделю и дальше гонится год 24/7.
Потом оборудование в утиль, ставится новое и снова по кругу.
И будет вам счастье в виде ценника сказочного.
Но под это рынок нужен ОГО-ГО.
А это немного перпендикулярно производству.
Это маркетинг, товарные кредиты во всех звеньях и проча и проча.
То что мы только для самолётов делать можем.
А вот для самолётов или там ракет - 400 децималов в месяц, каждый со своей спецификой, на своем материалле, и со своими требованиями - тут простите вопрос цены где то на втором-третьем месте с конца. Это скока хотите, хоть 7го класса, хоть гибкожёсткую....
Правда сейчас все носятся ищут сторонние заказы. Бо после выполнения программы перевооружения обещан голодный паек.
И вот тут как раз пригодились заказы на разные там контроллеры-измерители-вычислители.
Только где оно. Приборо и станкостроение смердит тленом уже который год........