Не пора ли нам перейти на D - Философия программирования

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Чего

? Любой человек, кто в школе хотя бы немного видел математику (я думаю, что все-таки подавляющее большинство людей у нас в стране имеет хотя бы среднее образование) читает конструкции вида sin(x-1)*x совершенно однозначно.

VD>Ага и совершенно не так как это требует синтаксис Хаскеля.

Ты что-то путаешь, как раз тут будет полное соответствие синтаксису Хаскеля.

VD>А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.

Тут тоже мат. значение и значение выражения в Хаскеле совпадают.
Влад, ты в чём разницу нашёл-то?

Здравствуйте, Cyberax, Вы писали:

C>Собственно, я сначала хотел портировать N. на LLVM, чтобы сделать потом
C>на нем аналог Эрланга и добавить туда фичи типа RI для управления
C>памятью. Потому как Эрланг работает неплохо, но на контроллерах с 170MHz
C>уже слишком медленно.

Т.е. ты хочешь получить аналогичную модель, но более быструю за счёт статической типизации? Или есть ещё какие-то моменты оптимизации?

Курилка wrote:
> C>Собственно, я сначала хотел портировать N. на LLVM, чтобы сделать потом
> C>на нем аналог Эрланга и добавить туда фичи типа RI для управления
> C>памятью. Потому как Эрланг работает неплохо, но на контроллерах с 170MHz
> C>уже слишком медленно.
> Т.е. ты хочешь получить аналогичную модель, но более быструю за счёт
> статической типизации? Или есть ещё какие-то моменты оптимизации?
Ага, я планирую повторить большую часть Эрланга. Если подумать, то
AppDomain'ы из .NET замечательно подходят для разделения границ потоков.
Хотя, наверное, придется придумать что-то свое.

На внутренности Эрланга я смотрел — мало что можно сделать. HiPE уже
занимается выводом типов и JIT-компиляцией, но на моих тестах он
существенного прироста скорости не дал.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Ага, я планирую повторить большую часть Эрланга. Если подумать, то
C>AppDomain'ы из .NET замечательно подходят для разделения границ потоков.
C>Хотя, наверное, придется придумать что-то свое.

C>На внутренности Эрланга я смотрел — мало что можно сделать. HiPE уже
C>занимается выводом типов и JIT-компиляцией, но на моих тестах он
C>существенного прироста скорости не дал.

Круто.
Можно будет как-нибудь вам хотябы в бета-тестеры потом записаться?

Кстати, почему CLI а не JVM?

Курилка wrote:
> C>На внутренности Эрланга я смотрел — мало что можно сделать. HiPE уже
> C>занимается выводом типов и JIT-компиляцией, но на моих тестах он
> C>существенного прироста скорости не дал.
> Круто.
> Можно будет как-нибудь вам хотябы в бета-тестеры потом записаться?
> Кстати, почему CLI а не JVM?
Хотя бы потому, что JVM для LLVM уже есть

Там не хватает только
интерфейса с GC (в LLVM еще не было интеграции с GC, когда ее писали) и
мелочей типа многомерных массивов.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:
>> Кстати, почему CLI а не JVM?
C>Хотя бы потому, что JVM для LLVM уже есть

Там не хватает только
C>интерфейса с GC (в LLVM еще не было интеграции с GC, когда ее писали) и
C>мелочей типа многомерных массивов.

А почему не взята тогда за основу готовая JVM, если она есть? И на ней реализовать идеи эрланга?
Просто не совсем понимаю логику — зачем нужна реализация CLI для реализации эрланговских идей? Для интероперабельности?
И вообще какая, если не секрет, конечная цель продукта? Просто перегонять CLI-байткод в LLVM — это одна задача, эрланговская параллельность — другая задача, каким образом они пересекаются?

