OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 13 Август, 2020 11:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 117 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 05 Апрель, 2019 21:15 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2810
Не стоит цели делать текст сейчас.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Апрель, 2019 14:16 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8351
Откуда: Троицк, Москва
И вполне разумно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Апрель, 2019 18:30 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Comdiv писал(а):
Обратите внимание, что всё это время я писал о переносимости в целом, а не о той переносимости, которая соответствует Вашему пониманию.
Вот это зубоскальство я прокомментирую.

Константин, Вы читали старые книги по информатике и ЯП, скажем, 60-80х? Я по ним учился. Они характерны своим единого фронта мнением о том, что машинно-ориентированные языки вообще (и ассемблеры в частности) в основе своей являются непереносимыми. Именно отсюда следует моё мнение, которое, заметьте, уже далеко не моё, а авторов всех этих книг. Перечислять их я не буду, здесь многие читали и понимают, о чём я говорю. Даже у виртовского пи-кода есть много недостатков, и его переносимость очень условная. Там всегда есть слой абсолютно непереносимого на другую систему кода. А уж как пи-код убивал производительность и без того слабеньких систем. Короче, годился только для не очень ёмких задач обучения. Но позже в Оберонах Вирт ушёл от идей пи-кода (а подход JVM и .NET мы можем смело считать их развитием).

Про имитацию переносимости машинно-ориентированных языков в виде слоя виртуализации или эмулятора/симулятора заговорили позже, когда железо стало мощнее. Но я не думаю, что мнение о непереносимости ассемблера как-то устарело с окончанием эпохи 80х. Просто появились доступные песочницы, имитаторы одной архитектуры на другой и прочие виртуализаторы. Но это — не о том. Ориентироваться на языки ассемблера как на переносимые языки в целом — это абсурдно. Рассказали бы своему учителю информатики в школе/ВУЗе о переносимости ассемблера, двойку отгребли бы. И ссылки, выдранные из контекста, не помогли бы. ;-)

Кстати, полное копирование свойств одной архитектуры на другой подразумевает и воспроизведение её багов тоже. А как же. Иначе полной совместимости не будет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Апрель, 2019 22:43 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1093
Откуда: Киев
Oleg N. Cher писал(а):
Константин, Вы читали старые книги по информатике и ЯП, скажем, 60-80х?
Конечно - я любитель старины. Не так давно кто-то из шутников на работе принёс в локальную библиотеку несколько старых книг. Меня больше всего заинтересовала "Программирование на языке АЛМО. Богданов В.В., Ермаков Е.А., Маклаков А.В. 1976". Я и раньше встречал упоминание АЛМО, но с этой книгой смог ознакомиться с проектом подробней. Кстати, всё время забываю спросить - нет ли какой связи одного из авторов с Ильёй Евгеньевичем?
Отчасти поэтому, я знаю, что утверждение ниже - не истина:
Цитата:
Они характерны своим единого фронта мнением о том, что машинно-ориентированные языки вообще (и ассемблеры в частности) в основе своей являются непереносимыми

Дома у меня нет под рукой книги, посвящённой АЛМО, но есть "Енциклопедія кібернетики. 1973", где о языке также есть заметка
Вложение:
ЕК-АЛМО.png
ЕК-АЛМО.png [ 102.29 КБ | Просмотров: 1319 ]

В соверменном формате об АЛМО можно почитать на сайте ИПМ им. М.В. Келдыша. В частности, в ней упоминается сравнение производительности
Цитата:
В 1974 году было проведено исследование под руководством Э.С Луховицкой по оценке эффективности трансляторов, разработанных на базе АЛМО. Был выбран ряд задач, участвоваших в производственном счете на БЭСМ-6. Исследовались трансляторы, написанные вручную (ФОРТРАН Дубна, БЭСМ-Алгол, ALGOL-транслятор), и 4 транслятора Универсальной системы программирования. Сравнивая времена счета, полученные по готовым программам различных задач, можно заключить, что в среднем эти значения для трансляторов Универсальной системы оказались не хуже, чем для трансляторов, написанных вручную


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 12:13 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9271
Откуда: Россия, Орёл
2Comdiv, я понимаю, о чём Вы, но это всё же особое поисковое направление: как приемлемо жить на уровне, близком к машине.
В Союзе было много таких экспериментов. Кронрод, кстати, в своих "Беседах о программировании", недавно переизданных, очень сильно "мочил" ЯВУ и пропагандировал развитие именно на уровне автокода.

