Embarcadero RAD Studio - [108] :: Прикладное программирование

kaz_av

Цитата:

Цитата:
Покажи мне пример, когда, проблема фрагментации стала для натива стала критичной.

Гуглиться на раз.

там чел коммитит 6-7 блоков по 380 мегабайт, это идет в обход MM. А потом освобождает.
В 32-битном режиме!
идиот..

Такая задача либо для 64-разрядных машин, где ,большой фрагментации не будет, либо для специаированного MM.

Он сам виноват. Не такая и проблема: следить чтобы 6-7 блоков не фрагментировались. Это и ежу понятно.

У тебя все примеры такие дурацкие??

Цитата:

Что работает быстрее: последовательный просмотр памяти или прыжки по разным участкам? Так вот первый сценарий это GC, второй - подсчет ссылок.

В плане кэша, ведь ты говоришь о нем: если участок больше 64 байт, линейки кеша, то разницы нет.
Конечно есть префетч, и накладные расходы на стороне RAM для пересылки и вычисления адреса: там, действительно, несколько последовательных чтений или записей выгоднее (DRAM burst).
Но это не поможет : выигрыш невелик по сравнению с ценой кэшевого промаха.

Другими словами, рандомные адреса, не влияют на обработку длинных в массивах(так как там все последовательно), ни на локальные переменные(то все последовательно).

Напротив, наличие активного GC в отдельном потоке, потребляет невеликие ресурсы кэша 3-го уровня. А в процессорах Интел, и вовсе активный GC может вызвать обнуление кэша L2 в другом ядре.

Что же до остального, типа строк, то не даст последовательное размещение особых преимуществ, если объекты больше 64-байт.
Ручное управление памятью тоже не серебряная пуля, но там намного больше контроля. Больше возможностей.

А крохотные объекты обходятся дорого везде: причем GC с ними работает хуже: приходится вычислять достижимость каждого из целой тучи.

Цитата:

А чего не на 4 или 8?

а того, что при вычислении размера буфера, программисты чаще всего ошибаются на 1 элемент, как в том случае, который ты упоминал.
Опыт, батенька

Цитата:

Я тебе предлагал уже самому посмотреть на счетчики любого дотнетовского приложения. Всё от ситуации зависит, когда я мониторил одну софтину там GC кушал сотые доли процента.

мы далее рассмотрим время GC, только поскольку ты использовал JVM в своем примере, то о ней и будем говорить.

Цитата:

Кроме того, что не пригоден для использования в продакшене? Ничем.

Кто сказал? Форк ScaleMM включен даже в дистрибуцию mORMot. Он вполне юзабелен.

Цитата:

Сравнивать iOS и Android, для поисков истины в споре ARC vs. GC, вообще глупо т.к. iOS является оптимизированным решением для железа единственного вендора, а Android универсальная ОС работающая на диком зоопарке разношерстного говна. У меня аппарат далеко не флагман, скорее середнячек. .

iOs приложения тоже вынуждены работать с разными версиями iPhone, которые различаются железом.

Цитата:

Памяти там 2Gb, но свободной почти гигабайт

вот тебе и ответ. GC может быть хорош, когда памяти вдвое более требуемой.
в покое есть половина, а как начинается нагрузка, GC забирает эту память своим оверхедом.
---------
теперь по примеру.
У меня нет оксиджена, да и вообще писать на нем, таргетируя под JVM, -- имхо извращение, так что я написал аналогичный код на жабе.
Прежде всего скажу, что в твоем коде в итерации забирает не более 30 мегабайт=(12букв*2*10+48(размер объекта) )*100'000. Так не пойдет. Нужно создать близкую к предельной нагрузку.
Второе, нужно условиться, сколько же памяти мы разрешаем JVM. Как раз для того, чтобы рассчитать нагрузку.

И третье, код , который ты привел на оксиджене, ужасен. Ну зачем пересоздавать StringBuilder? Это замедляет код почти в два раза! За такое нужно увольнять с формулировкой "нахер".

JVM, которую я использовал

Код:

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode, sharing)

