Центр информации по операционным системам: Форумы / ОС-21 / Заглядывая в туманное будущее

Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21		<< Предыдущая тема \| Следующая тема >>
Заглядывая в туманное будущее - обсуждение

Переход на страницу 1 [2] 3 ... 13 14 15
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

brasset

Суббота 23.07.2005 00:40

ID пользователя #198

Зарегистрирован: Среда 02.02.2005 13:17
Местонахождение: Моск. обл. г.Дмитров
Сообщений: 45

Блин! Не могу не сказать этого слова!

Ребята, как вы легко спрыгивате на частности. Мне этот тред напоминает разговор двух склочниц (хотя вас намного больше), каждая цепляется за одну-две фразы, в сообщении другого, и понеслась... Это уже спор на интерес (вспомните 3 фразы Жванецкого: "Мы будем спорить о вкусе устриц с теми кто их ел..."; "Что может сказать хромой об исскустве Генриха фон Караяна, если ему сразу сказали, что он хоромой?..."; "В самый неожиданный момент спора попросите гражданина предъявить паспорт..."

). Это уже ТРЕД НА ИНТЕРЕС!
Не знаю, все откликнувшиеся на статью Warender'а, как-то мало задумались о смысле и предпосылке статьи, а вот по частностям пройтись почему-то не забыли.

А уж если о частностях, то сейчас я пройдусь ими же (И пусть никто не уйдет не обиженным

)

Весьма оптимистично. Среди моих знакомых стационарный телефон имеют менее 20%, из них компьютер менее половины. Итого потенциально менее 10% диалапщиков.

Мой же город 7 лет назад. В чем мы варимся сейчас расписывать не буду, но почему-то до сих пор завидуем Москве (у них "stream"). Хотя не понимаю - имеем то, о чем не могли и мечтать. Прогресс он не стоит на месте.

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

"До перестройки", активно продвигались наши отечественные языки программирования, которые на 99% повторяли basic и pascal, но вот вся нотация была на русском. Это были "родные" ("нативные"

) языки программирования всех отечественных МикроЭВМ (про более мощьные машины не знаю). Примеров приводить не буду т.к. не могу уже вспомнить на память, а книги остались на другой квартире.
Так что это не шутка. Просто правила задает тот, кто первый придумал, и продвинул продукт. Именно поэтому "компьютер", а не "ECM (англ.)". С точки зрения лексического разбора или компилятора(интерпретатора) "те же яица только в профиль" - так что почему бы и нет.

Человеческий язык не содержит строгости, однозначности и последовательности. Люди не могут понять даже друг друга.

Именно так! Причем, в IT (и на этом сайте) люди зачастую не могут понять друг друга, просто потому что используют разные определения для одних и тех же сущьностей. И при чем не используют общепринятые (стандартизированные) понятия. Вот такая селява

Наверх

batu

Воскресенье 24.07.2005 13:05

ID пользователя #5

Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22

