kaz_av
Цитата:
да ну?
Цитата:
если это не сравнение, то что?
Я показал, что такой случай не показателен для действительно критического к производительности приложения.
Там если и есть преимущество, то только в весьма ограниченных рамках, и только потому, что работа с памятью вынесена в отдельный поток, потребляющий ресурсы дополнительно, а самой памяти нужно вдвое больше, чем дельфийскому или "плюсовому" приложению.
Сам GC концептуально и фактически медленнее ручного управления. Он дает большую безопасность, запрашивая при этом значительную цену.
Цитата:
Думаю, ты сделал что-то неправильно. Ну или оксиджен тупит.
Цитата:
ничего не понял...
Для Delphi это ограничение никак не сказывается: она и на 400 тысячах элементов не перекрывает в потреблении 400 метров.
Ну а своп JVM ее бы только замедлил.
Я смоделировал ситуацию ограниченных ресурсов, потому что ресурсы всегда ограничены.
И показал, что когда масштаб задачи подбирается, хотя бы даже и не вплотную, к потолку ресурсов системы, JVM sucks, тупит и лагает.
Какое же это читерство?
Мои выкладки, в отличие от твоих "впечатлений" и "случаев", объективны: я показал и превосходство JVM в одних случаях, и ее недостатки -- в других.
И сделал взвешенный, беспристрастный вывод -- Java малопригодна для случаев, когда теоретический размер и сложность задачи близок к актуальному пределу железа.
Пять лет назад оптимисты сказали бы: "ну и что, железо удваивает мощность каждые два-три года". Сегодня -- мы уже знаем, что это не работает. Производительность на такт, на ватт, на гигабайт памяти -- снова приобретает значимость.
И тут managed языкам приходится кисло.
Цитата:
между обвинениями и оскорблениями есть разница. Жаль, что ты этого не улавливаешь.
Я поначалу думал, что ты просто заблуждаешься, когда ставить вровень managed языки и натив. Тогда я потратил время(это вообще первое мое приложение под java, так что усилие было значительным), и написал тестовое приложение на Java, аналогичное твоему.
Оптимизировал его: слачала ввел статический StringBuilder, а потом увеличил размер пула "молодых" объектов.
Каждый из этих двух шагов дает практически двукраное ускорение. Далее, провел исследование, достаточное, наверное, даже для статейки на хабре, выложил код. Показал силу и слабость JVM.
И тут ты начинаешь лепить отмазки: мол, "я только говорил о скорости, а о памяти ничего не говорил"... Что якобы я поставил JVM в "невыгодные условия", хотя условия для JVM были равными или превосходили условия для Delphi.
То есть ты упорствуешь, и говоришь как фанатик или евангелист managed языков, который игнорирует все недостатки парадигмы, но выпячивает их преимущества.
И это здесь, в ветке Delphi! Не в моих правилах такое терпеть.
Цитата:
Конечно, не всегда. Если уж подсчет ссылок съедает до 5 процентов, то что говорить о GC? А ведь ты назвал эти пять процентов "адовым замедлением". Блин, это ли не двойные стандарты?
Напротив, все твои последние высказывания о managed коде были в неестественно светлых тонах. Случай, когда GC потребляет доли процента процессорного времени -- не правило, а исключение. Случай, когда JVM быстрее Delphi работает со строками, тоже нетипичен и не применим к случаю, когда скорость важна, и работа со строками действительно должна вестись максимально быстро.
А из твоих постов неокрепший ум мог сделать заключение, что managed код имеет лишь незначительные недостатки, обладая при этом огромными преимуществами.
Повторюсь, не здесь, не в ветке Delphi, не на моих глазах может это происходить без моей реакции.
Цитата:
ты слишком много говорил о достоинствах, не упоминая недостатки. Получается однобоко.
Цитата:
тест был предложен тобой. Я лишь оформил и формализивал его, чтобы он был репрезентативен. Тест не на сферическом железе в вакууме, а на железе, адекватном задаче.
Твои же "нормальные условия" известны: почти двойное потребление памяти в managed коде, и значительная нагрузка на процессор в фоновом потоке. Однопоточная задача на минимум двухпоточном процессоре, чтобы обеспечить ресурсами сборщик мусора. Если бы ты был объективен, то сразу же упомянул это.
Цитата:
Если нет существенного прироста по кэшу, то зачем писать это "cache friendly"? Зачем это маркетинговый буллшит?
Цитата:
Цитата:
Другое дело, что новичка именно такие нечастые случаи могут довести до отчаянья, да и опытный программист поимеет нехилый геморрой с ними.
Да, в нашем лесу встречаются волки. Да, новичок не сможет писать на нативном языке сложные программы, без помощи сеньора, пока сам пару-тройку лет не походит по этому лесу.
Managed код дает дает более быстрый старт. В этой роще безопаснее, но она невелика, она огорожена, и лут в ней только тот, что одобрен ее хозяевами.
Дети, играйте в ней, но не смейте утверждать, что это и есть весь мир. Что в лес вообще не стоит выходить, потому что там волки и медведи с пустыми черными глазами. Подрастайте, и набирайтесь мужества.
Добавлено:
xpin2013
Цитата:
хм, интересно.. Прежде не встречался.
Описание, на мой взгляд, довольно сумбурное, и непонятно, какова киллер-фича у этого проекта?
Вот я использую sqlite+mormot без DataSet обвязки. Думаю, это очень быстро, и при этом -- sqlite -- стандарт де-факто, а ориентация на SQL привносит возможможности масштабирования. А у вас что?
Я вижу, что в ваш проект вложены существенные усилия, но не понимаю, ради чего они..
Добавлено:
----
из-за тестов с явой я стал подозревать, что скорость работы любой, даже однопоточной Delphi программы, может быть увеличена за счет асинхронной работы с кучей.
Аллокацию без ожидания в отдельном потоке реализовать сложно, но вот освобождение памяти, можно сделать отложенным. Когда исполняемый поток лишь вносит объект в список на удаление, а специальный, выделенный поток , освобождает память из списка..
Это ускорит каждую функцию, в которой есть переменные управляемых типов, за счет экономии времени в эпилоге.
Это снизит затраты на блокировки в основных, пользовательских исполняемых нитях, когда блокировка происходит по причине освобождения ресурсов.
Да и насчет аллокации: почему бы не держать, с десяток, а то и сотню преаллоцированных буферов различных размеров под распространенные типы.
То есть в дополнение к уже существующему пулам small objects, добавить дежурный, либо даже ассоциированный с потоком пул, пополняемый по мере нужды, хотя тут я не уверен, что это ускорит программу.
Цитата:
Я вообще не предлагал ни каких сравнений, я рассказал о случае из практики
да ну?
Цитата:
Лично наблюдал, как код на жабе делающий огромное количество операций со строками драл аналогичный дельфийский и плюсовый код. Для паритета и на дельфях и на плюсах пришлось пользоваться собственным аллокатором под задачу
если это не сравнение, то что?
Я показал, что такой случай не показателен для действительно критического к производительности приложения.
Там если и есть преимущество, то только в весьма ограниченных рамках, и только потому, что работа с памятью вынесена в отдельный поток, потребляющий ресурсы дополнительно, а самой памяти нужно вдвое больше, чем дельфийскому или "плюсовому" приложению.
Сам 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
Цитата:
http://sourceforge.net/p/vdbi/home/Home/
хм, интересно.. Прежде не встречался.
Описание, на мой взгляд, довольно сумбурное, и непонятно, какова киллер-фича у этого проекта?
Вот я использую sqlite+mormot без DataSet обвязки. Думаю, это очень быстро, и при этом -- sqlite -- стандарт де-факто, а ориентация на SQL привносит возможможности масштабирования. А у вас что?
Я вижу, что в ваш проект вложены существенные усилия, но не понимаю, ради чего они..
Добавлено:
----
из-за тестов с явой я стал подозревать, что скорость работы любой, даже однопоточной Delphi программы, может быть увеличена за счет асинхронной работы с кучей.
Аллокацию без ожидания в отдельном потоке реализовать сложно, но вот освобождение памяти, можно сделать отложенным. Когда исполняемый поток лишь вносит объект в список на удаление, а специальный, выделенный поток , освобождает память из списка..
Это ускорит каждую функцию, в которой есть переменные управляемых типов, за счет экономии времени в эпилоге.
Это снизит затраты на блокировки в основных, пользовательских исполняемых нитях, когда блокировка происходит по причине освобождения ресурсов.
Да и насчет аллокации: почему бы не держать, с десяток, а то и сотню преаллоцированных буферов различных размеров под распространенные типы.
То есть в дополнение к уже существующему пулам small objects, добавить дежурный, либо даже ассоциированный с потоком пул, пополняемый по мере нужды, хотя тут я не уверен, что это ускорит программу.
Но предупреждаю, какие то косяки ещё есть и в XE7.
ога. Они ещё скажут что преобразование Integer(Pointer(String(S))):=0 грубая ошибка, хотя этим трюком пользовался стринглист и описывалось в каждом учебнике как уловка. Ну надо же грубая ошибка которую я исправил с помощью Current:=''. Это же нарушение, это хаккерство какое-то.