Почему в .NET и в Java нет value-type массивов (размещаемых на стеках или внутри объектов)? В чем они провинились? За что их уничтожили?

Может быть потому, что экономили место на стеках? Ведь когда много потоков, то, соответственно, много стеков — на них на все памяти не напасешся, значит надо минимизировать количество данных располагаемых на стеке, самый большой и расточительный тип данных располагаемый на стеке — это массивовый тип данных. Вот, поэтому, наверное массивы и сделали refernce-type. А почему тогда в Оберонах массивы можно располагать на стеке, там же тоже сборка мусора и все такое??? Может есть какая-то другая причина?

Сергей Губанов пишет:

> Может быть потому, что экономили место на стеках? Ведь когда много
> потоков, то, соответственно, много стеков — на них на все памяти не
> напасешся, значит надо минимизировать количество данных располагаемых
> на стеке, самый большой и расточительный тип данных располагаемый на
> стеке — это массивовый тип данных. Вот, поэтому, наверное массивы и
> сделали refernce-type. А почему тогда в Оберонах массивы можно
> располагать на стеке, там же тоже сборка мусора и все такое??? Может
> есть какая-то другая причина?

Может потому, что нафиг это никому не нужно?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Почему в .NET и в Java нет value-type массивов (размещаемых на стеках или внутри объектов)? В чем они провинились? За что их уничтожили?

Если ты имеешь ввиду статические массивы то они есть но в унсейве и во второй версии версии есть не масиивы
http://gzip.rsdn.ru/article/devtools/newinwhitbey2.xml#EHDA

Автор(ы): Владислав Чистяков (VladD2)
Дата: 27.07.2004
Статья является продолжением цикла статей, опубликованных в номере 6 за 2003 год. В ней рассказывается о нововведениях, появившихся в новой версии VS 2005 (Whidbey) и .NET Framework. Упор делается в первую очередь на нововведения, связанные с программированием на C#.

Для стека BufferAlloc или что то типа того
Основная проблема что это по сути структура, но нет проблем передавать в методы как
ref array, Type type, в принципе как это делается в Delphi

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

S>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Почему в .NET и в Java нет value-type массивов (размещаемых на стеках или внутри объектов)? В чем они провинились? За что их уничтожили?

S> Если ты имеешь ввиду статические массивы то они есть но в унсейве

Да есть, но мало того что они только в unsafe режиме, но они еще должны быть простых типов (byte, char, short, int, long, sbyte, ushort, uint, ulong, float или double.). А я хочу value-type массивы любых типов в safe режиме с проверкой индексов и все такое. Почему их нет? В чем причина их изгнания? Что в них плохого?

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

C>Может потому, что нафиг это никому не нужно?

Ну, например, мне нужно. Я сейчас пишу реализацию Real-time Transport Protocol на C#, а там специфика такая что ежесекундно создается и удаляется несколько тысяч мелких объектов (желательно до 100'000 объектов в секунду). Создавать их в динамической памяти с помощью new совсем никак нельзя — будут ужасные тормоза. С другой стороны, создавать их на стеке я не могу так как внутри этих объектов есть массив, а .NET запрещает размещать массивы на стеке. Приходится по страшному извращаться... А вот были бы value-type массивы, извращаться бы не пришлось.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>>Почему в .NET и в Java нет value-type массивов (размещаемых на стеках или внутри объектов)? В чем они провинились? За что их уничтожили?

S>> Если ты имеешь ввиду статические массивы то они есть но в унсейве

СГ>Да есть, но мало того что они только в unsafe режиме, но они еще должны быть простых типов (byte, char, short, int, long, sbyte, ushort, uint, ulong, float или double.). А я хочу value-type массивы любых типов в safe режиме с проверкой индексов и все такое. Почему их нет? В чем причина их изгнания? Что в них плохого?
Для меня самого это загадка. Но наверное еще не пришло время. Дженерики еще года 3 назад были, а еще не вышли в тираж.
Помоему главный девиз Хэйлсберга и компании Торопись не спеша. В конце концов главная задача Net это LongHorn. Да и динамические массивы не столь тормозные. В конце концо Всегда можно организовать такого рода структуры на массиве байт.
А в Яве вооьще нет структур.

Сергей Губанов пишет:

> C>Может потому, что нафиг это никому не нужно?
> Ну, например, мне нужно. Я сейчас пишу реализацию Real-time Transport
> Protocol на C#, а там специфика такая что ежесекундно создается и
> удаляется несколько тысяч мелких объектов (желательно до 100'000
> объектов в секунду). Создавать их в динамической памяти с помощью
> *new* совсем никак нельзя — будут ужасные тормоза.

