Коллеги,
Эту тему уже обсуждали на форуме. Насколько я помню — если структура больше чем машинное слово на данном компьютере, то она размещается не в стэке, а в куче. И вроде как была статься об этом в MSDN, только я ее сейчас найти не могу. Можете подтвердить либо опровергнуть данный факт?
Здравствуйте, Nikita Lyapin, Вы писали:
NL>Коллеги, NL>Эту тему уже обсуждали на форуме. Насколько я помню — если структура больше чем машинное слово на данном компьютере, то она размещается не в стэке, а в куче. И вроде как была статься об этом в MSDN, только я ее сейчас найти не могу. Можете подтвердить либо опровергнуть данный факт?
Здравствуйте, Nikita Lyapin, Вы писали:
NL>Коллеги, NL>Эту тему уже обсуждали на форуме. Насколько я помню — если структура больше чем машинное слово на данном компьютере, то она размещается не в стэке, а в куче. И вроде как была статься об этом в MSDN, только я ее сейчас найти не могу. Можете подтвердить либо опровергнуть данный факт?
Сделал тестовый пример, x64 сборка.
struct S64
{
public long p1, p2, p3, p4, p5, p6, p7, p8;
public byte p65;
}
class C64
{
public long p1, p2, p3, p4, p5, p6, p7, p8;
public byte p65;
}
static void F<T>(long l) where T: new()
{
if (l == 0)
{
return;
}
var e = new T(); // S64 - stack, C64 - heap
F<T>(l - 1);
}
static void Main(string[] args)
{
GC.Collect();
GC.WaitForFullGCComplete();
F<C64>(20000); // Pass
GC.Collect();
GC.WaitForFullGCComplete();
F<S64>(20000); // Fail, stack overflow -> S64 is allocated on stack
}
Здравствуйте, Nikita Lyapin, Вы писали:
NL>Коллеги, NL>Эту тему уже обсуждали на форуме. Насколько я помню — если структура больше чем машинное слово...
Строго говоря, ваши рассуждения "ниачом". Вы работаете с ВИРТУАЛЬНОЙ МАШИНОЙ, соотв. никаких "машинных слов" там нет и в помине. Вся подкапотная часть — закрытый ящик и может меняться хоть каждый месяц.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Nikita Lyapin, Вы писали:
NL>>Коллеги, NL>>Эту тему уже обсуждали на форуме. Насколько я помню — если структура больше чем машинное слово...
K>Строго говоря, ваши рассуждения "ниачом". Вы работаете с ВИРТУАЛЬНОЙ МАШИНОЙ, соотв. никаких "машинных слов" там нет и в помине. Вся подкапотная часть — закрытый ящик и может меняться хоть каждый месяц.
Какая нахрен виртуальная машина в .Net Native? Да RuyJit меняетя не сильно. Так же можно говорить о любом нативном компиляторе
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Kolesiki, Вы писали:
K>Строго говоря, ваши рассуждения "ниачом". Вы работаете с ВИРТУАЛЬНОЙ МАШИНОЙ, соотв. никаких "машинных слов" там нет и в помине. Вся подкапотная часть — закрытый ящик и может меняться хоть каждый месяц.
Но для этой виртуальной машины должна выдерживаться одна и та же memory model, иначе получаем проблемы с backward compatibility, performance degradation и прочая и прочая.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Но для этой виртуальной машины должна выдерживаться одна и та же memory model
Шта?? Вы там на Турбо-Си штоле всё ещё пишете? Small, large, tiny... как вспомню, так вздрогну!
Нет никакой memory model уже лет 30. Нужна память — запросил у ОС кусок. А с 64-битной вендой даже размер куска потерял всякий смысл.
Конечно же, JIT'у придётся поднапрячься, чтобы создать правильные размеры, но вот эти игры "в стеке или нет?" — боже... оставьте уже их, вылезайте из 20 века и начинайте создавать что-то полезное! Уже давно колом всем разжевали: если вы — "старый сипиписник", который зациклился на железе — продолжайте писать на этих ООП-ассемблерах. Дотнет же изобрели именно для того, чтобы навсегда прекратить морочить голову ненужными деталями — просто садись и пиши эффективный код. Если программа тормозит, в большинстве случаев это косяк программиста, а не "в стеке или нет?".
Здравствуйте, Kolesiki, Вы писали:
K>Шта?? Вы там на Турбо-Си штоле всё ещё пишете? Small, large, tiny... как вспомню, так вздрогну! K>Нет никакой memory model уже лет 30. Нужна память — запросил у ОС кусок. А с 64-битной вендой даже размер куска потерял всякий смысл. K>Конечно же, JIT'у придётся поднапрячься, чтобы создать правильные размеры, но вот эти игры "в стеке или нет?" — боже... оставьте уже их, вылезайте из 20 века и начинайте создавать что-то полезное! Уже давно колом всем разжевали: если вы — "старый сипиписник", который зациклился на железе — продолжайте писать на этих ООП-ассемблерах. Дотнет же изобрели именно для того, чтобы навсегда прекратить морочить голову ненужными деталями — просто садись и пиши эффективный код. Если программа тормозит, в большинстве случаев это косяк программиста, а не "в стеке или нет?".
Похоже вы совсем не в теме. Зачем нужен Thread.MemoryBarrier? Не задавались таким вопросом? А если подробно, то здесь:
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Но для этой виртуальной машины должна выдерживаться одна и та же memory model
K>Шта?? Вы там на Турбо-Си штоле всё ещё пишете? Small, large, tiny... как вспомню, так вздрогну!
K>Нет никакой memory model уже лет 30. Нужна память — запросил у ОС кусок. А с 64-битной вендой даже размер куска потерял всякий смысл.
"Той самой" модели памяти в терминах small/large/tiny/huge уже давно нету, конечно. Но потребность обозначить правила игры при работе с памятью никуда не делась, а для многоядерных/многосокетных машин вообще встала в полный рост: reordering и прочий CPU-level optimization должны иметь гарантированный сценарий работы, иначе будет как с 3D Max и прочими автокадами во времена пентиумов: на Intel работает ОК, а на AMD виснет через раз.
Здравствуйте, Nikita Lyapin, Вы писали:
NL>Похоже вы совсем не в теме. Зачем нужен Thread.MemoryBarrier?
Пофиг абсолютно. 12 лет пишу на .НЕТ и такую низкоуровневую лабуду никогда не употреблял. Собственно, этим и выдают себя закостенелые "братья по сипипи" — занимаются любой ерундой, лишь бы не делом! Почему ерундой? Да потому что даже документация по твоему методу гласит:
For most purposes, the C# lock statement, the Visual Basic SyncLock statement, or the Monitor class provide easier ways to synchronize data.
Вот и всё, что нужно знать о "специалистах по стеку"
Здравствуйте, Kolesiki, Вы писали:
K>Строго говоря, ваши рассуждения "ниачом". Вы работаете с ВИРТУАЛЬНОЙ МАШИНОЙ, соотв. никаких "машинных слов" там нет и в помине. Вся подкапотная часть — закрытый ящик и может меняться хоть каждый месяц.
Тут нужна подпись "Математики-теоретики о программирование".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, snaphold, Вы писали:
S>Здравствуйте, StatujaLeha, Вы писали:
S> у x86 сборка и у меня F<C64>(20000); не проходит — stackoverlow ошибка S>Почему?
Здравствуйте, VladD2, Вы писали:
VD>Тут нужна подпись "Математики-теоретики о программирование".
Скорее, "DOS головного мозга". Как привыкли лазить немытыми ручищщами по прерываниям, так и не выросли из детских штанишек — всё б им "хакнуть", "посмотреть как работает"... Смысл? Общую инфу и так все знают (про value/reference), её практически достаточно для написания программ. Лезть куда-то глубже — либо время девать некуда, либо ты — инженер этой виртуальной машины. Да и "практика" эта немногого стóит — придут очередные танцоры, перепишут компилер на Расте и трёхадресной машине — и всё, твои "глубокие познания" протухли прямо там, на глубине.
Ну серьёзно, сколько у вас задач и какого характера, что вот прямо нужно влезть и узнать, сколько ж там байт на стеке?! Если у вас есть хоть одна такая задача — вы просто некомпетентный ИТшник, выбравший неправильную платформу. ДотНЕТ сделан для созидания, а хакать — осталось там, в 80-ых на XTшках.
K>Конечно же, JIT'у придётся поднапрячься, чтобы создать правильные размеры, но вот эти игры "в стеке или нет?" — боже... оставьте уже их, вылезайте из 20 века и начинайте создавать что-то полезное! Уже давно колом всем разжевали: если вы — "старый сипиписник", который зациклился на железе — продолжайте писать на этих ООП-ассемблерах. Дотнет же изобрели именно для того, чтобы навсегда прекратить морочить голову ненужными деталями — просто садись и пиши эффективный код. Если программа тормозит, в большинстве случаев это косяк программиста, а не "в стеке или нет?".
Блин, ты хоть раз решал проблемы пользователей? Хотя-бы раз?
Или всегда списывал на какие-то баги, и предлагал винду переставить, раз уж софтина не работает?
У меня тут сейчас пяток дампов лежит от особо важных юзверей (разных и географически разнесённых), и проблема там описывается словами "GUI cannot start".
ESXi 6.5, Windows 10 x64.
Напиши мне особо эффективный код на .net, который решит эту проблему. Цена вопроса — покупка пакетов лицензий почти на 10к вечнозелёных, кстати. Нужно вчера. Дебажить удалённо нельзя: дампы, и логи в помощь.
— Вот за этим нужно понимать, что происходит под капотом.
Решишь такую проблему?
Всё сказанное выше — личное мнение, если не указано обратное.
K>For most purposes, the C# lock statement, the Visual Basic SyncLock statement, or the Monitor class provide easier ways to synchronize data.
Easiest way не означает most efficient, а некоторые части обязаны быть most efficient.
От таких как, ты, которые что-то там ваяют 12 лет, не вдаваясь в детали остаётся тяжкое наследие, которое "в большинстве случаев работает"(звучит как оскорбление, надеюсь?), и на суперсовременных процах едва ворочается.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Kolesiki, Вы писали:
K>Ну серьёзно, сколько у вас задач и какого характера, что вот прямо нужно влезть и узнать, сколько ж там байт на стеке?! Если у вас есть хоть одна такая задача — вы просто некомпетентный ИТшник, выбравший неправильную платформу. ДотНЕТ сделан для созидания, а хакать — осталось там, в 80-ых на XTшках.
Есть такая задача: у некоторых пользователей не работает (в некоторых конфигурациях), есть дампы памяти и логи. Не надо хакать — надо открыть дамп, и посмотреть что не так. Судя по логам падает где-то в недрах WPF на этапе инициализации. Возможно, из-за древнего риббона, который мы таскаем, поддерживая пользователей Win2k3.
Откроешь дамп, посмотришь?
Или "вы просто некомпетентный ИТшник, выбравший неправильную платформу"??????
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Есть такая задача: у некоторых пользователей не работает (в некоторых конфигурациях), есть дампы памяти и логи. Не надо хакать — надо открыть дамп, и посмотреть что не так. Судя по логам падает где-то в недрах WPF на этапе инициализации. Возможно, из-за древнего риббона, который мы таскаем, поддерживая пользователей Win2k3. Ф>Откроешь дамп, посмотришь?
Я так полагаю, дамп вы откроете студией и посмотрите стеки вызовов и значения аргументов. При чем тут "структура больше 64 байт" и прочая "truth about value types"?
p.s. вангую: не хватает зависимостей (возможно нативных типа vcredist) или не та версия дотнета
Здравствуйте, sr_dev, Вы писали:
_>Я так полагаю, дамп вы откроете студией и посмотрите стеки вызовов и значения аргументов. При чем тут "структура больше 64 байт" и прочая "truth about value types"? _>p.s. вангую: не хватает зависимостей (возможно нативных типа vcredist) или не та версия дотнета
Студией очень долго, она далеко не всё умеет, и часто умирает нажравшись памяти. Конечно же Windbg! Студия только для простейших случаев годится, типа взаимоблокировок. Для случаев, когда нужно выяснить, в какую именно кашу превратились платформенные вызовы и игра на WIC студии не хватит. Ну и таки хотелось бы иметь возможность нормально смотреть нативные структуры, раз уж дело коснулось PInvoke и окошек.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Nikita Lyapin, Вы писали:
NL>Коллеги, NL>Эту тему уже обсуждали на форуме. Насколько я помню — если структура больше чем машинное слово на данном компьютере, то она размещается не в стэке, а в куче. И вроде как была статься об этом в MSDN, только я ее сейчас найти не могу. Можете подтвердить либо опровергнуть данный факт?
Суть не в том, находится ли структура в стеке или в куче. Если структура является полем класса, элементом массива или частью замыкания, то она вполне может оказаться в куче. Существенно то, что присваивание структуры (или передача её в качестве параметра) создаёт копию исходной структуры, которая может быть модифицирована независимо от оригинала, а присваивание ссылки на класс создаёт ссылку на тот же экземпляр, и любая модификация этого экземпляра будет видима через все существующие ссылки на него. Размер структуры при этом не имеет значения. Маленькую структуру JIT может целиком уместить в регистр процессора вместо стека; это может повлиять на производительность, но не наблюдаемое функциональное поведение. Теоретически, JIT может положить и экземпляр класса на стек или даже в регистр, если escape анализ указывает на отсутствие алиасинга, или вообще избавиться он него, если возможен constant folding/propagation, но, насколько я знаю, в .NET это пока не реализовано.