Сегодня это представляет интерес для системщиков, техническими решениями, но вряд ли в виде идеи "А вот как прекрасен уровень автокода".

(Е. А. Ермаков, про которого Вы спрашивали, не из наших родственников, если только по какой-то очень далёкой ветке, но фамилия нередкая).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 12:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9271
Откуда: Россия, Орёл
Oleg N. Cher писал(а):
А уж как пи-код убивал производительность и без того слабеньких систем. Короче, годился только для не очень ёмких задач обучения. Но позже в Оберонах Вирт ушёл от идей пи-кода (а подход JVM и .NET мы можем смело считать их развитием).


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

И стратегически, в общем, оказался прав. Учитывая, что и в 2019-м году, со всеми безумными JIT-оптимизациями (невоспроизводимыми никем, кроме вендора, и такого объёма, что о доверенности говорить сложно), Java имеет такие проблемы:

https://ru.wikipedia.org/wiki/Java писал(а):
По данным сайта shootout.alioth.debian.org, для семи разных задач время выполнения на Java составляет в среднем в полтора-два раза больше, чем для C/C++, в некоторых случаях Java быстрее, а в отдельных случаях в 7 раз медленнее[14]. С другой стороны, для большинства из них потребление памяти Java-машиной было в 10—30 раз больше, чем программой на C/C++. Также примечательно исследование, проведённое компанией Google, согласно которому отмечается существенно более низкая производительность и бо́льшее потребление памяти в тестовых примерах на Java в сравнении с аналогичными программами на C++[15][16][17].


А закон Мура-то уже тю-тю. А объём ИКТ-задач вырос настолько, что вопросы энергопотребления ЦОДов стоят остро, как и вопросы объёма редкоземельного сырья на производство чипов и т.п.
А волна "чип в каждый веник"... Будет этот чип за 50 р или за 500 р - чтобы Java-машина влезала, как бэ, разница есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 14:00 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3191
Откуда: Астрахань
Я писал на АЛМО в Ташкенте на БЭСМ-6.
Это фактически была сделана компилируемая виртуальная машина - задолго до бума интерпретируемых ВМ на персоналках.
Хороший был язык.

Кстати, Илья, - моя бабушка тоже урожденная Ермакова... :mrgreen: :mrgreen: :mrgreen:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 15:29 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Илья Ермаков писал(а):
Java имеет такие проблемы
Мы с Сергеем Волковым на днях пытались повторить сборку мидлета для J2ME на GPCP. У жавы какая риторика? "Напиши один раз и запускай везде". По факту. Скачал я новый Java ME SDK 8.3 — он не устанавливается. Пишет, что у меня не установлена JDK. Попробовал последовательно 3 версии OpenJDK — не сработало. Попробовал официальный JDK, тоже не сработало. Похоже, из-за заброшенности платформы Java ME её SDK не адаптирован для работы на свежих версиях JDK. В документации это никак не отражено, не написано, какая максимальная версия JDK нужна. Так что мир жавы фрагментирован, а девиз "напиши один раз" — просто красивый рекламный слоган.

Да, может ещё и с битностью дело. Надо ставить какой-то определённый — например, 32-битный JDK. Но новые версии JDK только 64-битные. Надо ставить старый. Мне это надоело, и я забил. Надеюсь, Сергей не будет в обиде. :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 16:15 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 63
Откуда: Equestria
Oleg N. Cher писал(а):
J2ME на GPCP
Для этого какой-то особый SDK не нужен. Нужны только javac (для либ) и jar из JDK, набор jar'ов с api j2me и proguard для преверификации.
Ну и ещё хорошо бы взять мою версию старого gpcp с патчами для j2me. ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 16:22 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
По-хорошему, да, но желателен ещё эмулятор разработчика с отладчиком. У меня на ноуте установлено окружение для сборки мидлетов, но если с нуля рассказывать как именно собирать мидлеты на GPCP, то нехорошо говорить: "Вот, возьмите этот старый SDK, как-нибудь его распакуйте вручную, выковыряйте из него вот эти три файла. А в принципе, можете их взять по этой ссылке, но я ничего не гарантирую...". Сами понимаете.

