Здравствуйте, samius, Вы писали:
S>Не сомнваюсь, что Василий об этом знает.
VV>Просто, честно говоря, при желании можно легко сымитировать связный список на динамическом массиве
Вот я и решил акцентировать его внимание на том, что в этом моделировании есть подводный камень. Коль скоро он об этом камне сам не упоминает.
S>А для меня было новостью, что динамических массивов не существует.
Следующий раз, когда мне захочется говорить метафорически. я специально помечу это как-нибудь персонально для тебя
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>А для меня было новостью, что динамических массивов не существует.
PD>Следующий раз, когда мне захочется говорить метафорически. я специально помечу это как-нибудь персонально для тебя
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Правда, есть VirtualAlloc с резервированием и коммитированием по частям. В этом случае можно зарезервировать большой кусок адресного пространства, но не выделять память на весь этот размер. Адресное пространство не жалко (до поры до времени). Потом можно коммитировать от начала и далее маленькими кусочками. Так что массив сможет действительно расти без переаллокаций. Это уже ближе к истине, но все же в пределах зарезервированного размера.
Термин "динамический массив" придумал не я. Предлагаешь вместо него использовать термин "массив, который при добавлении в конец иногда приходится пересоздавать заново и копировать в него существующие элементы, как правило выбирая длину нового массива так, чтобы резервировать место и избежать лишних аллокаций"? Нет, спасибо.
В реальной ситуации стоимость переаллокаций как правило ничтожна (например, в дотнетовских коллекциях размер обычно просто увеличивается в два раза — при таком подходе зарезервированного места всегдя будет много) и ее можно попросту проигнорировать. Да, адресное пространство надо экономить Тем не менее по потреблению памяти массив все равно куда экономнее связного списка.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Термин "динамический массив" придумал не я. Предлагаешь вместо него использовать термин "массив, который при добавлении в конец иногда приходится пересоздавать заново и копировать в него существующие элементы, как правило выбирая длину нового массива так, чтобы резервировать место и избежать лишних аллокаций"? Нет, спасибо.
Не надо спасибо. Я этого не предлагаю. Меня вполне устраивает название "динамический массив". Вообще мне игры в дефиниции не по душе. Еще раз — массивов с изменением размера без переаллокаций быть не может. А с переаллокациями они есть. Называй их хоть динамическими, хоть как-нибудь еще — мне все равно.
ВВ>В реальной ситуации стоимость переаллокаций как правило ничтожна (например, в дотнетовских коллекциях размер обычно просто увеличивается в два раза — при таком подходе зарезервированного места всегдя будет много)
При небольших размерах коллекции — да. При миллионах и сотнях миллионов элементов — вовсе нет.
Но плохо даже не это. Плохо то, что у программы будет очень странная временная зависимость на добавление элемента. В 99.999% — ничтожно. Зато в 0.001% — ого-го!
>и ее можно попросту проигнорировать.
Я там пример привел, на С++ правда, который не работает и никогда в Win32 работать не сможет. Хотя с точки зрения чистой логики он безупречен — было в массиве 1 млрд элементов, а я хочу 1 млрд + 1 элемент. Захоти я сразу 1 млрд + 1 элемент — пожалуйста. А увеличить — не выйдет. Не проигнорируешь. И на C# будет то же самое.
>Да, адресное пространство надо экономить
Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет
Например, мне известно, что у меня в программе не очень много не очень больших объектов, а вот один объект может иметь размер и 16 Кб, и 1 Гб. Своеобразный такой объект, динамический. В этом случае можно спокойно откусить 1 Гб адресного пространства (оставшегося почти 1 Гб на все остальное хватит за глаза) и заполнять его по мере необходимости, понемногу увеличивая и увеличивая. Зачем мне тут экономить, для чего ?
>Тем не менее по потреблению памяти массив все равно куда экономнее связного списка.
Безусловно. Но вот список будет расти пока есть память, а массив, как видишь, не может. Списку безразлична (почти) фрагментация кучи, ему нужно место под один новый элемент, а массиву подай большой непрерывный участок для всех элементов при реаллокации, а его может и не быть при том, что вообще-то свободного места много.
Но в списке нет прямого доступа, а в массиве есть.
Одним словом , я не за массив и не за список. я за то, чтобы употреблялось лучшее по условиям задачи.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Да, адресное пространство надо экономить
PD>Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет
Не понятно. Ведь ресурс-то это как раз адресное пространство, а не память. Мало памяти — почисти диск.
PD>>Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет
S>Не понятно. Ведь ресурс-то это как раз адресное пространство, а не память. Мало памяти — почисти диск.
При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить. А АП у всех 2 Гб, хоть что делай (или 3 на сервере), и оно приватно (если самому не делать часть его публичной), а поэтому от того, как я его использую, никому не холодно и не жарко. И мне его тоже не жалко, пока хватает, конечно.
Например, VirtualAlloc на 1 Гб с MEM_RESERVE. Из примерно 2 Гб АП я зарезервировал 1. И ни одного байта не выделил. Просто пометил адреса как занятые, больше ничего. У меня еще почти 1 Гб осталось, хватит.
А вот если не хватит (например, 2 таких массива нужно), тогда будем и АП экономить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет
S>>Не понятно. Ведь ресурс-то это как раз адресное пространство, а не память. Мало памяти — почисти диск.
PD>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить.
Оперативной памяти нехватить не может (ее может быть просто маловато, тогда будет много свопу). От размера ОП зависит разве что объем свопа. Нехватить может либо АП либо места в файла подкачки. И если диск забит под завязку, то не хватает как-правило места в файле подкачки. Мне странно что я объясняю это спецу по WinAPI.
Здравствуйте, VladD2, Вы писали:
VD>Если не включена поддержка pdb (что может быть и в релизе), nop-ов быть не должно. VD>В прочем, они выкидываются джитом когда тот работает в оптимизирующем режиме.
Да, была включена.
VD>>>Кстати, ты знаком с О-нотацией? VD>>>Не подскажешь какова алгоритмическая сложность перебора списка и массива (в О-нотации)? ВВ>>Более бредовый вопрос не мог спросить? ВВ>>Сложность какого перебора? Сложность доступа по индексу и сложность обращения к полю? VD>Последовательного... с начала к концу. Ты же его тестировал.
Для массива — O(n). Для списка — не знаю. Есть разные варианты перебора, но судя по сгенерированному коду, который я приводил, там идет простой перебор, без подстраховки от циклических ссылок (возможно, потому что их нельзя создать?). А провисаем на всяких castclass-ах, так что алгоритмическая сложность тут не причем.
А тестировал я обещанную тобой эффективность Что, нельзя?
VD>Если по делу, а не ради флэйма, то добро пожаловать. Если найдешь что, только спасибо скажем.
У меня вопросы больше философские Ну ок, спасибо за приглашение
Здравствуйте, samius, Вы писали:
PD>>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить. S>Оперативной памяти нехватить не может (ее может быть просто маловато, тогда будет много свопу). От размера ОП зависит разве что объем свопа. Нехватить может либо АП либо места в файла подкачки.
Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство. Хвати его или не хватит — чисто мои проблемы. Это только адреса, без памяти. Этих адресов 2 млрд. Что хочу с ними — то и делаю, и ни перед кем не отчитываюсь. И если я зарезервирую 1 Гб или же 100 Кб только — от этого ничего не изменится, пока мне хватит второго имеющегося Гб адресов.
Что же касается памяти, то ее не хватить может, так как своп расти не будет неограниченно.
NotificationType
The memory condition under which the object is to be signaled. This parameter can be one of the following values.
Value Meaning
LowMemoryResourceNotification
0
Available physical memory is running low.
HighMemoryResourceNotification
1
Available physical memory is high.
Applications can use memory resource notification events to scale the memory usage as appropriate. If available memory is low, the application can reduce its working set. If available memory is high, the application can allocate more memory.
А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде.
>И если диск забит под завязку, то не хватает как-правило места в файле подкачки.
Этот случай большого интереса не представляет, хотя, конечно, довести систему до того, чтобы на диске со своп-файлом не было нескольких свободных Гб, можно. Но довести систему до LowMemoryResourceNotification можно, даже если свободного места на диске полно.
>Мне странно что я объясняю это спецу по WinAPI.
Не обижайся, но ты просто не разобрался с этим вопросом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить. S>>Оперативной памяти нехватить не может (ее может быть просто маловато, тогда будет много свопу). От размера ОП зависит разве что объем свопа. Нехватить может либо АП либо места в файла подкачки.
PD>Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство.
Что с чем?
PD>А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде.
Видел в прошлом веке, кажись.
>>И если диск забит под завязку, то не хватает как-правило места в файле подкачки.
PD>Этот случай большого интереса не представляет, хотя, конечно, довести систему до того, чтобы на диске со своп-файлом не было нескольких свободных Гб, можно. Но довести систему до LowMemoryResourceNotification можно, даже если свободного места на диске полно.
Можно.
PD>Не обижайся, но ты просто не разобрался с этим вопросом.
Просто все мои проблемы с памятью были только от фрагментации АП на объемах выделений до гигабайта. LowMemoryResourceNotification давно не видел.
Здравствуйте, samius, Вы писали:
PD>>Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство. S>Что с чем?
Адресное пространство с физической памятью, понимая под последней ОП + своп. Это — важнейший ресурс всегда (мы в коммунальной квартире, твое приложение не единственное). А АП — это ресурс только когда его не хватает. Здесь мне ни о ком заботиться не надо, кроме как о себе, да и для себя затраты практически нулевые.
PD>>А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде. S>Видел в прошлом веке, кажись.
Оно никуда не делось. Своп не растет бесконечно — бессмысленно, будет просто пробуксовка ОС.
PD>>Не обижайся, но ты просто не разобрался с этим вопросом. S>Просто все мои проблемы с памятью были только от фрагментации АП на объемах выделений до гигабайта.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство. S>>Что с чем?
PD>Адресное пространство с физической памятью, понимая под последней ОП + своп.
Я не путаю АП и ФП.
PD>Это — важнейший ресурс всегда (мы в коммунальной квартире, твое приложение не единственное). А АП — это ресурс только когда его не хватает. Здесь мне ни о ком заботиться не надо, кроме как о себе, да и для себя затраты практически нулевые.
Ну да, ОП+ своп — ресурс общий, АП — частный.
PD>>>А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде. S>>Видел в прошлом веке, кажись.
PD>Оно никуда не делось. Своп не растет бесконечно — бессмысленно, будет просто пробуксовка ОС.
Да, знаю. Но у меня своп большой и памяти много. Достичь края не получалось. А вот АП на вес золота.
PD>>>Не обижайся, но ты просто не разобрался с этим вопросом. S>>Просто все мои проблемы с памятью были только от фрагментации АП на объемах выделений до гигабайта.
PD>Конечно, тогда будут.
Не правильно выразился. При объеме использованной (под актуальные данные) памяти до гигабайта (это могло быть 300 или 600 Мб) было невозможно выделить несчастные 100Кб. Спасибо LOH-у.
Здравствуйте, samius, Вы писали:
PD>>Адресное пространство с физической памятью, понимая под последней ОП + своп. S>Я не путаю АП и ФП.
Тогда,значит. я не прав.
PD>>Это — важнейший ресурс всегда (мы в коммунальной квартире, твое приложение не единственное). А АП — это ресурс только когда его не хватает. Здесь мне ни о ком заботиться не надо, кроме как о себе, да и для себя затраты практически нулевые. S>Ну да, ОП+ своп — ресурс общий, АП — частный.
Совершенно верно.
PD>>Оно никуда не делось. Своп не растет бесконечно — бессмысленно, будет просто пробуксовка ОС. S>Да, знаю. Но у меня своп большой и памяти много. Достичь края не получалось. А вот АП на вес золота.
Где как. У меня тоже было, причем обидным образом. Под W2000. C++. Куча фрагментировала почему-то АП, хотя не должна была, по моему мнению. И под XP этого не было. А под W2000 почему-то вместо использования сатрых блоков она отводила новый экстент. А был еще VirtualAlloc, он и проваливался, через несколько часов после начала работы. С трудом поборол.
PD>>Конечно, тогда будут. S>Не правильно выразился. При объеме использованной (под актуальные данные) памяти до гигабайта (это могло быть 300 или 600 Мб) было невозможно выделить несчастные 100Кб.
Странно, конечно. Но не зная деталей, вполне могу допустить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп)
Это смотря где и как. Для Решарпера, к примеру, память физическая вообще сейчас не проблема, даже на больших солюшенах ему хватит 200-300 мег. А вот с адресным пространством плохо. 10 студия на все плагины оставляет в лучшем случае 500М спейса. С учетом фрагментации попа может наступить очень быстро.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп)
AVK>Это смотря где и как. Для Решарпера, к примеру, память физическая вообще сейчас не проблема, даже на больших солюшенах ему хватит 200-300 мег. А вот с адресным пространством плохо. 10 студия на все плагины оставляет в лучшем случае 500М спейса.
Ну что же, это лишь подтверждает мою мысль о том, что относиться к ресурсам стали сейчас просто безобразно. На что им там почти 1.5 Г адресного пространства понадобилось ?
Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете. Если, конечно, их писали не с тем же безобразным отношением к ресурсам.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?
ВВ>Просто, честно говоря, при желании можно легко сымитировать связный список на динамическом массиве + энумератор, при этом мы получим кучу бенефитов, например, нам всегда будет известна длина и сложение списков будет стоить дешевле.
Дональд Кнут еще в первом томе детально этот вопрос рассмотрел.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете.
А помнишь, 512 К — это было СТОЛЬКО памяти!!! Весь институт одновременно сидел... AVK>>Это тебе так только кажется за незнанием предмета. PD>Возможно. И все же — что там занимает 1.5 Г АП ?
1.5 Гига — это БЕСКОНЕЧНО МНОГО... PD>Я 2010 не ставил, но как-нибудь посмотрю АП в 2008. Интересно, что там есть. PD>>>P.S. Студию в 64-бита не перевели ? AVK>>Нет, и не собираются. PD>Жаль.
Скорее всего это произойдет после повсеместного перехода ОС на x64.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Что, нельзя?
Ну ок, спасибо за приглашение 