Извиняюсь за то, что ответ Captain cobalt так поздно и не в той ветке, но в тему.
Captain cobalt писал (а)
Проверка типов может быть практически полностью выполнена во время компиляции и компоновки, и не потреблять ресурсов во время исполнения.
Все оно именно так, только во-первых это немного усложняет транслятор, а во-вторых все таки не решает проблему проверки типов объектов, которые появляются динамически, во время выполнения.. На это тоже уходят ресурсы. Но главное не в этом. А в том что это не системный подход. Во первых одна проверка в трансляторе (причем в каждом написаном трансляторе), а во вторых надо генерировать код в выполняемой части программы для проверки типов. А это те же ресурсы процессора, только каждый раз дублированные программным кодом.
Captain cobalt писал (а)
Ссылочный тип данных. Проверка на наличие значения - проверка ссылки на NIL. Можно использовать механизмы аппаратной защиты памяти, чтобы перехватывать обращение по нулевому адресу. Использовать сборку мусора, чтобы избежать утечек памяти и висящих указателей. Для тяжёлых случаев - untraced poiner.
Что в результате получается?
Вах, да это же Вluebottle.
Такая же ситуация и с формированием адресов. Мало того что для этого приходится еще один проход делать, но и мороки там хватает. Не симпатичный транслятор получается. Да и ни о каком универсализме (а отсюда и надежности) речи не может идти. Да и что сформируешь, если объекта еще нет, Т.е. это явно задача процессора. Но жалко ресурсов. Понимаю. Я тоже жадина! И поэтому предлагаю режим 0-выполнения. Когда процессор считывает команды, формирует адрес, проверяет типы а операции не выполняет!
И тогда после проверки лексики, синтаксиса и семантики запускаем 0-выполнение сгенерированого кода. Вопрос закрыт. То, что можно проверить в типах, и там, где можно построить адреса они будут построены. А остальное по любому делается на этапе выполнения, но без дополнительных команд и проверок в программе. По моему должно быть очевидно, что такой подход резко сократит код, и увеличит скорость выполнения программы (а не команды). Такой метод я назвал метод «отложенной трансляции».
Я не хочу останавливаться на ссылочных типах данных и проверкой на наличие данных.. Проблема эта есть и реально. Почитайте как справляется с этим (частично) в проекте E2K http://www.elbrus.ru/mcst/pub.shtml . И сбор мусора и выделение памяти дело диспетчера памяти (тоже аппаратное. И не кляните меня за такую нагрузку для машины. Во первых это можно выполнять параллельно, во вторых это логично)
Captain cobalt писал (а)
А как работают сейчас системы на мультипроцессорах?
Хреново работают. Нет оптимальных алгоритмов ни на последовательность команд и соотвественно данных, ни на количество процессоров. Вплоть до того что приходится перетранслировать программу для другого числа процессоров. Так что процессорами надо управлять для получения эффективной загрузки. Одна и таже последовательность команд для разного числа процессоров имеет разную эффективную последовательность выполнения.
Captain cobalt писал (а)
В настоящее время имеются: загрузка данных в кэш (prefetch), выгрузка строки кэша (write-back & invalidate), сохранение напрямую в память минуя кэш (non-temporal store).
Что ещё нужно?
А нужно более гибкие алгоритмы работы. Сейчас кэш работает по последнему обращению. Не было к данным обращений- выбросить. А недавние пусть хранятся. Согласись это не идеальный алгоритм. Идеальный должен быть гибким. А значит кэш память нужно программировать. Даже если с данными (они же и команды) грузится номер алгоритма из стандартного набора это ведь тоже программирование. И вобще все управление памятью и распределение данных между процессорами дожно быть управляемым. Т.е. на лицо необходим диспетчер процессоров и диспетчер памяти (распределение памяти, сбор мусора и управление кэш-памятью задача его задача). Объективно. Можно и ничего не делать. Но ведь прийдеться. В будущем.
Captain cobalt писал (а)
В старой ОС Unix все файлы одного формата - "неструктурированный поток байт".
Я предлагаю вообще иметь только структурированые данные. Просто разряды и байты должны исчезнуть. Т.е. конечно быть, но не байтами, а данными. С типами, свойствами и прочей лабудой. Команды и ссылки это тоже данные. Вот такой формат я сконструировал. Это вроде XML. Только XML работает с данными, а мне удалось создать язык SXML. Им можно описать не только данные, но и команды,и ссылки, и лексику, синтаксис. Т.е. все! И он попроще XML оказался. И помощнее. Им можно описать самого себя. Что у меня и происходит. Транслятор SXML написан на SXML.
Этот формат прекрасно транслируется в двоичный код и все проблемы с форматами файлов. А теперь концепция тегового управления.
Captain cobalt писал (а)
Что такое "приложения"?
Что такое "управляться"?
Что такое "одинаково"?
Хороший вопрос! Давайте подумаем, а чем текстовые и остальные редакторы отличаются от трансляторов? Что там на входе и что на выходе? Как сделать что б некий формат был и средством, и редактором и результатом работы и еще и выполнялся (т.е. быть программой? И тут приходят на помощь тэги. Рассматривая каждый тег как элемент класса (и класс можно определять в языке SXML), а внутри тега свойства которые имеют значения очень легко представить любое приложение (программу, текст или редактируемый документ или изображение) в виде последовательности тегов(эементов класса). Классы тегов определенные в данном приложении являются инструментами данного приложения, а изменяя свойства «активного» тега можно управлять любым приложением от редактора-транслятора до медиоредакторов. Оттранслированные теги и представляют единственный формат в такой системе. Управление приложениями тоже универсально-единообразно. Т.е для создания любого приложения надо определить классы тегов (они же инструменты данного приложения) со свойствами, а изменяя свойства инстументов изменять приложение (по сути редактировать его). Вот и весь универсализм.
Дальнейшее развитие не в объектно-ориентированом, в аспектно-ориентированом языке.
Да. Дело в том что разница почти неуловима. Объектно-ориентированная парадигма сослужила свою службу и стала очередной ступенькой к дальнейшему совершенствованию программирования и стала для меня фундаментом новых идей. Я помню 80-е годы японцы проектировали машину управляемую потоками данных. У них ничего не получилось, но на современном уровне их идею можно реализовать. Причем просто как составляющую общей концепции. Основой этой концепции служит более развитый механизм определения отработки событий. Обычно (в .Net и аналогичных языках) событие определяется либо в классе, либо как отдельно висячее. В языке LADA (моя разработка) событие можно определить для любой переменной (или класса). Событие (понятно что с именем, и понятно что их может быть много) определяется как список логических выражений или булевских функций. Если одно из списка имеет истинное значение, то для переменной возникает событие. Подключение события к его обработке происходит в принципе как обычно, определением процедуры обработки события. Единственным дополнением имеется механизм отключения-подключения обработки события и перехват отработки события другой процедурой.
Это вроде бы незначительное дополнение значительно облегчает жизнь программисту (и так же значительно нагружает процессор, так как проверять необходимо каждую переменную на наличие событий). К примеру, надо что-то проанализировать последовательное увеличивая счетчик. и каждый раз проверять на «конец». Так теперь надо определить событие «конец», там отработать его и забыть эти проверки в алгоритме при увеличении счетчика.
Машину можно запрограммировать как управляемую потоками данных. Давняя мечта японцев. Не нарушая логику человеческого мышления.
Здесь тормозит архитектура машин. Нужна более прогресивная система адресации данных
Captain cobalt писал (а)
Также нужно изучать учебники по структурам данных.
Не могу не согласится. Нужно изучать учебники. Но и нужно анализировать о чем там идет речь. В первую очередь принимая стандарты по структурам данным (а на мой взгляд это совершенно необходимо), мы решаем одну из главнейших задач адресацию данных. И я это предлагаю делать аппаратно, то другого выхода просто нет. Как происходит сейчас адресация, например элемента в статическом массиве. Вообщем целая последовательность команд..Анализ размерности, нижняя граница, проверка индекса, проверка верхней греницы, проверка размера элемента элемента массива, перемножение для вычисления адреса. И это если в статических массивах.. А в динамических проверка размера выделенной памяти.. и т.д.. А теперь если мы все это опустим вниз на машину..необходимость в этих командах исчезнет.. Да... эти проверки нужны.. Но их не будет в кодах команд.. Прошу прощения за то, что я не развернуто пишу о новой системе адресации. Любители все делать ручками и на ассемблере меня побъют и за такие крамольные мысли. Но дело принципа. Это просто отдельная и большая тема. Ведь это логично. Да, каждая команда будет выполнятся медленней, но общая задача только выиграет.
и аппаратная поддержка событий
Аппаратные прерывания.
Любая форма асинхронных событий требует разрыва конвеера.
Конвеерное исполнение кода - основа высокой производительности процессоров.
Каким образом события повысят производительность?
Конвеерное исполнение кода, только один из методов увеличения производительности процессора. Хороший метод. И пусть работает. Но почему процессор один? И почему бы не сделать сервер обработки событий на отдельном процессоре? Ведь налицо распараллеливание процессов. Опять же это только предложение. Можно и не на отдельном, можно и на одном. Но явно в помощь. Здесь есть еще повод задуматся, так как работа с устройствами тоже может быть стандартизирована. Ведь результатом работы драйвера может стать уже готовый тег и может не стоит отвлекать процессор на чтение байтов и подробности работы с устройством. Вообщем лозунг такой- все детали опустить вниз. Программист должен заниматься программированием..

Наверх

captain cobalt

Понедельник 25.07.2005 01:03

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

batu написал(а) ...
Извиняюсь за то, что ответ Captain cobalt так поздно и не в той ветке, но в тему.

Да, времени мало...

Впрочем, куда сильно торопиться.

batu написал(а) ...

captain cobalt написал(а) ...
Проверка типов может быть практически полностью выполнена во время компиляции и компоновки, и не потреблять ресурсов во время исполнения.

Все оно именно так, только во-первых это немного усложняет транслятор

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

batu написал(а) ...
а во-вторых все таки не решает проблему проверки типов объектов, которые появляются динамически, во время выполнения..

Кто появляется динамически?
Объекты?
Или типы?
Если объекты - то они создаются процедурой NEW и манипулируются через указатели - проблема сводится к типизации указателей.
Если типы - то они объявляются в программных модулях и могут быть проверены во время динамической компоновки в соответствии с декларациями импорта и экспорта. Именно поэтому я говорю, что типы могут быть проверены во время компиляции и компоновки.

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

Таким образом, никакого дублирования кода - один типизированный компоновщик на всю систему. Соответственно не нужно генерировать никакого "скрытого" кода для проверки типов - всё проверит компоновщик перед использованием кода.

batu написал(а) ...

captain cobalt написал(а) ...
Ссылочный тип данных. Проверка на наличие значения - проверка ссылки на NIL. Можно использовать механизмы аппаратной защиты памяти, чтобы перехватывать обращение по нулевому адресу. Использовать сборку мусора, чтобы избежать утечек памяти и висящих указателей. Для тяжёлых случаев - untraced poiner.
Что в результате получается?
Вах, да это же Вluebottle.

Такая же ситуация и с формированием адресов.

Каким формированием адресов?

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

batu написал(а) ...
Да и что сформируешь, если объекта еще нет

Типизированные указатели.
Одна стандартная процедура NEW для динамического выделения памяти на всю систему.
Предполагается что эта процедура отлажена и корректна - "формирует" только "правильные указатели".

batu написал(а) ...
Т.е. это явно задача процессора. Но жалко ресурсов. Понимаю. Я тоже жадина! И поэтому предлагаю режим 0-выполнения. Когда процессор считывает команды, формирует адрес, проверяет типы а операции не выполняет!
И тогда после проверки лексики, синтаксиса и семантики запускаем 0-выполнение сгенерированого кода. Вопрос закрыт. То, что можно проверить в типах, и там, где можно построить адреса они будут построены. А остальное по любому делается на этапе выполнения, но без дополнительных команд и проверок в программе. По моему должно быть очевидно, что такой подход резко сократит код, и увеличит скорость выполнения программы (а не команды).

Выводы полностью поддерживаю!
Так сделано в Bluebottle.
Именно увеличивается общая скорость программы, а не отдельных команд.
Всё что может быть вычислено во время компиляции - должно быть вычислено во время компиляции.

Но в остальных немногих случаях действительно вставляются команды дополнительных проверок. Таким образом, задача решается компилятором в полном объёме. Не нужно никакого "0-выполнения". Не нужно никаких специальных процессоров - всё полностью переносимо практически на любые фон-Неймановские машины.

batu написал(а) ...
Такой метод я назвал метод «отложенной трансляции».

А соответствуюшая теория есть?

batu написал(а) ...
Я не хочу останавливаться на ссылочных типах данных и проверкой на наличие данных.. Проблема эта есть и реально.

Не понимаю, в чём проблема.
Если есть живые ссылки на данные - есть данные.
Если нет - происходит сборка мусора.
Откуда возьмётся "наличие отсутствия данных"?

batu написал(а) ...
Почитайте как справляется с этим (частично) в проекте E2K

Архитектура Эльбруса мне известна.
Была когда-то...
Насколько я помню, там отдельные регистры для адресов, а адресные переменные в памяти помечаются тэгом. Таким образом, адреса и обычные данные не перемешиваются. Защищаются аппаратно.

Или там что-то ещё?

batu написал(а) ...
И сбор мусора и выделение памяти дело диспетчера памяти (тоже аппаратное. И не кляните меня за такую нагрузку для машины. Во первых это можно выполнять параллельно, во вторых это логично)

Абсолютно протестую!
Абсолютно нелогично!
Это должно быть программно.
Нет никакого смысла усложнять (и удорожать!) процессор.
Чем проще процессор, чем он может быть сделан быстрее.

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

batu написал(а) ...

captain cobalt написал(а) ...
А как работают сейчас системы на мультипроцессорах?

Хреново работают. Нет оптимальных алгоритмов ни на последовательность команд и соотвественно данных, ни на количество процессоров. Вплоть до того что приходится перетранслировать программу для другого числа процессоров.

Ну перетранслировать.
Что страшного?

Вероятно, проблема в том, что количество процессоров задано в программе константой.

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

batu написал(а) ...
Так что процессорами надо управлять для получения эффективной загрузки. Одна и таже последовательность команд для разного числа процессоров имеет разную эффективную последовательность выполнения.

Так и не вижу никакого опровержения.
Имеющиеся аппаратные системы предоставляют вполне приличные средства для управления мультипроцессорами. Нужно лишь правильно их использовать - написать софт.

Кроме того, что конструктивное предлагается взамен?
Вот, например, Bluebottle предлагает активные объекты - легковесные параллельные сущности. Их можно создавать сотнями и тысячами. За счёт их большого числа их наверняка хватит на все процессоры. А за счёт легковесности может быть достигнута отличная балансировка нагрузки.

batu написал(а) ...

captain cobalt написал(а) ...
В настоящее время имеются: загрузка данных в кэш (prefetch), выгрузка строки кэша (write-back & invalidate), сохранение напрямую в память минуя кэш (non-temporal store).
Что ещё нужно?

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

Обыкновенно данные обладают "пространственной локальностью". Лоальность (как и очень многое) в целом подчиняется распределению Парето (пресловутое 80/20). Поэтому алгоритм вполне адекватный. Лишь в очень небольшом количестве случаев необходимо нечто большее. Для этого предназначены упомянутые машинные команды (а раньше и без них обходились). Таким образом, необходимость поголовного перехода на другие процессоры здесь также необоснована.

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

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

А кто это будет делать?
Прикладные программисты вручную на ассемблере?
Вряд ли. Они и сейчас с трудом "заставляют работать" свои "большие программные системы".

Значит это должен делать автоматически компилятор.
Увы, сегодняшние достижения в этой области весьма скромны. Управление кэшированием - это частный случай управления иерархией памяти. В том числе каналом RAM-HDD. Когда здесь будут достигнуты адекватные результаты, возможно будет построить пресловутую RAM OS (или CacheOS?), которая просто порвёт современные системы с виртуальной памятью и подкачкой. И программистам больше не нужно будет вручную управлять дисками - всё будет оптимально распределять система. Но пока этого не произошло.

batu написал(а) ...

captain cobalt написал(а) ...
В старой ОС Unix все файлы одного формата - "неструктурированный поток байт".

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

Это невозможно.
Необходим interoperability с существующими системами.
Поэтому соответствующий слой представления должен присутствовать.

batu написал(а) ...
...
Команды и ссылки это тоже данные. Вот такой формат я сконструировал. Это вроде XML.
...
Давайте подумаем, а чем текстовые и остальные редакторы отличаются от трансляторов?
...
Вот и весь универсализм.

Замечательно.
А теперь посмотреть на концепцию модулей, документной ориентированности и способа выполнения команд в системе Oberon, которой под 20 лет.

batu написал(а) ...
Дальнейшее развитие не в объектно-ориентированом, в аспектно-ориентированом языке.

Это напоминает рекламные лозунги.
Снова возникает вопрос, как называется язык?
И поподробнее обоснования.

batu написал(а) ...
Я помню 80-е годы японцы проектировали машину управляемую потоками данных. У них ничего не получилось

Насколько я помню, в 80-х dataflow машину разрабатывали в MIT. И даже, похоже, кое что получилось.

А японцы вроде разрабатывали Пролог-машину?

batu написал(а) ...
Основой этой концепции служит более развитый механизм определения отработки событий. Обычно (в .Net и аналогичных языках) событие определяется либо в классе, либо как отдельно висячее. В языке LADA (моя разработка) событие можно определить для любой переменной (или класса). Событие (понятно что с именем, и понятно что их может быть много) определяется как список логических выражений или булевских функций. Если одно из списка имеет истинное значение, то для переменной возникает событие.

Здесь отмечу два существенных пункта.

Первое. Зачем такие навороты. Почему бы тому, кто устанавливает событие, не вызывать напрямую обработчик. Одна машинная команда call - и готово. И не нужно проверять условные переменные на наличие событий. И замечательно вписывается в конвеер. Так работает Bluebottle.

Второе. Посмотреть пристально на Active Oberon (язык программирования). Там есть оператор AWAIT. Но не как основное средство программирования, а как способ синхронизации. В качестве операнда ему передаётся булевское выражение произвольной сложности (а не просто условная переменная). Оператор предназначен для ожидания условия. Если условие ложно - процесс блокируется. На одном объекте на AWAIT может заблокироваться более одного процесса. А далее точно также - как только какое нибудь условие становится истинным, соответствующий процесс разблокируется.

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

batu написал(а) ...
К примеру, надо что-то проанализировать последовательное увеличивая счетчик. и каждый раз проверять на «конец». Так теперь надо определить событие «конец», там отработать его и забыть эти проверки в алгоритме при увеличении счетчика.

Это притягивание за уши.

На самом деле надо "правильно программировать".

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

batu написал(а) ...
Здесь тормозит архитектура машин. Нужна более прогресивная система адресации данных

captain cobalt написал(а) ...
Также нужно изучать учебники по структурам данных.

Не могу не согласится. Нужно изучать учебники. Но и нужно анализировать о чем там идет речь.

Вообще, я не против не-фон-Нейманов.
Но на мой взгляд единственная альтернатива, достаточно радикальная, чтобы быть обоснованной, и в то же время весьма приятная для программирования, это РЕФАЛ-машина. Как насчёт? Вот попсовая статейка.

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

batu написал(а) ...
В первую очередь принимая стандарты по структурам данным (а на мой взгляд это совершенно необходимо)

Это также представляется малореальным. Структур данных существует многие сотни. Разве что для "языков программирования четвёртого поколения", в которых компилятор принимает решение об оптимальном представлении данных.
Какие языки можно назвать?

batu написал(а) ...
Как происходит сейчас адресация, например элемента в статическом массиве. Вообщем целая последовательность команд..Анализ размерности, нижняя граница, проверка индекса, проверка верхней греницы, проверка размера элемента элемента массива, перемножение для вычисления адреса. И это если в статических массивах.. А в динамических проверка размера выделенной памяти.. и т.д.. А теперь если мы все это опустим вниз на машину..необходимость в этих командах исчезнет.. Да... эти проверки нужны.. Но их не будет в кодах команд.. Прошу прощения за то, что я не развернуто пишу о новой системе адресации. Любители все делать ручками и на ассемблере меня побъют и за такие крамольные мысли. Но дело принципа. Это просто отдельная и большая тема. Ведь это логично. Да, каждая команда будет выполнятся медленней, но общая задача только выиграет.

Замечательно.
Эти проверки в большинстве случаев могут быть выполнены во время компиляции. А оставшаяся небольшая часть - дополнительными командами во время исполнения.

Таким образом, каждая команда НЕ будет выполнятся медленней! Общая задача наверняка выиграет ещё больше. Всё может работать на существующем парке процессоров, не нужно никуда переходить, Bluebottle опять всех порулила.

batu написал(а) ...
Конвеерное исполнение кода, только один из методов увеличения производительности процессора. Хороший метод. И пусть работает. Но почему процессор один? И почему бы не сделать сервер обработки событий на отдельном процессоре? Ведь налицо распараллеливание процессов.

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

batu написал(а) ...
Вообщем лозунг такой- все детали опустить вниз.

Мой лозунг - все детали поместить в программное обеспечение нижнего уровня (компилятор и среду исполнения).

batu написал(а) ...
Программист должен заниматься программированием..

Да и программирование неплохо бы автоматизировать.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Rygoravich

Понедельник 25.07.2005 14:03

ID пользователя #10

Зарегистрирован: Воскресенье 04.07.2004 16:29
Местонахождение: Navapolatsk, Belarus
Сообщений: 30

Wanderer написал(а) ...

Rygoravich написал(а) ...

Я привел это как простой пример того, что живые языки далеко не в последнюю очередь предназначены именно для программирования.

Программирования кого? Родных детей?

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

Wanderer написал(а) ...

А смысл?

Я не понимаю смысл этой программы. Компьютер - это машина. Программа - это программа. В ее основу положен алгоритм. Алгоритм - это математический термин. Естественный язык отделяют от языка математики. Так почему мы должны смешивать естетсвенный язык и язык программирования, который происходит от языка математики, а не от естественного языка?

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

Wanderer написал(а) ...

Rygoravich написал(а) ...

Ну во многом он таковой и являлся, но ведь в каждой шутке есть доля шутки... Я писал, что я не программист и если не считать bash- и php-скриптов не писал уже ничего года три как минимум. Но хоть и получилась дикая смесь языков (что, кстати, хорошо - наехал на всех сразу

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

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

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

Wanderer написал(а) ...

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

...

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

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

Наверх

Dron

Понедельник 25.07.2005 14:25

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Лично я не вижу ничего плохого в специализированном языке для программирования машин.

нафиг он нужен - естественный то?

хотя взять тот же логлан - на нем люди говорят...
но тем не менее это специализированный язык.

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

Андрей Валяев

Наверх

Rygoravich

Понедельник 25.07.2005 16:51

ID пользователя #10

Зарегистрирован: Воскресенье 04.07.2004 16:29
Местонахождение: Navapolatsk, Belarus
Сообщений: 30

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

Наверх

Dron

Понедельник 25.07.2005 17:36

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Погоди... давай не будем отождествлять программирования и общение с компьютером...

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

И это количество будет расти в той же мере в какой и компьютеры будут становиться дружелюбнее.

Остается маленькая (мышиная доля Ж)) людей, которым по долгу службы это нужно...

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

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

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

короче клавке не место на компах пользователей...

все будет осуществляться через голос... мощности компов будут неизбежно расти и качество распознавания не заставит себя ждать.

То же самое с текстами - их проще надиктовывать нежели набивать.

А программирование... если уж фантазировать, то мне кажется что там вообще языку не место особо... объекты... сущности.. да как хотите называйте... и сидишь перед 3D монитором... организуешь взаимодействие сущностей...

манипуляторы останутся по любому.

ЗЫ: добавлю немного... вообще программирование это нелинейный процесс... см выше... это не стих, который прочитал и успокоился... это стих, который придется перечитывать сто раз до тех пор, пока ты не научишься читать его правильно... или постоянно прыгать с места на место... это слово не так... здесь вообще хотел не то сказать... какой смысл в естественном языке? я против!
[ Редактирование понедельник 25.07.2005 17:41 ]

Андрей Валяев

Наверх

Wanderer

Понедельник 25.07.2005 19:37

ID пользователя #2

Зарегистрирован: Вторник 29.06.2004 20:13
Местонахождение: Беларусь, Гомель
Сообщений: 76

Rygoravich написал(а) ...

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

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

Rygoravich написал(а) ...

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

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

Rygoravich написал(а) ...

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

Еще одно подтверждение мои словам.

Rygoravich написал(а) ...

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

Что и требовалось доказать.
[ Редактирование понедельник 25.07.2005 19:40 ]

Доказывая идиоту, что он идиот, ты сам становишься идиотом.

Наверх

batu

Понедельник 25.07.2005 23:35

ID пользователя #5

Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22

Captain cobalt, я разделяю вашу любовь к Вluebottle, хотя не знаю что это такое, но это не повод не слышать друг друга. Еще раз повторяю, что в объектно-ориентированых языках частенько типы объектов до выполнения не известны. И такие вот процедуры вполне допустимы.

Пример 1. Поцедура работающая с неизвестным объектом

Sub NN (OD As Object)
Select Case OD.GetType.Name
Case “Integer”
OD+=1
…..
Case “Int32”
OD+=1
…..
Case “String”
OD&=”1”
……
End Select
End Sub

Ну, нет у транслятора на момент трансляции информации по объекту. Ни типа не можем построить, ни сформировать команду любимой IBM Add (или все возможные варианты сложения, так как целые (а может и не целые) разной длины могут складыватся разными командами, а уж если там конкатенация, то и подавно.), ни тем более адресную часть операнда, потому что адресную часть операнда неизвестно как формировать. Еще раз повторить? И никакой компоновщик тут не поможет. Выход один и в выполняемой части программного кода включаетя анализ будущих типов, и все возможные варианты команд.
О ссылочных данных и проверке на наличие объектов и «висячих» ссылок. Читайте пожалуйста ссылки, на которые я отсылаю. Хотя работ по этой теме предостаточно. Проблема есть и не простая. Процедура New тут не поможет. Она тоже может выделить память при трансляции, а может и во время выполнения. Элементарный пример с применением процедуры NN (см. Пример1)

Пример 2. Создание динамических объектов в процессе выполнения.
For I=0 To Count-1
Dim DD As New String
DD=I ‘ Кстати, на разных языках этот оператор может быть опознан как ошибка
NN(DD)
Next I

Могу привести пример «правильной» (которую транслятор не распознает) программы в которой ссылка идет на отсутствующий объект, но не хочу засорять. Опять же к друзьм или к литературе. Уже столько исписано, что неприлично повторять
Все это настолько элементарно, что добавить нечего. Еще раз спасибо за ссылку на Пролог. Не знаком. Если найду описание то познакомлюсь подробнее. Если пришлете ссылку буду благодарен. Не сочтите за труд просмотреть ссылку http://www.elbrus.ru/mcst/pub.shtml. Ваша информация об Эльбрусе попахивает нафталином. Мои работы я отсылал в виде статей Роману год назад в виде статей. Это язык SXML и язык LADA. Могу повторить. С тех пор они значительно прибавили. Но основная концепция должна прослеживаться. Отправить новые разработки трудно, потому как они принимают коммерческий характер. А разговор поддержать могу. Или ответить на вопросы.

P.S. Дальше диалог имеет смысл после прочтения работ Бабаяна, и там есть начальник отдела программистов запамятовал фамилию. То ли Воронцов.. что-то такое. сори. хотел найти ссылки не нашел. Там есть и про адресацию и про защиту данных, и про многопроцессорную работу. Найдешь. Если захочешь.

Наверх

captain cobalt

Вторник 26.07.2005 12:35

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

batu написал(а) ...
Captain cobalt, я разделяю вашу любовь к Вluebottle, хотя не знаю что это такое

А я довольно неплохо знаю, что такое Эльбрус.

И рекомендую узнать что такое Bluebottle.

Bluebottle - это операционная система. Софт. Возможности которого перекрывают возможности аппаратуры Эльбруса. И реализованы на существующем парке ЭВМ. Это существенное преимущество.

batu написал(а) ...
но это не повод не слышать друг друга

Угу.

batu написал(а) ...
Еще раз повторяю, что в объектно-ориентированых языках частенько типы объектов до выполнения не известны.

Это называется "полиморфизм".

Существует два основных способа реализации полиморфизма:
-- расширение объектных типов - наследование классов (одиночное)
-- реализация определений (интерфейсов).
В языке C++ есть нечто промежуточное - "множественное наследование", которое может требовать dynamic_cast во время исполнения.

batu написал(а) ...
Пример 1. Поцедура работающая с неизвестным объектом

Сразу вопрос: почему "процедура работающая с неизвестным объектом"? Почему не связанная с типом процедура (метод класса), которая для каждого конкретного типа точно знает какую операцию выполнять?

batu написал(а) ...
Sub NN (OD As Object)
Select Case OD.GetType.Name
Case “Integer”
OD+=1
…..
Case “Int32”
OD+=1
…..
Case “String”
OD&=”1”
……
End Select
End Sub

Это называется "проверка типа".
Ну и что?

В Оберонах тоже имеется такая языковая конструкция. Фактически, там есть кое-что "покруче" - оператор WITH по множеству типов для одного объекта - нечто вроде switch\case который точно также может автоматически оптимизироваться в бинарные деревья или хэш таблицы (вместо линейной цепочки проверок). А в Active Oberon имеются и обобщённые объекты.

Раз в программе так написано - то так оно и должно транслироваться в исполняемый код. Речь ведь шла про скрытые проверки типов, которые якобы появляются "из ниоткуда". А здесь они явно написаны в программе.

batu написал(а) ...
Ну, нет у транслятора на момент трансляции информации по объекту. Ни типа не можем построить, ни сформировать команду любимой IBM Add (или все возможные варианты сложения, так как целые (а может и не целые) разной длины могут складыватся разными командами, а уж если там конкатенация, то и подавно.)

А вообще код сгенерировать можем?

- Доктор, когда я делаю так, мне больно.
- А вы так не делайте.

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

batu написал(а) ...
ни тем более адресную часть операнда, потому что адресную часть операнда неизвестно как формировать

Адресная часть - передаётся параметром в процедуру. Если объект передаётся по значению, то адрес указывает на стек. Что неизвестно?

batu написал(а) ...
Еще раз повторить? И никакой компоновщик тут не поможет.

Компоновщик замечательно поможет при "правильной" реализации полиморфизма. Если одна часть типа объявлена в одном модуле, а другая - в другом, то компоновщик может собрать всё вместе.

batu написал(а) ...
Выход один и в выполняемой части программного кода включаетя анализ будущих типов, и все возможные варианты команд.

Вот, например, вызов "виртуальной функции" - это тоже "анализ типа", и весьма эффективный. Обычно виртуальными являются лишь часть всех функций. Если они имеют достаточно большую семантическую нагрузку (по отношению к обычным функциям), то есть "выполнняются долго", то накладные расходы на "виртуальность" становятся исчезающе малыми.
Что ещё изобретать?

batu написал(а) ...
О ссылочных данных и проверке на наличие объектов и «висячих» ссылок. Читайте пожалуйста ссылки, на которые я отсылаю.

Эти ссылки давно прочитаны.
Но о чём речь, непонятно.

Поэтому расскажу подробнее.

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

Решение:
-- сильная типизация указателей и динамических переменных, в результате получаем "ссылочную прозрачность" динамических структур данных, что делает автоматическую сборку мусора довольно тривиальной операцией.
-- запрет ручного освобождения динамической памяти
"Висячие ссылки" возникают из-за ручного освобождения памяти. И запрет на такую операцию решает проблему в корне (а не пытается "лечить следствие")

batu написал(а) ...
Процедура New тут не поможет. Она тоже может выделить память при трансляции, а может и во время выполнения.

Более того, во время исполнения она может выделять блоки памяти разного размера - ровно столько, сколько необходимо для динамической переменной заданного типа. А что ещё от неё нужно?

batu написал(а) ...
Могу привести пример «правильной» (которую транслятор не распознает) программы в которой ссылка идет на отсутствующий объект, но не хочу засорять.

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

batu написал(а) ...
Еще раз спасибо за ссылку на Пролог. Не знаком. Если найду описание то познакомлюсь подробнее. Если пришлете ссылку буду благодарен.

Описание Pефала?
Все pефальщики тут:
http:/refal.net/

batu написал(а) ...
Ваша информация об Эльбрусе попахивает нафталином.

А где у них на странице описание "свежего" Эльбруса, что-нибудь вроде трёхтомника Интела? А не политические статьи для жёлтой прессы?
Ась?

Для меня основным достижением Эльбруса является только EPIC/VLIW архитектура, которая может продолжить развитие после уже изживших себя суперскаляров.

batu написал(а) ...
P.S. Дальше диалог имеет смысл после прочтения работ Бабаяна

Можно предполагать, что прочтение успешно завершено и приступать к обсуждению конкретных технических деталей.

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

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Переход на страницу 1 [2] 3 ... 13 14 15
Перейти: Наверх