Я не знал, что у тебя специальная патченная версия GPCP для Jme была. Кстати, последний GPCP для JVM валится на моём коде. Совсем заброшенный проект, даже грустно об этом говорить. :-(


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 17:31 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1093
Откуда: Киев
Илья Ермаков писал(а):
2Comdiv, я понимаю, о чём Вы, но это всё же особое поисковое направление: как приемлемо жить на уровне, близком к машине.
Поисковое решение - это язык Сигма, который был инициирован Ершовым, так как был неудовлетворён тем, что не смог уговорить подопечных пропихнуть в Эпсилон идеи, содержащие научную новизну. АЛМО же и тот самый Эпсилон создавались для практических целей и, как утверждается, с ними хорошо справлялись.
Цитата:
Вирт наверняка чувствовал, что работа через пром. слой срезает производительность
Всё строго наоборот - для достижения высокой производительности промежуточный слой строго необходим. Жёстко оптимизирующие компиляторы работают через ВМ в том или ином виде.
Цитата:
поэтому перешёл к идее такого простого языка, для которого и прямую кодогенерацию перетащить на другую платформу не особо сложнее, чем написать интерпретатор P-кода
Как можно судить по результатам, Вирт стремился уменьшить совокупную сложность минимально самодостаточной системы, не более.

Цитата:
По данным сайта shootout.alioth.debian.org, для семи разных задач время выполнения на Java составляет в среднем в полтора-два раза больше, чем для C/C++, в некоторых случаях Java быстрее, а в отдельных случаях в 7 раз медленнее,
Free Pascal тоже в отдельных тестах в 8 раз медленней. Надо ли говорить, где в этом benchmark оказалася бы гипотетический транслятор Вирта в код х86? Тут сравниваются конкретные реализации, а не концепции. Хотите правильное сравнение - возьмите сопоставимые языки, делаемые сопоставимыми усилиями, например, Go vs Java, и тут Вы не увидите преимущества. При том, что все для достижения высокой производительности именно обязаны иметь низкоуровневое представление, хотя и могут делать это по разному.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 17:34 

Зарегистрирован: Пятница, 22 Март, 2019 07:50
Сообщения: 61
Цитата:
Да, может ещё и с битностью дело
- Ubuntu 14 - 64 бита - вроде oracle-jmesdk-8-3 сразу установилось скриптом. JDK стоит 8 от оракла
Цитата:
просто красивый рекламный слоган
- там же не сказано "напиши везде" :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Апрель, 2019 18:05 

Зарегистрирован: Пятница, 22 Март, 2019 07:50
Сообщения: 61
То что Java "в среднем по больнице" проигрывает по скорости C/C++ и жрет больше памяти - в этом нет ничего удивительного - так как ее виртуальная машина на этих языках написана. Плюс работа сборщика мусора тоже сказывается (справедливости ради следует отметить что в особо критических использованиях есть разные хитрости - например создание массива байтов и использование этого массива для размещения в нем объектов и так сказать "ручного" управления памятью). Но надо рассматривать комплекс характеристик языка. Ну, например, при многопоточности с разделяемыми объектами java намного больше гарантий предоставляет, чем C/C++ (например causality requirements С/С++ просто не специфицируют никак, что в теории может привести к очень неожиданным результатам) . Но это может превратиться все в холивар дальше и поэтому не сильно интересно. Важна так сказать взвешенная сумма преимуществ языка, причем в каждой сфере применения свои веса важности каждого свойства.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 07:10 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 63
Откуда: Equestria
Oleg N. Cher писал(а):
ещё эмулятор разработчика с отладчиком
Microemulator, pstros. Для винды kemulator. Насчёт отладчика не знаю, ниразу в жизни не пользовался.
Oleg N. Cher писал(а):
нехорошо говорить: "Вот, возьмите этот старый SDK, как-нибудь его распакуйте вручную, выковыряйте из него вот эти три файла. А в принципе, можете их взять по этой ссылке, но я ничего не гарантирую...".
Не надо ничего ковырять, все необходимые jars можно достать где-то на сайте jcp.org.
Если есть желание, то можно и сделать сборочку специально для разработки под j2me, где всё уже в комплекте со скриптами и требуется только jre+jdk любой версии... только кому это надо?
Oleg N. Cher писал(а):
Я не знал, что у тебя специальная патченная версия GPCP для Jme была. Кстати, последний GPCP для JVM валится на моём коде. Совсем заброшенный проект, даже грустно об этом говорить. :-(
Там совсем минимальные изменения, конечно. Ну а новый gpcp полностью сломан, у меня самый примитивный код уже не работал, о чём я и сообщал в багтрекер. Что-то большее даже не тестировал.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 10:30 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 935
Откуда: Казань
Это уже не первое сообщение на форуме, когда кто-то где-то сделал интеграцию с каким-то open source решением, а через какое-то время интеграция сломалась, так как вышла новая версия системы, которая не совместима со старой, а старую поставить тоже проблематично, так как она уже не совместима с новой версией операционной системы и т.д.
Поэтому, мне кажется, что все эти интеграции с байткодом Java, LLVM и прочее - это просто потеря времени. Нужно иметь своё независимое решение. Например, вместо итеграции с байткодом Java, реализовать свою виртуальную машину интерпретирующую байткод. При этом не надо будет ни от кого зависеть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 11:18 

Зарегистрирован: Пятница, 22 Март, 2019 07:50
Сообщения: 61
Цитата:
Поэтому, мне кажется, что все эти интеграции с байткодом Java, LLVM и прочее - это просто потеря времени. Нужно иметь своё независимое решение. Например, вместо итеграции с байткодом Java, реализовать свою виртуальную машину интерпретирующую байткод. При этом не надо будет ни от кого зависеть.
Так это никак не спасет от смены API. Если Вашей подсистеме нужна другая подсистема - но которая в новой версии (на новой ОС) работает только с новым API, а старый уже не поддерживает? Это мы приходим к идее о "серых ящиках", которая прозвучала в одном из докладов по блекбоксу - Вам придется интегрировать библиотеку, от которой зависите в проект. Или стандартизировать API, вынуждая разработчика поддерживать старый интерфейс. Или еще какие-то решения есть? (Построил ради любопытства дерево зависимостей по текущему своему рабочему проекту - несколько экранов используемых библиотек которые в свою очередь имеют зависимости - обычный уровень зависимостей - 3-5, есть и 6-й уровень зависимостей. )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 11:58 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1387
Откуда: Украина, Киев
Rifat писал(а):
Поэтому, мне кажется, что все эти интеграции с байткодом Java, LLVM и прочее - это просто потеря времени.
В компиляторе Fox, так для справки, по состоянию на сегодня, уже готовая инфраструктура компиляции через промежуточное представление. Есть два бэкенда ARM и AMD64 (есть ещё TRM, но это под FPGA проект Oberon On Chip). Каждый бэкенд - это 3 модуля: FoxXXXInstructionSet.Mod, FoxXXXAssembler.Mod, FoxXXXBackend.Mod. Во фронтэнде помимо Активного Оберона есть и Оберон-07
Оптимизация производится именно над промежуточным представлением. Базовый уровень оптимизаций где-то встречал описанным. Более продвинутые оптимизации, возможно тоже где-то описаны.
Может проще сделать эту злополучную оптимизацию чем городить огороды с байткодом Java и LLVM...!?
И дописывать недостающие фронтэнды и бэкенды. Но каждый же стремится изобресть свой велосипед, самый велосипедистый в мире.


Последний раз редактировалось Ярослав Романченко Понедельник, 08 Апрель, 2019 12:12, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 12:11 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1387
Откуда: Украина, Киев
Oleg N. Cher писал(а):
А уж как пи-код убивал производительность и без того слабеньких систем.
Всякие промежуточные представления позволяют упростить компилятор и избежать "взрыва сложности". Что-бы не приходилось делать кодогенерацию из каждого диалекта ЯП на каждую платформу и разрядность отдельно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 12:27 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1387
Откуда: Украина, Киев
Вон, народ курсачи пишет по "Оптимизации методом свертки" :lol:
https://life-prog.ru/view_psp.php?id=14
Можно реализовать, оттестировать не ломается-ли код, есть-ли выигрыш по производительности. И т.д. И двигаться дальше. А то тут уже столько текста исписано на форуме... Если-бы столько же было написано кода :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Апрель, 2019 12:33 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4442
Откуда: Россия, Орёл
Ярослав Романченко писал(а):
В компиляторе Fox, так для справки, по состоянию на сегодня, уже готовая инфраструктура компиляции через промежуточное представление.

Документацию бы на это всё увидеть и новое сообщение о языке АО. А то понятно, что изменеий много, но каких именно непонятно.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 117 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB