Здравствуйте, Oyster, Вы писали:
O>Если б он был не надуманным, вы бы применили другой подход в гонке за перфомансом.
Так вот мне и пришлось применить...
O>И таки очень может быть, что по итогу Оберон ещё и медленнее на аналогичных операциях?
Не понял. Что именно?
O> При грамотной реализации вполне можно сделать пул самоочищающимся. Например, сделать пул на слабых ссылках — GC сам подберёт долгое время не используемые массивы из пула.
Да, не спорю, можно. Но и Вы тоже не спорьте с тем, что всё это слишком сложно по сравнению с тривиальнейшим размещением временного массива на стеке.
O> Такое ощущение, что Сергей схватился за свою мегафичу "локальных массивов" и считает, что её отсутствие уже влечёт за собой несостоятельность того или иного языка.
Мелко берёте. Я кидал камень не в огород языка C#, а в огород двух платформ: дотнета и джавы.
O>
O>а) Либо написать компилятор моего любимого оберона под дотнет, но тогда я: 1) потеряю чисто оберонистые библиотеки исходников которых у меня нет; 2) заработаю огромадные потери производительности, так как дотнетская вычислительная модель (или как там это назвать) "слабее" чем оберонистая (в дотнете нет нормальных value-типов, массивов, вложенных процедур).
O>Я попытался показать, что никаких "огромадных" потерь производительности не будет, что есть и другие способы работы с временными массивами, кроме создания массивов на стеке... боюсь, я не был услышан. Или же меня просто не хотели слушать.
Если я напишу программу с процедурой:
PROCEDURE P;
VAR a: ARRAY N OF INTEGER;
BEGIN
...
END P;
то будучи скомпилированной и запущенной под родной оберон системой времени исполнения она будет работать быстро; но она же будучи скомпилирована под платформу дотнет или под платформу джава будет работать в несколько раз медленнее из-за того что строчка VAR a: ARRAY N OF INTEGER; будет скрытым образом переделана в строчку:
int[] a = new int[N];
Вот они — скрытые, неявные, не ожидаемые огромные (в несколько раз) потери!!!!! Вот именно это я и имел в виду. Писать компиляторы оберонов под платформы дотнет и джава значит заранее соглашаться с тем, что программы скомпилированные такими компиляторами будут работать медленнее (ибо разные вычислительные модели у этих платформ). А вот наоборот, исполнять дотнетские или джавовские программы на соответствующим образом "подкрученной" обероннистой системе времени исполнения, не приведет к потере производительности дотнетских или джава программ. Вот именно в этом смысле я заявил, что дотнетская (и джавовская) вычислительная модель "слабее" чем оберонистая (надо было сказать не "слабее", а "меньше", т.е. оберонистая платформа может вобрать в себя дотнетскую и ждавистую, а наоборот нет). Да, действительно, слово "слабее" неудачное...
O>Сергей, повторю ещё раз, специально для вас, — наличие или отсутствие той или иной фичи в языке ещё не говорит о его превосходстве/низменности. Это может говорить лишь о незнании других фич языка, заменяющих отсутствующую фичу.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Oyster, Вы писали:
O>>Если б он был не надуманным, вы бы применили другой подход в гонке за перфомансом.
СГ>Так вот мне и пришлось применить...
Ну и? Не вижу в этом ничего плохого.
O>>И таки очень может быть, что по итогу Оберон ещё и медленнее на аналогичных операциях?
СГ>Не понял. Что именно?
Это я спрашивал — быстрее ли Оберон, чем C#, или нет?
O>> При грамотной реализации вполне можно сделать пул самоочищающимся. Например, сделать пул на слабых ссылках — GC сам подберёт долгое время не используемые массивы из пула.
СГ>Да, не спорю, можно. Но и Вы тоже не спорьте с тем, что всё это слишком сложно по сравнению с тривиальнейшим размещением временного массива на стеке.
O>> Такое ощущение, что Сергей схватился за свою мегафичу "локальных массивов" и считает, что её отсутствие уже влечёт за собой несостоятельность того или иного языка.
СГ>Мелко берёте. Я кидал камень не в огород языка C#, а в огород двух платформ: дотнета и джавы.
Цитирую себя:
... несостоятельность того или иного языка ...
Я специально абстрагировался от конкретного языка тут. Вы вообще обычно кидаете камень куда-то далеко — сразу и не разберёшь, в кого
O>>
O>>а) Либо написать компилятор моего любимого оберона под дотнет, но тогда я: 1) потеряю чисто оберонистые библиотеки исходников которых у меня нет; 2) заработаю огромадные потери производительности, так как дотнетская вычислительная модель (или как там это назвать) "слабее" чем оберонистая (в дотнете нет нормальных value-типов, массивов, вложенных процедур).
O>>Я попытался показать, что никаких "огромадных" потерь производительности не будет, что есть и другие способы работы с временными массивами, кроме создания массивов на стеке... боюсь, я не был услышан. Или же меня просто не хотели слушать.
СГ>Если я напишу программу с процедурой: СГ>
СГ>PROCEDURE P;
СГ> VAR a: ARRAY N OF INTEGER;
СГ>BEGIN
СГ> ...
СГ>END P;
СГ>
СГ>то будучи скомпилированной и запущенной под родной оберон системой времени исполнения она будет работать быстро; но она же будучи скомпилирована под платформу дотнет или под платформу джава будет работать в несколько раз медленнее из-за того что строчка VAR a: ARRAY N OF INTEGER; будет скрытым образом переделана в строчку: СГ>
СГ>int[] a = new int[N];
СГ>
СГ>Вот они — скрытые, неявные, не ожидаемые огромные (в несколько раз) потери!!!!! Вот именно это я и имел в виду. Писать компиляторы оберонов под платформы дотнет и джава значит заранее соглашаться с тем, что программы скомпилированные такими компиляторами будут работать медленнее (ибо разные вычислительные модели у этих платформ).
Тут, милейший, всё зависит от производителей компиляторов.
СГ>А вот наоборот, исполнять дотнетские или джавовские программы на соответствующим образом "подкрученной" обероннистой системе времени исполнения, не приведет к потере производительности дотнетских или джава программ.
Почему это?
СГ>Вот именно в этом смысле я заявил, что дотнетская (и джавовская) вычислительная модель "слабее" чем оберонистая (надо было сказать не "слабее", а "меньше", т.е. оберонистая платформа может вобрать в себя дотнетскую и ждавистую, а наоборот нет). Да, действительно, слово "слабее" неудачное...
О Боги! Чувствую, затягивает меня булькающая пучина Оберона...
А если серьёзно, то чего-то не видно, как Оберон рулит. А если ещё серьёзней, то на великую технологий Оберон не тянет, вы уж извините. Как, кстати, Оберон собирается вбирать те же дотнетовские reflection и атрибуты?
А если совсем серьёзно, то тогда уж Лисп, но никак не Оберон.
O>>Сергей, повторю ещё раз, специально для вас, — наличие или отсутствие той или иной фичи в языке ещё не говорит о его превосходстве/низменности. Это может говорить лишь о незнании других фич языка, заменяющих отсутствующую фичу.
СГ>А для платформы?
Аналогично. Незнание фич, специфичных для платформы, не освобождает от ответственности думать, прежде чем отвечать.
Здравствуйте, Oyster, Вы писали:
O>Почему это на момент чистки практически все они находятся во 2-м поколении?
Есть много потоков.
Несколько из них вызвали Calculate и сидят в ней, вычисляют...
Затем еще несколько вызвали Calculate (каждая из которых вызвала new) в то время когда первые еще не закончили свою работу.
Если Сборщик мусора запускался (поводом для запуска могли быть вызовы new), то он перевел те первые несколько массивов в следующее поколение.
Затем еще несколько потоков залезли в Calculate в то время когда предыдущие потоки еще сидят в ней же.
Если Сборщик мусора запускался, то он перевел уже созданные массивы еще на одно поколение "вглубь".
Если общее количество потоков велико, то так продолжается много раз.
Вдруг, те самые первые несколько потоков наконец-то закончили вычисления и вышли из своих Calculate.
Сколько раз вызывался сборщик мусора за это время? Он вызвался много раз. При каждом его вызове каждый из уже
созданных массивов перемещался в следующее поколение. Так что если потоков много, то с большой вероятностью
на момент удаления каждый из массивов находится в последнем поколении.
Здравствуйте, Сергей Губанов, Вы писали:
O>>Почему это на момент чистки практически все они находятся во 2-м поколении?
СГ>Есть много потоков. СГ>Несколько из них вызвали Calculate и сидят в ней, вычисляют... СГ>Затем еще несколько вызвали Calculate (каждая из которых вызвала new) в то время когда первые еще не закончили свою работу. СГ>Если Сборщик мусора запускался (поводом для запуска могли быть вызовы new), то он перевел те первые несколько массивов в следующее поколение. СГ>Затем еще несколько потоков залезли в Calculate в то время когда предыдущие потоки еще сидят в ней же. СГ>Если Сборщик мусора запускался, то он перевел уже созданные массивы еще на одно поколение "вглубь". СГ>Если общее количество потоков велико, то так продолжается много раз. СГ>Вдруг, те самые первые несколько потоков наконец-то закончили вычисления и вышли из своих Calculate. СГ>Сколько раз вызывался сборщик мусора за это время? Он вызвался много раз. При каждом его вызове каждый из уже СГ>созданных массивов перемещался в следующее поколение. Так что если потоков много, то с большой вероятностью СГ>на момент удаления каждый из массивов находится в последнем поколении.
Ну если у вас Calculate так редко вызывается, то и проблема исчерпывается, т.к. GC будет собирать эти массивы очень редко...
Здравствуйте, Oyster, Вы писали:
O>Ну если у вас Calculate так редко вызывается, то и проблема исчерпывается, т.к. GC будет собирать эти массивы очень редко...
1) А что тогда разница в скорости в несколько раз...
2) А нафига программа то и дело захватывает всю доступную оперативную память (а потом освобождает и так туда-суда, туда-суда) вместо того чтобы работать с фиксированным малым количеством памяти...
СГ>Тут я возился со сборщиками мусора в BlackBox и MS .NET
А ответы в теме читали?... Я это к тому, что там у людей тоже была некая аргументация... или вы и те сообщения успешно игнорировали?
СГ>Если сами надумаете тестировать, то вот один из самых лучших (бесплатных) компиляторов Modula-2/Oberon-2: СГ>http://www.excelsior-usa.com/xds.html
Здравствуйте, Сергей Губанов, Вы писали:
O>>Ну если у вас Calculate так редко вызывается, то и проблема исчерпывается, т.к. GC будет собирать эти массивы очень редко...
СГ>1) А что тогда разница в скорости в несколько раз...
А про это уже пальцы устали отвечать. Читаем выше. Ключевые слова: кеширование массивов.
СГ>2) А нафига программа то и дело захватывает всю доступную оперативную память (а потом освобождает и так туда-суда, туда-суда) вместо того чтобы работать с фиксированным малым количеством памяти...
У меня дежавю — такое ощущение, что я вам уже отвечал на такие вопросы... Отвечу ещё раз — есть и другие подходы к созданию/использованию временных массивов (см. предыдущие сообщения).
Здравствуйте, Oyster, Вы писали:
O>А ответы в теме читали?... Я это к тому, что там у людей тоже была некая аргументация... или вы и те сообщения успешно игнорировали?
Читал.
(Специально отвечаю, чтобы не быть обвиненным в игнорировании этого сообщения . Блин может мне надо после каждого сообщения писать свое: "Ознакомился")
Здравствуйте, Oyster, Вы писали:
O>А про это уже пальцы устали отвечать. Читаем выше. Ключевые слова: кеширование массивов.
O>У меня дежавю — такое ощущение, что я вам уже отвечал на такие вопросы... Отвечу ещё раз — есть и другие подходы к созданию/использованию временных массивов (см. предыдущие сообщения).
Ну значит, Вы наверное уже точно поняли, что вместо того чтобы писать компиляторы: Oberon ---> .Net, JVM, более перспективно "подкручивать" oberon runtime system так чтобы они сами умели исполнять .Net/JVM модули. А то понимаетели "другие подходы" в них...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Oyster, Вы писали:
O>>А ответы в теме читали?... Я это к тому, что там у людей тоже была некая аргументация... или вы и те сообщения успешно игнорировали?
СГ>Читал.
Я это к тому, что из тех сообщений (аргументов, контрагрументов) становится понятно, что нельзя однозначно сказать, что BlackBox GC лучше или быстрее, чем .NET GC.
СГ> СГ>(Специально отвечаю, чтобы не быть обвиненным в игнорировании этого сообщения . Блин может мне надо после каждого сообщения писать свое: "Ознакомился")
Здравствуйте, Сергей Губанов, Вы писали:
O>>А про это уже пальцы устали отвечать. Читаем выше. Ключевые слова: кеширование массивов.
O>>У меня дежавю — такое ощущение, что я вам уже отвечал на такие вопросы... Отвечу ещё раз — есть и другие подходы к созданию/использованию временных массивов (см. предыдущие сообщения).
СГ>Ну значит, Вы наверное уже точно поняли, что вместо того чтобы писать компиляторы: Oberon ---> .Net, JVM, более перспективно "подкручивать" oberon runtime system так чтобы они сами умели исполнять .Net/JVM модули. А то понимаетели "другие подходы" в них...
Нет, не понял. Вы так и не пояснили, как планируется использовать .NET assemblies из-под Оберона. Подъёмный ли это труд? Один reflection чего стоит...
Здравствуйте, Сергей Губанов, Вы писали: СГ>Ну значит, Вы наверное уже точно поняли, что вместо того чтобы писать компиляторы: Oberon ---> .Net, JVM, более перспективно "подкручивать" oberon runtime system так чтобы они сами умели исполнять .Net/JVM модули. А то понимаетели "другие подходы" в них...
Т.е. получается — сами написать толком не можем — стырим-ка библиотеки у МС и иже с ними. Всёже .нет это прежде всего библиотеки входящие во фреймворк + архитектура на которой они построены (непонятно, правда, как использовать библиотеки обходя стороной эту архитектуру )
Здравствуйте, Oyster, Вы писали:
O>Я это к тому, что из тех сообщений (аргументов, контрагрументов) становится понятно, что нельзя однозначно сказать, что BlackBox GC лучше или быстрее, чем .NET GC.
Зато можно сказать при каких условиях BlackBox GC быстрее MS. Net GC в два-три раза и больше (или во всяком случае точно не медленее):
1) Если необходимое количество памяти не превышает объема установленной оперативной памяти.
2) Если нет большого числа (несколько миллионов) фоновых (т.е. никогда не удаляемых) объектов.
Нормальные условия в общем-то.
А временно не нужные фоновые объекты в этом случае просто рекомендуют сохранять на диск...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Oyster, Вы писали:
O>>Я это к тому, что из тех сообщений (аргументов, контрагрументов) становится понятно, что нельзя однозначно сказать, что BlackBox GC лучше или быстрее, чем .NET GC.
СГ>Зато можно сказать при каких условиях BlackBox GC быстрее MS. Net GC в два-три раза и больше (или во всяком случае точно не медленее): СГ>1) Если необходимое количество памяти не превышает объема установленной оперативной памяти. СГ>2) Если нет большого числа (несколько миллионов) фоновых (т.е. никогда не удаляемых) объектов. СГ>Нормальные условия в общем-то.
СГ>А временно не нужные фоновые объекты в этом случае просто рекомендуют сохранять на диск...
Сергей, сколько можно кормить людей данными высосанными из пальца? Конкретные тесты с описанием и итоговыми результатами есть? Нет — значит всё это лишь досужие домыслы, не более
Здравствуйте, Oyster, Вы писали:
O>Нет, не понял. Вы так и не пояснили, как планируется использовать .NET assemblies из-под Оберона. Подъёмный ли это труд? Один reflection чего стоит...
Я сам еще не знаю, мне эта идея в голову недавно пришла.
Но, с другой стороны, есть же пример реализации дотнета под линукс (Mono), работает же.
Значит принципиальных проблем создания своей реализации дотнетского рантайма нет.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А что будет, если вернуть (управляемую) ссылку на локальную переменную?
Это невозможно. Так что ничего не буедет.
ПК>С массивами в CLI/CLR/.Net этом смысле проблема другого свойства. В CLI/CLR/.Net приходится заранее указывать как будут создаваться объекты того или иного типа, указывая к какой разновидности тип относится: reference или value. Сделать массивы value-типом в остальных случаях (возварат значений из функций и т.п.) было бы слишком накладно. Соответственно, сделали reference-типом, что и влечет за собой невозможность создания их в стеке.
+1
ПК>В общем, вполне ожидаемое ограничение выбранной объектной модели CLI/CLR/.Net. Безопасность здесь, в общем, ни при чем. Вполне можно было бы доработать, если бы потребовали для всех managed языков поддержку типизированного забоксенного значения. Тогда можно было бы делать так (воображаемый синтаксис на C++/CLI): ПК>
ПК>array<int>^ f()
ПК>{
ПК> array<int> a(10); // создали массив в стеке -- в настоящее время невозможно
ПК> . . .
ПК> return a; // при желании вернули, массив "забоксился"
ПК>}
ПК>
Ну, и ужасен этот синтаксис.
А вообще-тогда и боксить ничего не нужно. Можно просто копию возврщать. Но тогда пользователю прийдется думать о том где размещается массив и к каким последствиям это приводит. Ускорения реального это все равно не принесло бы, а вот геморроя принесло бы и не мало.
К тому же еще пришлось бы всегда контролировать объемы данных занимаемых в стеке, так как совершенно реальным стало бы переполнение стека. На сегодня в стеке больших объектов быть не может по определнию.
ПК>Точно так же, как и для int (реальный синтаксис на C++/CLI): ПК>
ПК>int^ f()
ПК>{
ПК> int i = 10; // создали целое в стеке
ПК> . . .
ПК> return i; // вернули, оно "забоксилось"
ПК>}
ПК>
Для int такое можно написать только из любви к искуству . Так
int f()
{
int i = 10; // создали целое в стеке
. . .
return i;
}
как-то проще.
ПК>Впрочем, наверное, для VB.Net/C# это слишком сложно...
Это просто неопревданно сложно. Это как раз тот мусор о котором в С++ приходится думать вместо того чтобы думать о решении прикладной задачи. C# явно проектировали как интуитивно-понятный язык на слежение за которым не нужно тратить времени. Подобные извраты как раз напрочь учивают эту концепцию, а значит и смысл языка.
ПК>Гм... Правильно ли я понимаю, что ты говоришь, что, скажем, для "маленьких векторов" (a la геометрический вектор), в плане быстродействия фактически не будет разницы в следующих случаях (в т.ч. и с учетом последующей уборки созданных во втором случае объектов сборщиком мусора): ПК>
ПК>struct V
ПК>{
ПК> int x;
ПК> int y;
ПК> int z;
ПК>}
ПК>. . .
ПК>V v = new V();
ПК>
ПК>
ПК>int[] a = new int[3];
ПК>
ПК>?
Разница конечно будет, но уловить ее можно будет только в дийствительно критических местах и при условии, что код их использующий очень мал и быстр.
Простой пример, обычно бывает быстрее пользоваться не IEnumerable<T> или IList<T> для перебора коллекции, а скопировать значение коллекции через ICollection в массив и перебирать уже его содержимое. И происходит это потому, что создание массива довольно быстрая операция, а при переборе через IEnumerable<T> каждый вызов несет в себе дополнительне телодвижения связанные с продвижением указателя, контролем неизменяемости коллекции и т.п.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Если массив размещен на стеке — нельзя. СГ>Это касается не только массивов. СГ>Вообще любой объект может быть размещен либо в динамической памяти, и тогда доступ к нему осуществляется через указатель; либо на стеке или внутри другого объекта, но тогда доступ к нему осуществляется только по имени и получить указатель на него невозможно — просто нету в языке средства под названием "получение указателя на объект".
Ну, и что делать если объект размещен в стеке, а его нужно вернуть клиенту?
Или по другому. А что делать если массив нужно передать подпроцедуре?
СГ>Не понял юмора. СГ>Вот код: СГ>
СГ>PROCEDURE P;
СГ> VAR a: ARRAY 3 OF BYTE;
СГ>BEGIN
СГ> ...
СГ>END P;
СГ>
СГ>Что Вы предлагаете взамен?
class P
{
private byte[] _a = new byte[3];
public void F()
{
...
}
}
Ну, и далее:
P p = new P();
for (int i = 0; i < 1000; i++)
p.F();
СГ>Нет, если бы речь шла о 400 байтах или даже о 20 мегабайтах, я бы и не стал поднимать этот вопрос. СГ>Речь же идет о всей доступной памяти. Когда несколько потоков активно вызвают процедуру Calculate внутри которой при каждой ее активации ...
Тебе же сказали: создай массивы заранее. Будет как раз 400 байт на всю программу.
СГ>Все эти слова конечно хорошо, но не понятно какое это имеет отношение к value-типам. СГ>Код использующий value-типы не менее безопасен.
value-типы еще долны быть эффективны. Ну, и к тому же по концепции дотнета value-типы — это именно класс типов. Так что один и тот же тип не может быть одновременно и value-типом, и ссылочным типом. А введение двух типов массивов уже было бы серьезным усложнением.
СГ>А массив это, вообще-то, value-тип, и лишь только в дотнете или яве он лишен этой привилегии.
С какого это рожна массив — это value-тип? Где такой закон можно найти?
Да, примеры на Паскале приводить не нужно. У него работа с массивами сделана крайне не удобно и не эффективно. В С/С++ массивы вообще небезопасны и не удобны.
ЗЫ
В общем, единственное что мне приходит в голову — это то что джит/пре-джит мог бы распозновать случаи локального использования массивов и размещать память под них в стеке. Но это именно оптимизация рантайма ничего не имеющая общего с языковыми концепциями.
С точки же зрения концепции массивы несоменно очень удачно представляются ссылочными типами. Ими легко манимулировать. А это самое важное. Скорость же со временем все равно дойдет до почти идеальной. С С++ было точно так же. Когда-то его ругали за медленность относитально С, а теперь уже почти все признают, что разницы нет. Даже на С++ проще писать более быстрый код.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Oyster, Вы писали:
СГ>>Кстати, легко сообразить, что практически все эти массивы на момент чистки находятся в последнем поколении GC, то есть их чистка происходит от этого еще медленнее.
O>Почему это на момент чистки практически все они находятся во 2-м поколении? Да не занесёт их туда — они же используются относительно недолго. Скорее всего, они дальше нулевого не попадут — используются недолго, в freachable queue не попадут...
O>Эксперты, поправьте если неправ.
Все соврешенно верно. Пчти все временные объекты подбираются при сборке нулевого поколения.
Как раз проталкивание в первое и второе происходит исключительно с объектами на которые есть ссылки из тех самых поколений или из корней GC. А на временные объекты по определению таких ссылок быть не может.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
O>>Нет, не понял. Вы так и не пояснили, как планируется использовать .NET assemblies из-под Оберона. Подъёмный ли это труд? Один reflection чего стоит...
СГ>Я сам еще не знаю, мне эта идея в голову недавно пришла. СГ>Но, с другой стороны, есть же пример реализации дотнета под линукс (Mono), работает же. СГ>Значит принципиальных проблем создания своей реализации дотнетского рантайма нет.
СГ>Значит всё это только дело времени
Боюсь, ничего хорошего из этой идеи не выйдет (ворчу).
Кстати, а зачем вам вообще какая-то интеграция с .NET? Разве BlackBox не самодостаточен? Потому как если хочется заюзать преимущества .NET во всей полноте, то уж лучше имхо и использовать язык, спроектированный специально для .NET — IL... тьфу, т.е. C#
. Блин может мне надо после каждого сообщения писать свое: "Ознакомился")
)