Нормально все будет. С 100000 короткоживущих объектов GC справляется без
проблем.

> С другой стороны, создавать их на стеке я не могу так как внутри этих
> объектов есть массив, а .NET запрещает размещать массивы на стеке.
> Приходится по страшному извращаться... А вот были бы value-type
> массивы, извращаться бы не пришлось.

А затраты на копирование массива не считали? МС рекомендует не делать
value-типы больше 16 байт — медленнее получается.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Нормально все будет. С 100000 короткоживущих объектов GC справляется без
C>проблем.

Я проводил испытания прототипа программы под Windows и под Linux (Mono). Результаты не утешительны, особенно в Mono. Даже если я не использую вообще ни одного new, то скорость работы мешьше аналога написанного на Си++ под Windows в два раза, а под Mono в пять раз. При использовании new, производительность драмматически падает.

>> С другой стороны, создавать их на стеке я не могу так как внутри этих
>> объектов есть массив, а .NET запрещает размещать массивы на стеке.
>> Приходится по страшному извращаться... А вот были бы value-type
>> массивы, извращаться бы не пришлось.

C>А затраты на копирование массива не считали? МС рекомендует не делать
C>value-типы больше 16 байт — медленнее получается.

Есть такая проблема:

1) скопировать данные из буфера и отдать их клиенту

ИЛИ

2) отдать клиенту сам буфер, а себе создать новый с помощью new.

Копирование — медленно, но new — еще медленнее. Из двух зол выбираю меньшее.

Сергей Губанов пишет:

> C>Нормально все будет. С 100000 короткоживущих объектов GC справляется
> без
> C>проблем.
> Я проводил испытания прототипа программы под Windows и под Linux
> (Mono). Результаты не утешительны, особенно в Mono.

С Mono все понятно — там консервативный GC (я как раз пишу точный GC для
Mono ).

> C>А затраты на копирование массива не считали? МС рекомендует не делать
> C>value-типы больше 16 байт — медленнее получается.
> Есть такая проблема:
> 1) скопировать данные из буфера и отдать их клиенту
> ИЛИ
> 2) отдать клиенту сам буфер, а себе создать новый с помощью *new*.

Может попробовать схему с пулами буферов?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да есть, но мало того что они только в unsafe режиме, но они еще должны быть простых типов (byte, char, short, int, long, sbyte, ushort, uint, ulong, float или double.). А я хочу value-type массивы любых типов в safe режиме с проверкой индексов и все такое. Почему их нет? В чем причина их изгнания? Что в них плохого?
Честно говоря, я не понимаю, как ты собираешься разместить на стеке объект переменной длины, каким является массив. Или у тебя всегда массивы длиной, допустим, 5?

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

P>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Да есть, но мало того что они только в unsafe режиме, но они еще должны быть простых типов (byte, char, short, int, long, sbyte, ushort, uint, ulong, float или double.). А я хочу value-type массивы любых типов в safe режиме с проверкой индексов и все такое. Почему их нет? В чем причина их изгнания? Что в них плохого?
P>Честно говоря, я не понимаю, как ты собираешься разместить на стеке объект переменной длины, каким является массив. Или у тебя всегда массивы длиной, допустим, 5?
Здесь идет речь об обычных паскалевских массивах. По большому счету нет особой разнице между структурой и массивом определенной длины.
Единственно, что по аналогии с паскалем они должны иметь некий тип с описанием типов элементов и размерности, чтобы передавать их в методы копирования итд. За которым может следить компилятор, при этом обеспечивая безопастность. В обероне они есть.
На самом деле использование статических массивов на тестах с тем же Delphi они намного опережают нетовские.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Почему в .NET и в Java нет value-type массивов (размещаемых на стеках или внутри объектов)? В чем они провинились? За что их уничтожили?

В Шарпе есть. Только в небезопасном режиме. И по сути — это не массивы, а просто блоки памяти рассматриваемые как массивы.

СГ>Может быть потому, что экономили место на стеках? Ведь когда много потоков, то, соответственно, много стеков — на них на все памяти не напасешся, значит надо минимизировать количество данных располагаемых на стеке, самый большой и расточительный тип данных располагаемый на стеке — это массивовый тип данных. Вот, поэтому, наверное массивы и сделали refernce-type. А почему тогда в Оберонах массивы можно располагать на стеке, там же тоже сборка мусора и все такое??? Может есть какая-то другая причина?

В Яве и Шарпе обеспечивается полная безопасность. В том числе безопастность передачи ссылок. Так в этих языках запрещено возвращать из методов ссылки на объекты размещенные в стэке. Массив же в этих языках — это первоклассная сущьность и его можно возвращать из методов. Например, в этом примере:

X[] F1()
{
    X[] array; 
    return array;
}

X[] F2()
{
    X[] array    = F2();
}

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

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да есть, но мало того что они только в unsafe режиме, но они еще должны быть простых типов (byte, char, short, int, long, sbyte, ushort, uint, ulong, float или double.). А я хочу value-type массивы любых типов в safe режиме с проверкой индексов и все такое. Почему их нет?

Потому-что это глупость. Это или не эффективно или не безопасно. Даже в С++ разные векторые обычно занимают папять под массивы динамически.

СГ> В чем причина их изгнания? Что в них плохого?

Их никогда небыло. Так что и изгонять было нечего.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ну, например, мне нужно. Я сейчас пишу реализацию Real-time Transport Protocol на C#,

Реал-тайм на Шарпе — это очень правильно! Но надо обязательно запускать все это под Виндовс. Иначе будет не так смешно. Ведь виндовс по определению не реалтайм-ОС.

СГ> а там специфика такая что ежесекундно создается и удаляется несколько тысяч мелких объектов (желательно до 100'000 объектов в секунду).

На современном процессоре это не проблема.

СГ> Создавать их в динамической памяти с помощью new совсем никак нельзя — будут ужасные тормоза.

Кто тебе это сказал?

СГ> С другой стороны, создавать их на стеке я не могу так как внутри этих объектов есть массив, а .NET запрещает размещать массивы на стеке. Приходится по страшному извращаться... А вот были бы value-type массивы, извращаться бы не пришлось.

Извращение — это как раз вэлью-тип-массивы.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я проводил испытания прототипа программы под Windows и под Linux (Mono). Результаты не утешительны, особенно в Mono. Даже если я не использую вообще ни одного new, то скорость работы мешьше аналога написанного на Си++ под Windows в два раза, а под Mono в пять раз. При использовании new, производительность драмматически падает.

Прототип большой? Посмотреть можно?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я проводил испытания прототипа программы под Windows и под Linux (Mono). Результаты не утешительны, особенно в Mono. Даже если я не использую вообще ни одного new, то скорость работы мешьше аналога написанного на Си++ под Windows в два раза, а под Mono в пять раз. При использовании new, производительность драмматически падает.

А профайлер что говорит?

Здравствуйте, Сергей Губанов, Вы писали:

Если бы мне кто-нибудь рассказал как будут в стеке работать два объекта — массива у которых можно изменять размер, я бы согласился с данным вопросом.
Могу предложить сборку мусора в стеке. Вот тормозища будет!

С уважением, Gleb.

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

GZ>Здравствуйте, Сергей Губанов, Вы писали:

GZ>Если бы мне кто-нибудь рассказал как будут в стеке работать два объекта — массива у которых можно изменять размер, я бы согласился с данным вопросом.

Размер массива изменять нельзя.

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

C>С Mono все понятно — там консервативный GC (я как раз пишу точный GC для
C>Mono ).

Круто! Поздравляю.

C>Может попробовать схему с пулами буферов?

Да я так и сделал. Выделяю память в буфере и возвращаю: struct MemoryDescriptor{byte[] array; int offset; int size}. Затем, когда буфер исчерпывается, забываю о нем и создаю новый. Все старые буферы будут удалены GC тогда когда все соответсвующие MemoryDescriptor "рассосутся". Все вроде хорошо, но вот только выход индексов за пределы offset и offset+size-1 сама система контролировать не может, следовательно, если что-то по ошибке изломается, то будет труднообнаружимая порча памяти.

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

VD>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Ну, например, мне нужно. Я сейчас пишу реализацию Real-time Transport Protocol на C#,

VD> Реал-тайм на Шарпе — это очень правильно! Но надо обязательно запускать все это под Виндовс. Иначе будет не так смешно. Ведь виндовс по определению не реалтайм-ОС.

RTP работает с промежутками времени порядка 20 миллисекунд (50 пакетов в секунду). Плюс к этому джиттер буфер устанавливается обычно на 100-300 миллисекунд. Это не такие уж экстремальные промежутки времени, чтобы было смешно работать под Windows.NET. Да, естественно, правильные программы написанные на C++ работают под Linux и поддерживают до 1000 сокетов одновременно принимающих 50 пакетов в секунду и отправляющих другие 50 пакетов в секунду (процессор ~ 1 ГГц). Под Windows.NET, максимальное количество одновременно работающих сокетов поменьше примерно в два раза (так показало тестирование), но, собственно, я сейчас пишу немного другую программу, для нее одной сотни одновременно работающих сокетов (по 50+50 пакетов в секунду) вполне достаточно.