вот код
Код Delphi
Проект iDea, как и проект Delphi, с бинарниками доступны по ссылке
https://yadi.sk/d/7K10xzn3dpbF2
Я сейчас на слабой машине, поэтому все под XP/32

ключ Xmx400m задает предел кучи 400 Мб, ключ Xms200m задает начальный размер кучи в 200 мегабайт(это дает фору JVM)

Код:

>java -Xms200m -Xmx400m -Xmn300m -jar untitled.jar 100000 20 1
cached sb
3 args, 20 tries
string size:36, element size:408
Press enter to start

Memory 387 973 120, using 100 000 elements=39 843Kb(10 % of free heap)
total:184 384Kb, free:174 549Kb
used? memory:9 834Kb
done pass in 266 (13 per 5000 el)
done pass in 234 (11 per 5000 el)
done pass in 375 (18 per 5000 el)
done pass in 235 (11 per 5000 el)
done pass in 875 (43 per 5000 el)
done pass in 234 (11 per 5000 el)
done pass in 1 453 (72 per 5000 el)
done pass in 203 (10 per 5000 el)
done pass in 235 (11 per 5000 el)
done pass in 406 (20 per 5000 el)
done pass in 219 (10 per 5000 el)
done pass in 968 (48 per 5000 el)
done pass in 219 (10 per 5000 el)
done pass in 875 (43 per 5000 el)
done pass in 219 (10 per 5000 el)
done pass in 219 (10 per 5000 el)
done pass in 500 (25 per 5000 el)
done pass in 218 (10 per 5000 el)
done pass in 703 (35 per 5000 el)
done pass in 204 (10 per 5000 el)
---------------------------------
total:280 120Kb, free:140 528Kb
used? memory:139 591Kb, delta:129 757Kb
---------------------------------
Done: 8 875 time done;
---------------------------------
---------------------------------
8 875 time collected;
---------------------------------
total:280 120Kb, free:276 339Kb
used? memory:3 780Kb, delta:-6 054Kb
total:280 120Kb, free:208 528Kb
used? memory:71 591Kb, delta:61 756Kb

итак, 8.56 секунд для 100K элементов в 20 итерациях
замечу на полях, Xmn300m форсирует пул молодых объектов до 300 метров, что увеличивает скорость вдвое: без этого свитча время будет около 16с.

теперь Delphi-32

Код:

>untitled 100000 20 1 400m
Limit Memory to 400MB
Acquire priviledge:TRUE
handle:1972
Result:TRUE
Using elements:100000; Directly Allocated: 52343Kb
---------
Done in 719; 35 per 5000 el
Done in 703; 35 per 5000 el
Done in 719; 35 per 5000 el
Done in 719; 35 per 5000 el
Done in 687; 34 per 5000 el
Done in 719; 35 per 5000 el
Done in 719; 35 per 5000 el
Done in 703; 35 per 5000 el
Done in 718; 35 per 5000 el
Done in 704; 35 per 5000 el
Done in 703; 35 per 5000 el
Done in 718; 35 per 5000 el
Done in 704; 35 per 5000 el
Done in 718; 35 per 5000 el
Done in 719; 35 per 5000 el
Done in 703; 35 per 5000 el
Done in 703; 35 per 5000 el
Done in 719; 35 per 5000 el
Done in 719; 35 per 5000 el
Done in 703; 35 per 5000 el
Done in 734; 36 per 5000 el
Done: 14953

14.85 секунд. Delphi медленнее
Но это -- при том, что размер тестового массива очень мал, в сравнении с размером доступной кучи.

По моим подсчетам, яве требуется от 38 для работы с массивом: около 360 байт на 10 строк плюс 48 байт на объект, ну и 4 байта на список.
Для Delphi требуется не менее 60мегабайт, из-за оверхеда строк по 12байт на каждую.
По моим вычислениям, именно 60 метров использовала JVM, чтобы хранить этот массив.

Но!, судя по тесту, JVM держала около 128 мегабайт, когда при завершении внешнего цикла.

Так что я удвоил количество элементов: не количество прогонов, а количество элементов.

Код:

total:286 720Kb, free:147 103Kb
used? memory:139 616Kb, delta:129 782Kb
---------------------------------
Done: 23 953 time done;
---------------------------------
---------------------------------
23 953 time collected;
---------------------------------
total:276 664Kb, free:272 865Kb
used? memory:3 798Kb, delta:-6 035Kb
total:276 664Kb, free:138 537Kb
used? memory:138 126Kb, delta:128 292Kb

24 секунды, а ведь, должно быть 8.5*2=17
Что же Delphi?

Код:

Done: 29890

почти линейно удвоилось, 30 против 14.85. А тем временем JVM на выходе из цикла сожрала уже 276 664Kb=270 Мб.
Что же произошло?
Запустим еще раз JVM, с ключом -verbose:gc

Код:

>java -Xms200m -Xmx400m -Xmn300m -verbose:gc -jar untitled.jar 200000 20 1

cached sb
3 args, 20 tries
string size:36, element size:408
Press enter to start

Memory 387 973 120, using 200 000 elements=79 687Kb(21 % of free heap)
total:184 384Kb, free:174 549Kb
used? memory:9 834Kb
done pass in 515 (12 per 5000 el)
[GC (Allocation Failure) 163904K->19872K(184384K), 0.1618317 secs]
done pass in 594 (14 per 5000 el)
[GC (Allocation Failure) 183776K->43280K(207296K), 0.3533835 secs]
[Full GC (Allocation Failure) 43280K->43280K(207296K), 0.2921022 secs]
done pass in 1 125 (28 per 5000 el)
[GC (Allocation Failure) , 1.4949862 secs]
[Full GC (Allocation Failure) 286719K->49966K(286720K), 0.6880628 secs]
done pass in 2 641 (66 per 5000 el)
[Full GC (Allocation Failure) 213870K->76672K(267600K), 0.7981438 secs]
done pass in 1 219 (30 per 5000 el)
[Full GC (Allocation Failure) 240576K->103234K(286720K), 1.0608103 secs]
done pass in 1 515 (37 per 5000 el)
done pass in 531 (13 per 5000 el)
[Full GC (Allocation Failure) 286719K->14523K(286720K), 0.3241174 secs]
done pass in 969 (24 per 5000 el)
[GC (Allocation Failure) , 1.4938817 secs]
[Full GC (Allocation Failure) 286719K->41358K(286720K), 0.6118239 secs]
done pass in 2 563 (64 per 5000 el)
[Full GC (Allocation Failure) 205262K->67860K(286720K), 0.7302461 secs]
done pass in 1 156 (28 per 5000 el)
[Full GC (Allocation Failure) 231764K->94394K(286720K), 0.9640220 secs]
done pass in 1 406 (35 per 5000 el)
[Full GC (Allocation Failure) 258298K->121496K(286720K), 1.2126902 secs]
done pass in 1 656 (41 per 5000 el)
done pass in 532 (13 per 5000 el)
[Full GC (Allocation Failure) 286719K->14524K(286720K), 0.3204992 secs]
done pass in 984 (24 per 5000 el)
[Full GC (Allocation Failure) 178428K->41359K(286720K), 0.4725040 secs]
done pass in 906 (22 per 5000 el)
[Full GC (Allocation Failure) 205263K->67861K(286720K), 0.7336974 secs]
done pass in 1 172 (29 per 5000 el)
[Full GC (Allocation Failure) 231765K->94422K(286720K), 0.9798696 secs]
done pass in 1 422 (35 per 5000 el)
[Full GC (Allocation Failure) 258326K->121524K(286720K), 1.2060775 secs]
done pass in 1 656 (41 per 5000 el)
done pass in 532 (13 per 5000 el)
[Full GC (Allocation Failure) 286719K->14524K(286720K), 0.3246451 secs]
done pass in 968 (24 per 5000 el)
---------------------------------
total:286 720Kb, free:147 103Kb
used? memory:139 616Kb, delta:129 782Kb
---------------------------------

15 полных сборок, и еще 4 частичных! А было?

А было шесть полных и 4 частичных. Ну а по времени?
я запустил
jstat -gkutil PID 500 10000
и выходит, что 14.54 секунд было потрачено на сборку, из них 11 - на полную.
В случае со 100000 элементов, цифры совсем другие 4.6 / 2.6

Ну а какие цифры будут при 400 000 элементов, когда под данные придется отвести 280 из 400 мегабайт?

Код:

69 656 time collected;

А Delphi?

Код:

g:\devsoft\myprojects\lab\untitled\delphi\Win32\Release>untitled 400000 20 1 400m
Limit Memory to 400MB
Acquire priviledge:TRUE
handle:1972
Result:TRUE
Using elements:400000; Directly Allocated: 209375Kb
---------
Done in 2875; 35 per 5000 el
Done in 2922; 36 per 5000 el
Done in 2937; 36 per 5000 el
Done in 2922; 36 per 5000 el
Done in 2875; 35 per 5000 el
Done in 2875; 35 per 5000 el
Done in 2859; 35 per 5000 el
Done in 2860; 35 per 5000 el
Done in 2844; 35 per 5000 el
Done in 2843; 35 per 5000 el
Done in 2860; 35 per 5000 el
Done in 2890; 36 per 5000 el
Done in 2875; 35 per 5000 el
Done in 2907; 36 per 5000 el
Done in 2906; 36 per 5000 el
Done in 2859; 35 per 5000 el
Done in 2875; 35 per 5000 el
Done in 2860; 35 per 5000 el
Done in 2875; 35 per 5000 el
Done in 2875; 35 per 5000 el
Done in 2890; 36 per 5000 el
Done: 60500

60.5 секунд, против 69.6 секунд у JVM.
Delphi выигрывает там, где это и нужно: в высоконагруженных сценариях.
При этом она потребляет меньше памяти, не больше 300метров, точнее сказать затрудняюсь
При этом она работает ровнее, обработка 5000 строк занимает одно и то же время, всегда, н-р у меня 35ms, против разброса 10-70 у JVM.
То есть гарантированная отзывчивость у Delphi вдвое выше, чем JVM.

kaz_av
1) Естественно, но это же обман. Мы запоминаем дату, вставляем в файл, потом восстанавливаем. То есть дата исходника одна, а дата изменения файла другая, какая из них логичнее?
2) pre-build events. Ну да хорошо, но он вставит дату только в тех каталогах которые ему настроят, он должен запоминать даты которые были до этого, чтобы быть эргономичнее а не перезаписывать всегда все файлы настроенных каталогов. Он ничем не поможет если я нахожусь в проекте EXE, открываю файл библиотеки package, исправляю там ошибку, и забываю про пакет. EXE будет компилиться с неверной датой в окне About. Тут я обязан прописывать каталоги, помнить кучу нюансов, что обязательно нужен билд.
3) pre-build events. Их в Delphi6 не было, но можно было назначить INotificationModue ToolsAPI. Чтобы сделать это Рей Лишнер (секреты Delphi2) предлагал класть на такую форму свой компонент, который при создании в Design-Time вешает нотификатор, но это не касается тех юнитов которые не имеют форму. Задача была одна - создать свой объект при создании любой закладки любого модуля. Стандартных способов ToolsAPI сделать такое не было даже в d2006. Хотя не то что недокументированным способом, отыскать его изучая ToolsAPI.pas практически невозможно, но GExpert умудряются встраивать свой тулбар в редактор, однако это опять же видимые компоненты как у Рея Лишнера.
4) EhLib понятен так как он уравнивает программиста со стажем 1 год с программистом со стажем 16 лет. Но должна же быть какая то инфраструктурная этика. EhLib это один инструмент, а технология позволяющая заменить любой внутренний интерфейс самой Delphi это другой инструмент, он для высшей касты как бы проще сказать. Сделать такой инструмент, свернуть горы, добраться до золотого берега, ради чего? Конечно же чтобы поправить циферку у даты немного.
5) Что он мне дал? Разработка таких инструментов как GExpert для меня стала в 100 раз проще, то что я накручивал, я никому не даю. Код приобретал почти абсолютную независимость от версий Delphi. По технологии ничего не менялось с 2006 го года. Только благодаря ему я узнал, что внутри Delphi существуют препоны на объявленный ToolsAPI, то есть если в хидере написаны определённые последовательности символов, то объявленный интерфейс для чтения исходника останавливается на них и ничего больше не возвращает. Приходилось схитрить. Мне открылся особенный мир не доступный тем кто не писал GExpert или подобный проект.

В итоге - мой инструментик весьма простенький 3 pas файлика, одно отличие - Вы редактируете не компонент а исходник. Конкретно Вас kaz_av, я не призываю писать инструменты ToolsAPI, но про pre-builds не пишите пожалуйста, я рассматривал и такие варианты, но все они были ужасны, гораздо ужаснее чем Ctrl+S.

Цитата:

А вот полезность хрени вставляющей дату в исходник весьма сомнительна.

Я вот сравнительно уже стар. У нас программисты отмечают свои версии последней цифрой билда. Я с трудом понимаю как они запоминают что было в 124 а что было в 136 билде. Но они же это для чего-то делают, типа мне сказали ошибку я спросил билд и понял что ошибка была исправлена позже. Я вот хочу посмотреть на них когда 2.9.5.124 сменится 3.0.0.136, потом 3.0.1.. 3.0.15, 3.1.0..3.1.4, 3.2.0 и так далее. Я уже обычно не помню чем отличается 3.1 от 3.1.3. Когда мне говорят вместо версии дату моего исходника, который я записывал и смотрел чтобы там в датах не было цифры 666, я конечно сразу вспоминаю, ага это до, а это после. То есть для меня это без сомнений полезная хрень... Закроем.

Я напоминаю - Вы же отмазались. То что:

Цитата:

Поиски показали, что имеется проблема в кодогенераторе, который дважды финализирует интерфейс. Т.к. смысла постить баг в QC не было - на XE он уже не воспроизводился - был найден воркараунд и о проблеме благополучно забыли.
И вот теперь, спустя несколько лет, ты предлагаешь мне привести для тебя воспроизводимый пример? А ты понимаешь, что баг может элементарно не воспроизвестись на голом проекте? А понимаешь, что спустя такое количество времени, я могу просто не вспомнить всех деталей?

Это никак не вяжется с Вашим же утверждением о том, что такие случаи сплошь и рядом и они происходят чаще чем в средах которые используют GC. Вы же сказали - случай распространённый, я Вас за язык не тянул. Теперь Вы боитесь что мол на голом проекте кодогенератор текст исходника поймёт по другому, чем тот же текст но не на голом проекте, тут что-то у меня вообще не укладывается. Все Ваши объекты не на голом проекте появляются только после того как кодогенератор (win32/win64) отработает и выдаст программу, как они у Вас связаны? Это же не дотнет! Просто приходится наблюдать много мути, ничего доказывающего, что Ваш случай по Вашим словам распространённый. В каком месте?

Код:

SUPPORTS_INLINE Compiler supports the inline directive (D9+/FPC)
SUPPORTS_FOR_IN Compiler supports for in loops (D9+)
SUPPORTS_GENERICS Compiler supports generic implementations (D11.NET, D12+)

D9 - это 2005
D12 - это 2009
Вы бы в своём примере на 2010 использовали бы генерики лучше. По слухам с QC генерики исправляли от багов даже во времена XE3.

Историческая справка
TWideStringField появился в D7, но не работал. В D2005 он тоже не работал. В D2006 и D2007 он работает, но нет элементов редактирования показывающих Wide а не Ansi. В D2009 появляется юникод. В D2010 мы уже видим правильные буквы. D7 доросла до D2010. А Вы, в 2005 появились енумераторы в 2006 их используете и жалуетесь на распространённость недопонимания Вас компилятором. Мне уже нечего добавить к этому "РАСПРОСТРАНЁННОМУ" случаю предлагаю закрыть.

Предлагаю продолжить про ещё один Новый Год. Хорошо это или нет друзья?
Showmessage(DateToStr(42014)) = 10.01.2015
Showmessage(DateToStr(42015)) = 11.01.2015
Кто может подсчитать, когда будет такое же совпадение с новым годом? Допускается сдвиг не более десяти дней. Сколько пройдёт столетий или тысячелетий до такого же случая?

Модерирует : ShIvADeSt
Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326