AlekXL
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
kaz_av
Цитата:| Я вообще не предлагал ни каких сравнений, я рассказал о случае из практики |
да ну?
Цитата:| Лично наблюдал, как код на жабе делающий огромное количество операций со строками драл аналогичный дельфийский и плюсовый код. Для паритета и на дельфях и на плюсах пришлось пользоваться собственным аллокатором под задачу |
если это не сравнение, то что?
Я показал, что такой случай не показателен для действительно критического к производительности приложения.
Там если и есть преимущество, то только в весьма ограниченных рамках, и только потому, что работа с памятью вынесена в отдельный поток, потребляющий ресурсы дополнительно, а самой памяти нужно вдвое больше, чем дельфийскому или "плюсовому" приложению.
Сам GC концептуально и фактически медленнее ручного управления. Он дает большую безопасность, запрашивая при этом значительную цену.
Цитата:| Мой первоначальный оксидженовский код, будучи переписаным на использование статического стрингбилдера работает медленнее |
Думаю, ты сделал что-то неправильно. Ну или оксиджен тупит.
Цитата:| Ты её не ограничил, а дал столько, чтоб при таком количестве данных система тебя в своп не загнала. А вот потребность GC ты ограничил. Это читерство в чистом виде. |
ничего не понял...
Для Delphi это ограничение никак не сказывается: она и на 400 тысячах элементов не перекрывает в потреблении 400 метров.
Ну а своп JVM ее бы только замедлил.
Я смоделировал ситуацию ограниченных ресурсов, потому что ресурсы всегда ограничены.
И показал, что когда масштаб задачи подбирается, хотя бы даже и не вплотную, к потолку ресурсов системы, JVM sucks, тупит и лагает.
Какое же это читерство?
Мои выкладки, в отличие от твоих "впечатлений" и "случаев", объективны: я показал и превосходство JVM в одних случаях, и ее недостатки -- в других.
И сделал взвешенный, беспристрастный вывод -- Java малопригодна для случаев, когда теоретический размер и сложность задачи близок к актуальному пределу железа.
Пять лет назад оптимисты сказали бы: "ну и что, железо удваивает мощность каждые два-три года". Сегодня -- мы уже знаем, что это не работает. Производительность на такт, на ватт, на гигабайт памяти -- снова приобретает значимость.
И тут managed языкам приходится кисло.
Цитата:| Ты же перешел от любезностей к обвинениям, с чего мне себя сдерживать? |
между обвинениями и оскорблениями есть разница. Жаль, что ты этого не улавливаешь.
Я поначалу думал, что ты просто заблуждаешься, когда ставить вровень managed языки и натив. Тогда я потратил время(это вообще первое мое приложение под java, так что усилие было значительным), и написал тестовое приложение на Java, аналогичное твоему.
Оптимизировал его: слачала ввел статический StringBuilder, а потом увеличил размер пула "молодых" объектов.
Каждый из этих двух шагов дает практически двукраное ускорение. Далее, провел исследование, достаточное, наверное, даже для статейки на хабре, выложил код. Показал силу и слабость JVM.
И тут ты начинаешь лепить отмазки: мол, "я только говорил о скорости, а о памяти ничего не говорил"... Что якобы я поставил JVM в "невыгодные условия", хотя условия для JVM были равными или превосходили условия для Delphi.
То есть ты упорствуешь, и говоришь как фанатик или евангелист managed языков, который игнорирует все недостатки парадигмы, но выпячивает их преимущества.
И это здесь, в ветке Delphi! Не в моих правилах такое терпеть.
Цитата: Цитата:
Всё от ситуации зависит, когда я мониторил одну софтину там GC кушал сотые доли процента.
Если ты не понял, это совсем не означает, что GC всегда будет кушать сотые доли процента. |
Конечно, не всегда. Если уж подсчет ссылок съедает до 5 процентов, то что говорить о GC? А ведь ты назвал эти пять процентов "адовым замедлением". Блин, это ли не двойные стандарты?
Напротив, все твои последние высказывания о managed коде были в неестественно светлых тонах. Случай, когда GC потребляет доли процента процессорного времени -- не правило, а исключение. Случай, когда JVM быстрее Delphi работает со строками, тоже нетипичен и не применим к случаю, когда скорость важна, и работа со строками действительно должна вестись максимально быстро.
А из твоих постов неокрепший ум мог сделать заключение, что managed код имеет лишь незначительные недостатки, обладая при этом огромными преимуществами.
Повторюсь, не здесь, не в ветке Delphi, не на моих глазах может это происходить без моей реакции.
Цитата:| Я ни разу не сказал, что GC не требователен к памяти. Речь была о скорости работы. |
ты слишком много говорил о достоинствах, не упоминая недостатки. Получается однобоко.
Цитата:| Эти выводы сделаны тобой из некорректных тестов. В нормальных условиях GC безусловно быстрей. |
тест был предложен тобой. Я лишь оформил и формализивал его, чтобы он был репрезентативен. Тест не на сферическом железе в вакууме, а на железе, адекватном задаче.
Твои же "нормальные условия" известны: почти двойное потребление памяти в managed коде, и значительная нагрузка на процессор в фоновом потоке. Однопоточная задача на минимум двухпоточном процессоре, чтобы обеспечить ресурсами сборщик мусора. Если бы ты был объективен, то сразу же упомянул это.
Цитата:| Опять вранье. Я говорил, что "GC более cache friendly", ты мне приписываешь "существенно оптимальнее". |
В чем же разница между "cache friendly" и "существенно оптимальнее"?
Если нет существенного прироста по кэшу, то зачем писать это "cache friendly"? Зачем это маркетинговый буллшит?
Цитата:| С такими методами ведения дискуссий, проследуй-ка ты родной в пень |
все, кто читает это, видят и мои, и твои методы ведения дискуссии. Им судить. Это и есть моя цель. Не выиграть в споре, а внести полную ясность, без умолчаний, для чтобы читающие эту дискуссию могли составить свое суждение.
Цитата:| И снова вранье. Я сказал, что порча буферов, да и не только буферов, это обычная ситуация для натива. |
Это не так. Сложные, трудно диагностируемые ситуации, достаточно редки.
Другое дело, что новичка именно такие нечастые случаи могут довести до отчаянья, да и опытный программист поимеет нехилый геморрой с ними.
Да, в нашем лесу встречаются волки. Да, новичок не сможет писать на нативном языке сложные программы, без помощи сеньора, пока сам пару-тройку лет не походит по этому лесу.
Managed код дает дает более быстрый старт. В этой роще безопаснее, но она невелика, она огорожена, и лут в ней только тот, что одобрен ее хозяевами.
Дети, играйте в ней, но не смейте утверждать, что это и есть весь мир. Что в лес вообще не стоит выходить, потому что там волки и медведи с пустыми черными глазами. Подрастайте, и набирайтесь мужества.
Добавлено:
xpin2013
Цитата:
хм, интересно.. Прежде не встречался.
Описание, на мой взгляд, довольно сумбурное, и непонятно, какова киллер-фича у этого проекта?
Вот я использую sqlite+mormot без DataSet обвязки. Думаю, это очень быстро, и при этом -- sqlite -- стандарт де-факто, а ориентация на SQL привносит возможможности масштабирования. А у вас что?
Я вижу, что в ваш проект вложены существенные усилия, но не понимаю, ради чего они..
Добавлено:
----
из-за тестов с явой я стал подозревать, что скорость работы любой, даже однопоточной Delphi программы, может быть увеличена за счет асинхронной работы с кучей.
Аллокацию без ожидания в отдельном потоке реализовать сложно, но вот освобождение памяти, можно сделать отложенным. Когда исполняемый поток лишь вносит объект в список на удаление, а специальный, выделенный поток , освобождает память из списка..
Это ускорит каждую функцию, в которой есть переменные управляемых типов, за счет экономии времени в эпилоге.
Это снизит затраты на блокировки в основных, пользовательских исполняемых нитях, когда блокировка происходит по причине освобождения ресурсов.
Да и насчет аллокации: почему бы не держать, с десяток, а то и сотню преаллоцированных буферов различных размеров под распространенные типы.
То есть в дополнение к уже существующему пулам small objects, добавить дежурный, либо даже ассоциированный с потоком пул, пополняемый по мере нужды, хотя тут я не уверен, что это ускорит программу. |
Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 22:31 09-01-2015 | Исправлено: AlekXL, 22:44 09-01-2015 |
|