Курилка wrote:
> C>Хотя бы потому, что JVM для LLVM уже есть Там не хватает только
> C>интерфейса с GC (в LLVM еще не было интеграции с GC, когда ее писали) и
> C>мелочей типа многомерных массивов.
> А почему не взята тогда за основу готовая JVM, если она есть? И на ней
> реализовать идеи эрланга?
Я просто не вижу смысла портировать JVM — она и так уже есть везде, где
только можно.

> Просто не совсем понимаю логику — зачем нужна реализация CLI для
> реализации эрланговских идей? Для интероперабельности?
> И вообще какая, если не секрет, конечная цель продукта? Просто
> перегонять CLI-байткод в LLVM — это одна задача, эрланговская
> параллельность — другая задача, каким образом они пересекаются?
Я хочу взять достаточно мощный язык (N.), а потом добавить туда
примитивы для многозадачности в Эрланговском стиле. Это можно сделать
даже в рамках CLR.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:
>> Просто не совсем понимаю логику — зачем нужна реализация CLI для
>> реализации эрланговских идей? Для интероперабельности?
>> И вообще какая, если не секрет, конечная цель продукта? Просто
>> перегонять CLI-байткод в LLVM — это одна задача, эрланговская
>> параллельность — другая задача, каким образом они пересекаются?
C>Я хочу взять достаточно мощный язык (N.), а потом добавить туда
C>примитивы для многозадачности в Эрланговском стиле. Это можно сделать
C>даже в рамках CLR.

Но значительно медленней без поддержки в виртуальной машине?
Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на модель CLI.
У меня нет уверенности, что это в принципе возможно. От мутабельности переменных фиг избавишься, а это, сам понимаешь, модель уже сильно поменяет.
Реализация подобия эрланга на немерле — это тоже будет ваш проект или как?

Курилка wrote:
> C>Я хочу взять достаточно мощный язык (N.), а потом добавить туда
> C>примитивы для многозадачности в Эрланговском стиле. Это можно сделать
> C>даже в рамках CLR.
> Но значительно медленней без поддержки в виртуальной машине?
В том-то и дело, что я хочу добавить поддержку в VM с интерфейсом в виде
intrinsic-функций.

> Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на
> модель CLI.
Просто

> У меня нет уверенности, что это в принципе возможно. От мутабельности
> переменных фиг избавишься, а это, сам понимаешь, модель уже сильно поменяет.
> Реализация подобия эрланга на немерле — это тоже будет ваш проект или как?
Так пусть себе мутируют — для посылки сообщений между потоками можно
будет использовать только гарантировано иммутабельные объекты или
использовать глубокое копирование. А внутри потоков может быть что угодно.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:
>> Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на
>> модель CLI.
C>Просто

Да? Интересно было бы посмотреть

>> У меня нет уверенности, что это в принципе возможно. От мутабельности
>> переменных фиг избавишься, а это, сам понимаешь, модель уже сильно поменяет.
>> Реализация подобия эрланга на немерле — это тоже будет ваш проект или как?
C>Так пусть себе мутируют — для посылки сообщений между потоками можно
C>будет использовать только гарантировано иммутабельные объекты или
C>использовать глубокое копирование. А внутри потоков может быть что угодно.

Ну если забить на софтриалтайм, то да, но тогда на программисте будет лежать груз ответственности, что его бесконечный цикл не сьест всё время процессорное у ВМ. Или же будет какое-нибудь комбинирование лёгких и обычных потоков типа того, что в Scala.Actors возможно?
А проект на Немерле — секрет? Просто если Open Source, то возможно было бы интересно поучаствовать.

Курилка wrote:
>> > Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на
>> > модель CLI.
> C>Просто
> Да? Интересно было бы посмотреть
Если кратко — то в каждый объект добавляется флажок "immutable", после
того, как этот флажок выставлен попытки записать в объект будут вызывать
exception (в релизе можно будет отключить эту проверку).

Естественно, immutable-объект может указывать только на immutable-объекты.

> C>Так пусть себе мутируют — для посылки сообщений между потоками можно
> C>будет использовать только гарантировано иммутабельные объекты или
> C>использовать глубокое копирование. А внутри потоков может быть что угодно.
> Ну если забить на софтриалтайм, то да, но тогда на программисте будет
> лежать груз ответственности, что его бесконечный цикл не сьест всё время
> процессорное у ВМ.
Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
не отменял.

> Или же будет какое-нибудь комбинирование лёгких и
> обычных потоков типа того, что в Scala.Actors возможно?
Думаю пока. Легкие потоки кто-то уже реализовывал на LLVM, да и не
сильно это сложно.

> А проект на Немерле — секрет? Просто если Open Source, то возможно было
> бы интересно поучаствовать.
Проект на С++, так как сама LLVM на С++. Будет OpenSource, начнется пока
ориентировочно 1 мая (я скоро улетаю в командировку, а без моего
личного присутствия начинать не хочется).

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:
>> Ну если забить на софтриалтайм, то да, но тогда на программисте будет
>> лежать груз ответственности, что его бесконечный цикл не сьест всё время
>> процессорное у ВМ.
C>Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
C>не отменял.
Т.е. всёж ответственность на программисте и любой кривой код сможет "подвесить" виртуальную машину?

>> А проект на Немерле — секрет? Просто если Open Source, то возможно было
>> бы интересно поучаствовать.
C>Проект на С++, так как сама LLVM на С++. Будет OpenSource, начнется пока
C> ориентировочно 1 мая (я скоро улетаю в командировку, а без моего
C>личного присутствия начинать не хочется).
Теперь я уже запутался...
Ты озвучил 2 задачи:
1. CLI на LLVM
2. Реализации эрланговской модели на чём-нибудь типа N. на базе CLI

первый пункт понятно на C++, но второй?

Курилка wrote:
> C>Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
> C>не отменял.
> Т.е. всёж ответственность на программисте и любой кривой код сможет
> "подвесить" виртуальную машину?
Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
проблемы-то?

> C>Проект на С++, так как сама LLVM на С++. Будет OpenSource, начнется пока
> C> ориентировочно 1 мая (я скоро улетаю в командировку, а без моего
> C>личного присутствия начинать не хочется).
> Теперь я уже запутался...
> Ты озвучил 2 задачи:
> 1. CLI на LLVM
> 2. Реализации эрланговской модели на чём-нибудь типа N. на базе CLI
> первый пункт понятно на C++, но второй?
Тоже на С++ — ведь придется VM расширять. Естественно, потребуются
какая-то интеграция со стороны N. — но это уже будут мелочи.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:
>> C>Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
>> C>не отменял.
>> Т.е. всёж ответственность на программисте и любой кривой код сможет
>> "подвесить" виртуальную машину?
C>Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
C>проблемы-то?

Ну не подвесить, а сьесть почти всё процессорное время. И тот поток, где будет этот вечный цикл ты прервать не сможешь для использования другими лёгкими процессами. Чего в Эрланге не получится.

Курилка wrote:
> C>Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
> C>проблемы-то?
> Ну не подвесить, а сьесть почти всё процессорное время. И тот поток, где
> будет этот вечный цикл ты прервать не сможешь для использования другими
> лёгкими процессами.
Почему??? У нас ведь не кооперативная многозадачность с явным вызовом
yeild. Поток с вечным циклом — это просто один из претендентов на
процессорное время. То что в нем ничего полезного не делается — это
ничего не значит.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:
>> C>Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
>> C>проблемы-то?
>> Ну не подвесить, а сьесть почти всё процессорное время. И тот поток, где
>> будет этот вечный цикл ты прервать не сможешь для использования другими
>> лёгкими процессами.
C>Почему??? У нас ведь не кооперативная многозадачность с явным вызовом
C>yeild. Поток с вечным циклом — это просто один из претендентов на
C>процессорное время. То что в нем ничего полезного не делается — это
C>ничего не значит.

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

Здравствуйте, Курилка, Вы писали:

C>>Почему??? У нас ведь не кооперативная многозадачность с явным вызовом
C>>yeild. Поток с вечным циклом — это просто один из претендентов на
C>>процессорное время. То что в нем ничего полезного не делается — это
C>>ничего не значит.
К>На лёгких процессах в рамках одного потока кооперативная и есть. Другое дело, что за этими потоками может шедулер следить и т.п. в другом потоке.
Это означает, что с точки зрения потока, многозадачность будет вытесняющей. А то что планировщик реализуется не ядром ОС — это уже детали.

К>В рамках же эрланговской модели всё решается в рамках вообще одного потока и кооперативная многозадачность, только вот там дробление процессорного времени по редукциям идёт, а редукцию реально длинной сделать не получится.
К>А так как ты будешь перехватывать управление у процесса, который в бесконечный цикл вошёл, причём возможно там нужно сохранять соостояние и т.п. (что приводит к варианту с обычными потоками)?
Останавливаем его на ближайшем GC safepoint'е (очень удачная синэргетика получается

), сохраняем стек c регистрами и передаем управление "кому нужно".

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Курилка, Вы писали:

К>>А так как ты будешь перехватывать управление у процесса, который в бесконечный цикл вошёл, причём возможно там нужно сохранять соостояние и т.п. (что приводит к варианту с обычными потоками)?
C>Останавливаем его на ближайшем GC safepoint'е (очень удачная синэргетика получается

), сохраняем стек c регистрами и передаем управление "кому нужно".

OK much better

Вопрос только — а что за сейфпойнты? Насколько трудно их находить, насколько их много в программе и не вырастет ли сохранение стека в вариант обычного переключения контекста по затратам?

Курилка wrote:
> OK much better
> Вопрос только — а что за сейфпойнты? Насколько трудно их находить,
> насколько их много в программе и не вырастет ли сохранение стека в
> вариант обычного переключения контекста по затратам?
Safepoint'ы нужны для точного GC в любом случае.

Если кратко, то представь метод:

void someMethod()
{
    SomeObject obj1=new ...;
    for(int f=0;f<obj1.getSomeNum();f++)
    {
        AnotherObject obj2=obj1.getSomething(f);
        obj2.someVar=obj2.someVar*2; //(1)
    }
    ...
}

Теперь представим, что в точке (1) у нас закончилась память (в другом
потоке какой-то гад распределил объект в 50Мб) и запустился GC. Для
своей работы GC должен прервать выполнение всех потоков и начать
обследовать объекты.

Однако, для этого GC нужно точно знать в каких регистрах и по каким
смещениям в стеке сейчас лежат указатели на объекты. Для этого в
программах "расставляют" safepoint'ы (сам safepoint никак не выделяется
в коде) для которых точно известно расположение ссылок на объекты,
обычно для этого строятся register map'ы и stackmap'ы (они действительно
обычно занимают некоторый объем, хотя в новой JVM от Sun'а они строятся
динамически по требованию).

Safepoint'ы обычно расставляются перед каждым условным переходом,
вызовом функции и обычно после некоторого числа инструкций (вроде бы,
после 100 инструкций в JVM).

Так что при начале цикла сборки GC просто ждет, пока все потоки не
остановятся на safepoint'ах (кстати, для этого используют интересные
трюки вроде hot code patching). А так как safepoint'ы расставляются
перед вызовами функций (в том числе и "new"), мы можем гарантировать,
что при активном цикле сборки у нас потоки до остановки на ближайшем
safepoint'е не смогут сделать никаких существенных операций с памятью.

Эхх... Надо мне будет как-нибудь дописать свою статью о GC

Posted via RSDN NNTP Server 2.0

От:	Курилка	http://kirya.narod.ru/
Дата:	05.03.07 07:50
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	05.03.07 08:17
Оценка:

	От:	Cyberax
	Дата:	05.03.07 08:28
	Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	05.03.07 09:07
Оценка:

	От:	Cyberax
	Дата:	05.03.07 09:30
	Оценка: