V>·>А что значит "держать данные в БД"? БД это не волшебный сундук подаренный инопланетянами, а тоже программа, и тоже написанная на ЯП. Притом есть БД написанные и на C/C++ и на Java, в этих языках почему-то 200мб без проблем дефрагментируются. А вот в .net ВНЕЗАПНО появляются сложности и надо просить помощи у native или java... место проклятое, не иначе.
V>Или непонимание или передёргивание.
Там речь шла об тесте, где корневые данные постоянное меняются и размер их составляет 200 мб. А при этом идет постоянное создание объектов порядка 200 мб в секунду.
При этом есть пример на .Net. Но нет примера на Java
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>>>В плюсах без хаков. V>·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче? V>Вопрос, надо полагать, риторический?
Ага. Ну чтоб ты задумался о сути твоей аргументации.
V>>>И без GetType. V>>>Да и большинство типов идут без таблицы виртуальных ф-ий. V>·>А моки как делаются? V>На уровне исходников или через подмену реализации в процессе линковки. V>Помнишь был такой термин — "заглушка"? V>Никакие виртуальные ф-ии для заглушки не нужны.
Это хреново, без исходников ничего не потестишь. Как скажем протестировать свой код на то как он реагирует на ошибку при закрытии файла (ofstream.close), например?
V>>>Не ужаснее описания маппинга на XML, с той разницей, что компилятор статически проверяет соответствие по крайней мере со стороны типов С++. V>·>Соответствие типов чему? V>Исходнику.
Какому исходнику? Можно пример?
V>·>Пишешь pojo-класс с нужными типами полей — он и маппится. Что ещё за описание? V>Это маппинг на структуры, считай, что не всегда удобно и вообще не является ORM, положа руку на. Массив таких структур можно считать за "типизированный рекордсет". V>Собсно, чем мне нравится низкоуровневый ORM в С++, что не происходит переливания из пустого в порожнее. В Джаве сначала драйвер заливает входной стрим в нетипизированный рекордсет, да еще боксирует простые типы. А потом ORM копирует эти данные в типизированный рекордсет. Низкоуровневый С++ маппинг заливает данные с входного стрима сразу в типизированном виде. Разница чудовищная. В обратную сторону аналогично. Отмазки насчет "SQL-сервак и так долго пашет" — херь собачья, MS SQL выдаёт данные со скоростью файловой системы — надо успевать принимать. Управляемые среды не успевают.
Просто Java ORMы обычно делают поверх JDBC (ну чтобы не реализовывать протокол взаимодействия со всеми 100500 субд). Если очень надо — можно реализовать заливку из сетевого буфера напрямую в типы, ровно так же как и в С++. Но таки да, даже скорость файловой системы порядком ниже управляемых сред. Не надо.
V>>>От способа решения задачи, т.е. от доступного инструментария в языке. V>·>Выбор способа лежит на тебе, как программисте. V>Выбор языка лежит на тебе, как программисте. А затем уже всё, особо не порыпаешься.
Это уже от твоего опыта работы с данным языком зависит.
V>·>Это называется выразительностью системы типов. Динамика это возможность менять типы объектов или систему типов в рантайм. V>Динамика, это, в первую очередь, нарушение принципа подстановки Лисков. V>Чем это грозит было уже обсосано миллион раз неглупыми опытными людьми.
Угу-угу.
V>В этом смысле принятые в Джава способы проектирования архитектуры и реализации — это антипаттерн для самой парадигмы ООП. Средняя надёжность джавовских программ после их выкатывания близка к 0-лю обычно. Глюки на глюках, падения, репорты и т.д. Зато выхода за пределы массивов нет! Вернее, в коде-то их полно...
Кем принятые? Можно ссылку на параграф JLS? Если с ссылкой затруднишься — так и быть, можешь принять другие способы проектирования, я разрешаю.
V>В общем, я в разные годы много посидел на разных джавовских программах. Должно пройти примерно лет 5 поддержки, чтобы джавовский продукт перестал глючить. Это верно для любой более-менее крупной джава-программы. Все эти JBoss когда-то, Tomcat, невероятно падучие Together и VisualAge (сейчас Eclipse) — список можно продолжать бесконечно. А ведь это ведущие джавовские продукты каждый в своё время, собсно. ))
А уж падучеть Винды... Винда явно на Java написана.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>·>Скажем, в том же Вебе — всё динамика V>Откуда?
Отовсюду.
V>·>поэтому удивительно ожидать там статических библиотек. V>Но они есть.
В java тоже.
V>·>А в Вебе как раз Плюсы чувствуют себя несколько некомфортно. V>Утверждение устарело лет на 15.
гы.
V>·>Ничем не хуже xml_root.set("person.name", "John"); V>·>И вообще плохая конструкция. Непонятно — а что если <person> может быть список? Что мы меняем? Если уж так ратуем за статику, то будь добр опиши класс: V>·>class Person {String name;} V>·>и пользуйся им, а магией конверсии в xml пусть занимается аккуратно написанный компонент. V>Дык, XmlDocument он и есть. Даешь ему схему и пусть выполняет всю "магию".
? xsd-генератор что-ли? Накой тогда динамика? Он тебе и нагенерит эти самые class Person.
EP>>>Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится. V>·>Ну пока ещё не добавили. V>Сторонних инструментов хватает.
MFC? COM?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>В плюсах без хаков. V>>·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче? V>>Вопрос, надо полагать, риторический? ·>Ага. Ну чтоб ты задумался о сути твоей аргументации.
V>>>>И без GetType. V>>>>Да и большинство типов идут без таблицы виртуальных ф-ий. V>>·>А моки как делаются? V>>На уровне исходников или через подмену реализации в процессе линковки. V>>Помнишь был такой термин — "заглушка"? V>>Никакие виртуальные ф-ии для заглушки не нужны. ·>Это хреново, без исходников ничего не потестишь. Как скажем протестировать свой код на то как он реагирует на ошибку при закрытии файла (ofstream.close), например?
V>>>>Не ужаснее описания маппинга на XML, с той разницей, что компилятор статически проверяет соответствие по крайней мере со стороны типов С++. V>>·>Соответствие типов чему? V>>Исходнику. ·>Какому исходнику? Можно пример?
V>>Собсно, чем мне нравится низкоуровневый ORM в С++, что не происходит переливания из пустого в порожнее. В Джаве сначала драйвер заливает входной стрим в нетипизированный рекордсет, да еще боксирует простые типы. А потом ORM копирует эти данные в типизированный рекордсет. Низкоуровневый С++ маппинг заливает данные с входного стрима сразу в типизированном виде. Разница чудовищная. В обратную сторону аналогично. Отмазки насчет "SQL-сервак и так долго пашет" — херь собачья, MS SQL выдаёт данные со скоростью файловой системы — надо успевать принимать. Управляемые среды не успевают. ·>Просто Java ORMы обычно делают поверх JDBC (ну чтобы не реализовывать протокол взаимодействия со всеми 100500 субд). Если очень надо — можно реализовать заливку из сетевого буфера напрямую в типы, ровно так же как и в С++. Но таки да, даже скорость файловой системы порядком ниже управляемых сред. Не надо.
V>>>>От способа решения задачи, т.е. от доступного инструментария в языке. V>>·>Выбор способа лежит на тебе, как программисте. V>>Выбор языка лежит на тебе, как программисте. А затем уже всё, особо не порыпаешься. ·>Это уже от твоего опыта работы с данным языком зависит.
V>>·>Это называется выразительностью системы типов. Динамика это возможность менять типы объектов или систему типов в рантайм. V>>Динамика, это, в первую очередь, нарушение принципа подстановки Лисков. V>>Чем это грозит было уже обсосано миллион раз неглупыми опытными людьми. ·>Угу-угу.
V>>В этом смысле принятые в Джава способы проектирования архитектуры и реализации — это антипаттерн для самой парадигмы ООП. Средняя надёжность джавовских программ после их выкатывания близка к 0-лю обычно. Глюки на глюках, падения, репорты и т.д. Зато выхода за пределы массивов нет! Вернее, в коде-то их полно... ·>Кем принятые? Можно ссылку на параграф JLS? Если с ссылкой затруднишься — так и быть, можешь принять другие способы проектирования, я разрешаю.
public void notifyObservers(Object arg)
V>>В общем, я в разные годы много посидел на разных джавовских программах. Должно пройти примерно лет 5 поддержки, чтобы джавовский продукт перестал глючить. Это верно для любой более-менее крупной джава-программы. Все эти JBoss когда-то, Tomcat, невероятно падучие Together и VisualAge (сейчас Eclipse) — список можно продолжать бесконечно. А ведь это ведущие джавовские продукты каждый в своё время, собсно. )) ·>А уж падучеть Винды... Винда явно на Java написана.
WinNT не была падучей. Ветка 95-й падала из-за сознательно ухудшенной изоляции IO (например, можно было прямо в COM-порт писать из юзверского кольца), чтобы ДОС-бокс быстро работал.
В более поздних виндах падали левые дрова обычно, почему и ввели их подпись.
Ну и сравнить кол-во кода в виндах и в указанных джавовских программах. По-идее, винды должны были падать каждые пару минут работы, а почему-то было ровно наоборот — эти джавовские проги падали намного чаще чем винды, на которых они исполнялись.
Здравствуйте, ·, Вы писали:
S>> Ну вот тебе на это кстати vdimas приводит примеры. ·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.
Здравствуйте, vdimas, Вы писали:
V>·>И как это всё вообще относится к нашему разговору? V>·>Напомню: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"". V>Именно так.
Ссылочку плиз.
V>·>Ты имеешь в виду off-heap хранилища что-ли? V>Я имею ввиду обычную кучу, вне кучи GC.
Нет никаких "обычных куч" в Яве. Есть только Java Heap. И все объекты живут именно там, независимо от размера.
Бывает off-heap подход, но это не об объектах и их размерах, а по сути это просто in memory database. И off-heap как раз используется для хранения данных огромного кол-ва _мелких_ объектов.
V>Чем куча GC отличается от обычной?
Откуда я знаю что такое "обычная куча", этот термин ты придумал. Скажем, в zing куча операционки может не использоваться, и там есть ядрённый модуль, который выделяет Java-кучу прямо в физической памяти.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Ок. Подытож двумя словами: Что является результатом работы JIT? Что является результатом работы AOT?
S>>·>И ещё попробуй понять как из приведённой тобой информации можно сделать вывод, что "JIT не сильно оптимизирующий компилятор"? S>> Ты С++ приложения компилировал? Какова скорость компиляции? ·>Ты мне предлагаешь по скорости компилятора судить о качестве оптимизации??! ·>Пиши тогда на Скале, у неё тоже медленный компилятор.
Ну ты вроде тут соглашался про оптимизации SIMD и прочими оптимизациями. S>>>> Значит я тебя понять не могу. NGEN ускоряет загрузку приложения. Будешь с эти спорить? S>>·>Да, может ускорять. Дальше что? Как это влияет на жизнь батареи в типичном юзкейсе? S>> Быстрее запуск, значит меньше затрат на компиляцию. Некоторые приложения грузятся минутами. S>> Опять же JIT оптимизатор на мобильных устройствах будет жрать энергию еще и во время выполнения. ·>ART это AOT, а не JIT. dalvik был с JIT, но его заменили на ART.
Мы вроде говорим об отм, что предварительная компиляция экономит батарею?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>·>Есть ли БД написанные на .net? Если нет, то почему? V>RavenDB, к примеру.
С пачками unsafe.
V>Ну а сообще это бред, как по мне. V>.Net изначально ориентировано на интероп/гетерогенность. V>Молоток плохо заменяет плоскогубцы и обратно тоже верно.
Я не против интеропа, я против сравнения производительности java с "гетероненностью". Т.е. не надо говорить, что dotnet производительнее java основываясь на результатах сравнения нативного кода с java.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
S>>> Ну вот тебе на это кстати vdimas приводит примеры. V>·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++. V>Ссылка? dotnet vs java 2016-2020
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>> Ты С++ приложения компилировал? Какова скорость компиляции? S>·>Ты мне предлагаешь по скорости компилятора судить о качестве оптимизации??! S>·>Пиши тогда на Скале, у неё тоже медленный компилятор. S> Ну ты вроде тут соглашался про оптимизации SIMD и прочими оптимизациями.
SIMD на мобильниках?? Бывает разве?
S>>> Быстрее запуск, значит меньше затрат на компиляцию. Некоторые приложения грузятся минутами. S>>> Опять же JIT оптимизатор на мобильных устройствах будет жрать энергию еще и во время выполнения. S>·>ART это AOT, а не JIT. dalvik был с JIT, но его заменили на ART. S> Мы вроде говорим об отм, что предварительная компиляция экономит батарею?
Мы вроде говорим о том, что экономия батареи не означает запрет на компиляцию в нативный код самом на девайсе. Что вовсе не обязательно апп-магазину распространять непосредственно нативный код как ты предлагаешь с .net native.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
EP>>>Речь как раз о том, что в разных языках различные по удобству средства выражения статики. В некоторых, типа Python — и вовсе сплошная динамика. В других же типа Java — есть статика, но акцент смещён в сторону динамики. В третьих сильная статика — например C++, D, Nemerle. I>·>Интересная классификация. А C куда отнесёшь? I>В Cи зависит от того, какой код пишешь
Ок. А почему в С++ вдруг перестаёт зависеть?
I> переменная принимает значения разных типов — динамический, фактически, тип связан со значением и компилером не проверяется I> пишешь так, что значения только правильных типов — статический, здесь тип связан с переменной и проверяется компилятором I> Если раскладываешь всякие касты, то получается своего рода мягкая система типов, ни статика, ни динамика.
И чем это отличается от Java? Или шарпа? Или плюсов?
I>·>Касты не означают динамику, каст это приведение типов. I>Все зависит от того, какой тип компилятор предпочитает по дефолту. Иногда это object(any и тд), иногда — точный(string, List). Когда первое, это динамика. Когда второе — статика.
Что такое "предпочтение компилятора"? Можно ссылочку на language specification?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>В целом изжержки на джыт вполне осязаемы. Обычно джыт идет где то в первых трех позициях по расходу процессора и памяти, если верить профайлеру. Издержки меньше, чем от ГЦ, но тем не менее заметные.
Я знаю, поэтому dalvik и заменили на ART.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> Ты С++ приложения компилировал? Какова скорость компиляции? S>>·>Ты мне предлагаешь по скорости компилятора судить о качестве оптимизации??! S>>·>Пиши тогда на Скале, у неё тоже медленный компилятор. S>> Ну ты вроде тут соглашался про оптимизации SIMD и прочими оптимизациями. ·>SIMD на мобильниках?? Бывает разве?
Появятся. https://habrahabr.ru/post/153015/ S>>>> Быстрее запуск, значит меньше затрат на компиляцию. Некоторые приложения грузятся минутами. S>>>> Опять же JIT оптимизатор на мобильных устройствах будет жрать энергию еще и во время выполнения. S>>·>ART это AOT, а не JIT. dalvik был с JIT, но его заменили на ART. S>> Мы вроде говорим об отм, что предварительная компиляция экономит батарею? ·>Мы вроде говорим о том, что экономия батареи не означает запрет на компиляцию в нативный код самом на девайсе. Что вовсе не обязательно апп-магазину распространять непосредственно нативный код как ты предлагаешь с .net native.
Тогда я тебя не понял. Я говорю о том, что нативный код уменьшает время потребления энергии за счет уменьшения времени загрузки и скорости работы за счет уменьшения косвенности (инлайнинг) и Большей оптимизации нативного кода за счет использования оптимизирующих компиляторов. Кроме того например для .Net Native не нужна среда CLR, а значит и её не нужно загружать и она не расходует ресурсы
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
V>>·>Скажем, в том же Вебе — всё динамика V>>Откуда? ·>Отовсюду.
Т.е. нет там никакой динамики.
Бывают скриптовые динамические языки, но сама задача никакой динамикой не пахнет и близко.
V>>·>поэтому удивительно ожидать там статических библиотек. V>>Но они есть. ·>В java тоже.
Сам с собой споришь уже.
V>>·>А в Вебе как раз Плюсы чувствуют себя несколько некомфортно. V>>Утверждение устарело лет на 15. ·>гы.
То-то.
V>>·>и пользуйся им, а магией конверсии в xml пусть занимается аккуратно написанный компонент. V>>Дык, XmlDocument он и есть. Даешь ему схему и пусть выполняет всю "магию". ·>? xsd-генератор что-ли? Накой тогда динамика? Он тебе и нагенерит эти самые class Person.
Зачем?
EP>>>>Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится. V>>·>Ну пока ещё не добавили. V>>Сторонних инструментов хватает. ·>MFC? COM?
Здравствуйте, ·, Вы писали:
V>>·>И как это всё вообще относится к нашему разговору? V>>·>Напомню: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"". V>>Именно так. ·>Ссылочку плиз.
The maximum size of an object HotSpot JVM may allocate in young generation is nearly as large as the size of Eden (YoungGen minus two Survivor spaces).
За пределами этого размера (на самом деле задолго до этого размера) объект выделяется в обычной куче и отправляется сразу во 2-е поколение (Old generation в терминах Джавы).
V>>·>Ты имеешь в виду off-heap хранилища что-ли? V>>Я имею ввиду обычную кучу, вне кучи GC. ·>Нет никаких "обычных куч" в Яве. Есть только Java Heap. И все объекты живут именно там, независимо от размера.
Это не так.
·>Бывает off-heap подход, но это не об объектах и их размерах, а по сути это просто in memory database. И off-heap как раз используется для хранения данных огромного кол-ва _мелких_ объектов. V>>Чем куча GC отличается от обычной? ·>Откуда я знаю что такое "обычная куча", этот термин ты придумал.
Этому термину больше лет чем тебе.
·>Скажем, в zing куча операционки может не использоваться, и там есть ядрённый модуль, который выделяет Java-кучу прямо в физической памяти.
А бывает как-то иначе? ))
Ясно, понятий ровно ноль.
В обычной куче есть только две операции — выделение и освобождение памяти.
В куче GC дополнительно есть операции перемещения объектов, с целью уплотнения (дефрагментации).
Так вот, основной профит от GC как раз в этой дефрагментации, иначе не получится затем выделять память простым инкрементом указателя. Но эта фишка не работает для больших объектов, бо они выделяются в тех областях памяти, где дефрагментация не производится.
Здравствуйте, ·, Вы писали:
V>>·>Есть ли БД написанные на .net? Если нет, то почему? V>>RavenDB, к примеру. ·>С пачками unsafe.
Ссылку?
·>Я не против интеропа, я против сравнения производительности java с "гетероненностью". Т.е. не надо говорить, что dotnet производительнее java основываясь на результатах сравнения нативного кода с java.
Нет ты именно против, потому что переворачиваешь всё с ног на голову, насилуя банальную логику.
Обильное наличие интеропа в дотнете НЕ является показателем тормознутости дотнета, оно является показателем только лишь низкой трудоёмкости сопряжения дотнета с нейтивом, что только в плюс этой технологии.
И твоё внимание уже не раз обращали на твои погрешности рассуждений, но ты упорно продолжаешь насиловать логический аппарат коллег.
Здравствуйте, ·, Вы писали:
S>>>> Ну вот тебе на это кстати vdimas приводит примеры. V>>·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++. V>>Ссылка? ·>dotnet vs java 2016-2020
Продолжаем врать?
Я НЕ приводил этот пример. Это ты нарыл рекламную строчку и по-своему интерпретировал.
Свои цифры я приводил — 4-6 мкс для нейтива и более 120 мкс по Джаве.
А вот твоих по Джаве так и не дождался.
Так шта, поздравляю соврамши.
И да.
Посмотри картинки — синие линии на них это cheetah и b2bits — они примерно одинаково расположены.
Во-первых, не одинаково, а с разницей в полтора раза.
Во-вторых, на тех графиках Rapid vs b2bits и оба они нейтивные, безо всякой Джавы.
Здравствуйте, ·, Вы писали:
I>>·>Интересная классификация. А C куда отнесёшь? I>>В Cи зависит от того, какой код пишешь ·>Ок. А почему в С++ вдруг перестаёт зависеть?
Смотря что ты называешь плюсами. Там реально три разных языка — Си, собственно плюсы и шаблоны. Одна и та же задача решается в этих трех языках по разному. В си норма использовать void* а вот в плюсах это идея так себе, в шаблонах такое в своем уме вообще не пишут.
I>> переменная принимает значения разных типов — динамический, фактически, тип связан со значением и компилером не проверяется I>> пишешь так, что значения только правильных типов — статический, здесь тип связан с переменной и проверяется компилятором I>> Если раскладываешь всякие касты, то получается своего рода мягкая система типов, ни статика, ни динамика. ·>И чем это отличается от Java? Или шарпа? Или плюсов?
I>>·>Касты не означают динамику, каст это приведение типов. I>>Все зависит от того, какой тип компилятор предпочитает по дефолту. Иногда это object(any и тд), иногда — точный(string, List). Когда первое, это динамика. Когда второе — статика. ·>Что такое "предпочтение компилятора"? Можно ссылочку на language specification?
Очень просто
def (a) { return ... }
тип переменной a будет или точным или нет. Это вроде бы и вывод типа,но с другой стороны, вывод типа может выдать тебе <any> если не найдет ничего точного. Опаньки !
Вернее, в коде-то их полно...
