Здравствуйте, ·, Вы писали:
·>Здравствуйте, vdimas, Вы писали:
V>>·>Ну собственно намёк был в том, что твоя гениальная оптимизация пулами аллокаторов уже есть в gc. V>>Намек был на твоё полное невладение предметом, вообще-то. V>>Сорри, намек ты не понял, поэтому пришлось написать явно. ·>Ничего себе! Сочувствую. Было не очень больно? Может ты пиши всегда прямо писать будешь, а не намёками, мы не на свидании, вроде как.
Человек, который смело так берется рассуждать о Джаве в общем, на мой взгляд, должен быть достаточно подкован в подробностях её механики. Вот я и подумал, что ты прекрасно в курсе, как в Джаве выделяются объекты большого размера.
V>>Ну конечно, в GC такой оптимизации нет, т.к. процесс освобождения памяти крайне дорогой. ·>Так я ж пишу — TLAB такая оптимизация и есть — тред использует свою персональную память по возможности.
Этим улучшается локальность, но не получается избежать стандартного пробега по ссылочному графу.
V>>·>Чем оправдываешь переизобретение велосипеда? V>>Технологии современного велосипеда меняются приблизительно каждые 5 лет. ·>И что в аллокаторах поменялось 5 лет назад?
Новые реализации выходят, библиотеки/инфраструктуры для дешевой разработки своих и т.д.
Даже твой GC — это тоже разновидность аллокатора.
·>Что такое "Куча GC"
Что такое GC?
V>>·>И что такое "честный образ"? V>>Это обычный аллокатор. ·>Что такое "обычный аллокатор" в java?
Это который такой же как для любой нейтивной программы.
Здравствуйте, ·, Вы писали:
V>>·>А что мне помешает, передать, например, ссылку/указатель на элемент вектора куда-нибудь? V>>Ну тебе же ничто не помешало скипнуть заранее данный ответ на этот вопрос: V>>
V>>Такая техника работает для любых пользовательских типов в т.ч.
·>Что мне запрещает создать экземпляр пользовательского типа с другим аллокатором, содержащий ссылку на элемент массива?
Такая техника работает для любых пользовательских типов в т.ч.
Здравствуйте, alex_public, Вы писали:
_>Да, и главное: даже если бы ты тут и указал бы что-то реально дельное (кстати та же avalonia выглядит вполне перспективно), то это всё равно не имело бы никакого отношения к тому факту, что .net core и т.п. — это огрызки полноценного .net.
Со стороны, ты воюешь с ветряными мельницами. ))
Linux интересен сугубо как серверный узел, а не клиентский. А с портируемостью серверного кода на mono уже лет 10 особых проблем нет, т.е. разговор ни о чем.
Здравствуйте, ·, Вы писали:
·>Ок, согласен, что с simd у jvm дело плохо. Может когда-нибудь научится. ·>В общем-то я не утверждал, что всегда. Ты заявил, что "в разы медленнее". Я воспринял это как "обычно в разы медленнее", а ты, видимо, имел в виду "встречаются задачи, когда в разы медленнее".
Вообще основная моя мысль была в другом — в возражение твоему тезису, что при желание любой java код можно дооптимизировать до производительности C++. Очевидно, что с любым это не пройдёт, причём даже не учитывая такие вещи как simd (сам же видел, что C++ код без simd всё равно в пару раз быстрее). В Java и т.п. языках есть принципиальные архитектурные недостатки не позволяющие этого.
·>А если ещё GPU вспомнить...
Да, кстати, openacc теперь встроено в компилятор gcc, так что тоже можно формально относить к преимуществам компилятора C++. Но мы естественно такие "читы" использовать в дискуссии не будем. )))
Здравствуйте, Serginio1, Вы писали:
I>>Тут написано, да, но на сайте techempower ничего подобно и близко нет. Ссылка с микрософтовского сайта ведет на бенчмарки, где лидирует джава
I>>UPD: 'based on preliminary internal tests'
S> Вот их бенчмарки S>https://github.com/aspnet/benchmarks
В этих тестах товарищи избегают сравниваться с Джавой. Если смотреть plaintext относительно node и scala, то выходит так, что ASP NET Core из аутсайдеров стал всего лишь середнячком.
Вообще и этот результат хорош, т.к. ускорение относительно старой версии минимум в 5 раз.
Ааа, ну так это регулярные выражения... Они в php (и во всех остальных подобных скриптовых языках) реализованы как обёртка вокруг известной вылизанной библиотеки на C. При этом в данном тесте для C и C++ они почему-то используют не готовые библиотеки, а какое самопальное решение. Так что ничего удивительного.
Здравствуйте, alex_public, Вы писали:
I>>С этими бенчмарками чтото непонятное, PHP и Node.js не просто лидируют, а рвут в говно плюсовый вариант I>>https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna
_>Ааа, ну так это регулярные выражения... Они в php (и во всех остальных подобных скриптовых языках) реализованы как обёртка вокруг известной вылизанной библиотеки на C. При этом в данном тесте для C и C++ они почему-то используют не готовые библиотеки, а какое самопальное решение. Так что ничего удивительного.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Тут написано, да, но на сайте techempower ничего подобно и близко нет. Ссылка с микрософтовского сайта ведет на бенчмарки, где лидирует джава
I>>>UPD: 'based on preliminary internal tests'
S>> Вот их бенчмарки S>>https://github.com/aspnet/benchmarks
I>В этих тестах товарищи избегают сравниваться с Джавой. Если смотреть plaintext относительно node и scala, то выходит так, что ASP NET Core из аутсайдеров стал всего лишь середнячком. I>Вообще и этот результат хорош, т.к. ускорение относительно старой версии минимум в 5 раз.
Ну если сравнивать с netty
ASP.NET Core on Kestrel perfsvr 313,001
Netty perfsvr 447,993
Отношение 1.42
https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=plaintext
cpoll_cppsp 7,059,109
100.0%(99.6%) Mcr C++ Cpl Non Lin Rea 0
fasthttp-postgresql 6,371,358
90.3%(89.9%) Plt Go Go Non Lin Rea 0
fasthttp-mysql 6,340,999
89.8%(89.4%) Plt Go Go Non Lin Rea 0
undertow edge 5,739,303
81.3%(81.0%) Plt Jav Und Non Lin Rea 0
undertow 5,659,475
80.2%(79.8%) Plt Jav Utw Non Lin Rea 0
netty 4,913,525
69.6%(69.3%) Plt Jav Nty Non Lin Rea 0
vertx 3,387,403
48.0%(47.8%) Plt Jav Nty Non Lin Rea 0
grizzly 2,434,349
34.5%(34.3%) Mcr Jav Svt Grz Lin Rea 0
servlet-dsl 2,421,539
34.3%(34.2%) Plt Jav Svt Res Lin Rea 0
servlet3-cass 2,314,918
32.8%(32.7%)
То сравнение с servlet 2.
То есть .Net Core быстрее servlet
Хотя я не знаю где там ява.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>·>Какой динамикой? Ты о чём? Почитай учебники что-ли, хоть ту же вики: V>Почитай лучше реальный код или АПИ всевозможных джавовских фреймворков (системных и прикладных), поверх которых вы всё там рисуете.
Читал. И что?
V>·>Ты первый начал чушь пороть. V>Не кипишуй, это не чушь, это реальный расклад.
Ок. Просто твоё мнение, или понимание терминов.
V>·>Но я хоть что-то похожее на аргументы привёл. V>Я тебе предлагал исходниками обменяться. Ты отказался. Потому единственно, что ты можешь защищать — это собственный код. А если брать любой открытый джавовский — так я и вовсе сразу победил, потому что тысячу раз прав. Единственный тут тонкий момент — ты можешь продолжать утверждать, что у вас не так.
Ок. Ну возьмём любой проект, скажем disruptor. Где там динамика? Для чего там она? Как бы оно было в Плюсах? И в чём бы оно было лучше?
V>·>А вот ещё: DYNAMIC_DOWNCAST V>Это макрос для убожества MFC от 90-го года разработки.
Никогда не отмоетесь! Вечное проклятье! Му-ха-ха!
V>Покажешь мне проекты новее 2000-го года на MFC?
Щаз возьму и напишу cd ejector. Шах и мат!
V>·>Доказать-то сможшешь, что java — динамический? V>Да любым фреймворком, тем же Spring. Неужели ты никогда не пользовался Spring?
Я уже завязал.
V>Или взять абсолютно любые провайдеры зависимостей (их часто зовут IoC-контейнерами, что само по себе неграмотно, кста).
Если тебе интересно моё мнение об этих фреймворках... был тут флейм недавно: http://rsdn.org/forum/design/6512200.all
V>Или взять абсолютно любые провайдера JPA и т.д.
Так ты не бери.
V>Везде в основе лежат даункасты и динамика.
Потому что могут, а не потому что надо. В плюсах такого просто нет. Вот и лезут DYNAMIC_DOWNCAST и прочий макро-ужас.
V>>>Имелась ввиду статическая типизация. V>·>предложение "Потому что статической типизации исходника несопоставим от слова совсем." тоже смысла не имеет. Что сказать-то хочешь? V>С этой поправкой имеет. Хотя, я уверен, из контекста был понятен и первоначальный вариант. V>Представь на минуту, что в Джава вообще запретили динамическое приведение типов. Ну вот включи воображение. Всё, с этого момента такой операции тупо нет в JVM. Вот как ты будешь писать код?
Да те же хаки как и в плюсах — виртуальный GetType или хитроумные макросы, сам же мне C++ ORMы показывал — страх и ужас же.
Ещё раз повторяю, что "динамика" как ты называешь идёт не от языка, а от задачи. Что поделаешь, что имя колонки в субд это строка, а соответствующее поле в классе — символ.
V>·>Так увольте вы, наконец, этих девелоперов, наймите нормальных. V>Да-да, и перестань пользоваться джавовскими библиотекам.
Ок, и тебе разрешаю — пользуйся такими библиотеками, которые тебе нравятся, благо выбор есть.
V>>>·>Это я к тому, что наличие плохих тестов на Джава, не означает невозможность писать хорошие тесты. И наоборот. V>>>Я не придирался к кач-ву отдельных тестов, я же однозначно выразился — речь идёт о покрытии 100% веток кода. Т.е. речь о полноте набора тестов, принятых в мире Джавы. Сколько видел — позитивных тестов больше негативных. А их должно быть намного-намного больше. Но в Джава малость другая философия, а именно — выплюнул исключение наверх и дело с концом. V>·>Ну покрывай сколько хочешь, хоть 101%. Причём тут исключения? Я перестал понимать о чём ты говоришь, какой-то поток ворчания. V>Да какое уж тут ворчание. V>Просто ты в упор проблемы не видишь в привычном для Джавы подходе слабого покрытия кода тестами и вот тебе кажется, что я тупо придираюсь. Ы-Ы-Ы, как грится.
Ты говоришь о каких-то своих привычках и обычаях принятых в твоей команде. Как я могу что-то видеть? Ну плохо у меня с телепатией.
V>Понимаешь, в Джаве принято
Кем принято? Можно хотя бы параграф в JLS? Или ссылку на JSR?
V>покрывать тестами только целевые юз-кейзы, а не всю потенциальную комбинаторику вызовов, которая может произойти (по различным причинам) в реальном сложном приложении. Именно поэтому считается, что в среднем коде Джава намного больше ошибок, чем в С++. Тут как бэ условная "безопасность" среды немного расслабляет и вот эта "безопасность" с лихвой компенсируется россыпью логических ошибок. В итоге шило на мыло, как по мне. Если бы в С++ творилась подобная небрежность, программы на С++ вообще бы не работали. Се ля ви.
Наоборот, отстутствие UB (и например наличие JMM) даёт меньший набор таких комбинаций в реальном приложении.
V>И да, порой покрыть всю комбинаторику возможных вызовов сложно даже для некоего одиночного объекта, имеющего более 3-х зависимостей. Такая суровая необходимость борьбы со взрывным комбинаторным ростом потенциально-возможных сочетаний прогона одного и того же кода диктует экосистеме С++ специфические правила хорошего тона, а именно — необходимо резко ограничивать исходную размерность пространства "разрешённого".
Это не от языка зависит, а от архитектуры конкретного приложения.
V>Ограничивают это пространство через, да-да, ту самую суровейшую статическую типизацию. Дешевый шаблонный механизм С++, отсутствие пенальти за абстракции (средний мелкий объект/структура шириной всего в один int может являть из себя агрегат из кучи шаблонных типов, 3-5 уровней агрегации — запросто, хоть 10), меньше имерархий и диспетчеризации по конкретным типам.
Ага. Шаблоны. Так бы сразу и сказал. Да, в С++ метапрограммирование развито сильнее. Непонятно почему ты это называешь динамичностью.
V>Например, есть такой оксюморон в плюсах — "статический визитор". Понятно, что визитор НЕ может быть статическим. Тут речь о том, что тот класс задач, который во многих языках решается или через патерн-матчинг или через паттерн Посетитель или даже через тупой прямой опрос типа объекта и даункаст в стиле if(obj is Type1) {...} else if(obj is Type2){} и т.д., в 99% случаев в С++ такая задача решается через статическую диспетчеризацию. К каждому прикладному объекту С++ можно цеплять кучу признаков времени компиляции. Причем, такие признаки могут быть как простыми интегральными флажками (булевскими, целыми, некие типизированные enum), так и целыми глубочайшими иерархиями типов, в свою очередь снабженными подобными флагами. И всё это живёт только в compile-time. В случае джава подобные флаги надо либо вносить явно как часть данных (поля/св-ва) и поверять их в рантайм, либо как часть типа, вводя иерархии наследования и плодя на ровном месте виртуальные ф-ии в protected-интерфейсе классов, которые (виртуальные ф-ии) собсно и являют собой ту самую рантайм-диспетчеризацию (либо по поведению, либо по возвращаемому значению некоего виртуального св-ва-признака).
У шаблонов свои недостатки с другой стороны. Скажем, скорость компиляции.
Если хочется шаблонов и прочего мета — добро пожаловать в Скалу, там те же проблемы со временем компиляции.
V>В итоге, если сравнить программы на С++ и Джава, писанные для решения той же самой задачи, в исполнении С++ может обнаружиться в несколько раз больше конечных (инстанциированных) типов, но при этом намного меньше кода. Угу, шаблоны С++ и Джавы не сравнимы, ес-но и базовая инфраструктура для такого метапрограммирования на сейчас развита не то, чтобы хорошо, а уже даже черезчур. Было бы желание понять ЗАЧЕМ это всё нужно языку С++.
Так в Яве нет шаблонов. Они даже называются по-другому — дженерики.
V>В итоге, тестов для С++ понадобится тоже меньше, т.к. всевозможные неверные вызовы, которые можно осуществить в Джава и на потенциальную возможность которых стоит написать тесты, в хорошей С++-программе даже в исходнике выразить невозможно — компилятор же не даст!
Тут тоже сложно однозначно сказать. Написать такую "хорошую" программу, которая корректно выражает в виде типов-шаблонов некие бизнес-требования вещь нетривиальная. Поэтому ещё непонятно что окажется сложнее — написать тучу примитивных тестов или наворотить заумные шаблоны, которые по сути те же тесты, но compile-time. В каком-то смысле это просто перенос кода тестов на самом языке и выполняемых как обычные программы, на язык шаблонов и выполняемых компилятором. Проще говоря, те же тесты, только в профиль.
V>Вот такая тут связь типизированности, тестового покрытия и надежности конечных программ.
Ок, тут есть что обсуждать (хотя не в рамках сабжа). Но я бы поостерёгся называть это динамичностью, к динамике вообще никакого отношения не имеет. Это относится к выразительности системы типов.
V>·>Потому что он видит реальные данные, с которыми работает программа, наиболее частые потоки выполнения, реально используемые в данный момент классы, и т.п. V>Ясно. )) V>Мне поискать для тебя обсуждения по суперкомпиляции, которые тут происходили в разные годы? V>Кароч, за последние лет 10 мало что изменилось, т.е. положа руку на, у тебя есть возможность НЕСПЕШНО ознакомиться с этим вопросом. V>Простого "ты не прав" ты не примешь, ес-но, опять будет лишь ругань, выражения из разряда "мелешь чушь, газируешь лужи" и прочая непотребщина.
Только не надо мне рассказывать, что JIT полная гадость и вообще фигня. Это вполне конкурирующая технология с AOT. Иначе бы давно вымерла как PGO.
V>>>За время работы такие данные только добавляются, но никогда физически не удаляются (лишь помечаются как неактивные). V>·>А почему нельзя удалить-то? V>А зачем это делать для операций, происходящих раз в месяц примерно (удаление некоего инструмента?), если достоверно биржевая система перезапускается раз в сутки? V>Тут банальная инженерная формулировка задачи и соотв.решение с учётом всех компроммисов по каждому из решений.
Логично. gc это и есть такой компромисс.
V>>>Справочники хранятся как сбалансированное дерево или мультииндекс, итераторы остаются валидными после добавления нового элемента. V>·>И ради чего? V>Ради локальности в памяти + дешевой операции join.
Hash table вроде более локален, там тупо массив.
V>>>Если часть системы — отдельный от, собственно, HFT-матчинга процесс, то и стоит рассматривать именно его — что это за процесс, какие требования и т.д. Тем более, что такие вспомогательные процессы обычно на других физических узлах исполняются. V>·>Пусть отдельный, пусть на других узлах. И что? Почему это должно как-то серьёзно отличаться в ЯП? V>У другой задачи будет другая экосистема.
_может_ быть. Но вовсе не обязательно будет. Если экосистема — та же — довольно много вещей упрощается.
V>Такие вещи вообще приложение веб-сервера решать может, а веб-сервера сейчас на чём только не пишут. )) V>Всё чаще на node.js, кста.
Можно, конечно, но создаёт лишние сложности при интеграции.
V>>>Что Джава не сэкономит ни йоту времени на разработку на задачах такой размерности. V>·>Спекуляция. V>Борьба с мифами. V>Спекуляцией является процесс наоборот — натягивать опыт из разработки и обслуживания больших информационных систем на маленькие. V>Просто надо быть честными с самим собой.
V>Сама организация информационной структуры сложной системы — отдельная задача. Вот именно под эту задачу хорошо ложатся управляемые среды и куча их абстрактных интерфейсов, протоколов, фреймворков и прочего до бесконечности, куда ведут описательные ссылки из артефактов описаний архитектуры таких систем.
Это если у тебя система гетерогенная. Когда везде всё примерно так же — многие вещи типа интерфейсов и протоколов и фреймороков становятся просто не нужны. Зачем тебе придумывать какой-то особый протокол взаимодействия HFT C++ и Web node.js? А потом HFT C++ и DBMS app, а потом node.js и DBMS app, вот и появляется кошмарные корбы, веб-сервисы и прочий ESB. Ведь в большинстве случаев можно просто использовать простой вызов метода.
V>Если же всю информационную сложность можно описать скромной "плоской" брошюркой, то освободившиеся от поддержки "информационной целостности" (назовём так) усилия можно потратить на шлифовку неких критических путей прохождения кода за гораздо меньшую, чем в управляемых средах, трудоёмкость. Вот ты там описывал ручную плоскую разметку памяти FIX-сообщения. За ту же трудоёмкость можно написать половину FIX-движка.
Ровно такую плоскую же которую ты используешь и в С++. В общем это не рокет сайнс, и даже не бином ньютона.
V>>>·>Джава работает прекрасно и даёт кучу бенефитов, уменьшает стоимость разработки. V>>>Для задач уровня a+b никаких бенефитов нет. V>·>Заблуждение. V>Так убеди меня в обратном! ))
Простой факт — многие пишут на Java.
V>>>RMI жрет ресурсы сам по себе, чтобы пользоваться им из узла основного сервиса. )) V>·>Ну не используй RMI. У нас UDP-multicast в качестве транспорта. V>Вот, пока что ты лишь подтверждаешь, а не убеждаешь в обратном.
? А у вас что? Нуль-Т?
V>>>Ну реально, не смешно уже. Сегодня все задачи сетевые и C++ отлично себя в этих задачах чувствует. V>·>Я рад за его здоровье. Но в Java это таки проще. V>Смелее! Что такого я пропустил в Джава, что этого нет в С++ в плане сетевого обмена?
Ну напиши, например простенький rest-service на Плюсах.
V>>>От совсем уж лени можно взять точно такую же CORBA, я ей пользовался в некритичных к быстродействию приложениях. V>·>CORBA вроде сдохла давно. И даже уже закопали. V>Живет как раз там, где джависты хотят вызов методов удалённого объекта, а тот не на джаве или наоборот. V>Т.е. там, где так и не освоили REST-модели.
Ужас, приношу свои соболезнования.
V>>>И то она гораздо легковеснее, чем RMI. V>·> V>Сие факт. RMI работает по рефлексии, а CORBA — через харкорный генерённый код. Разница в скорости сериализации-десериализации более чем на порядок.
Ну не работай по рефлексии.. не используй RMI. Я разрешаю.
V>·>А что делать? V>Ну я выше описал, что делать. V>Другие языковые ср-ва.
Верно. CORBA это не единственное "языковое" средство.
V>>>·>Не надо ждать изменений от C++-икзпертов, когда java-"студентам" понадобилось внести изменение в "свою" часть. V>>>С++-студентов тоже хватает. V>·>Студенты в C++ такое понапишут... segfault это самое удачное будет. V>Код студентов проходит ревью обязательно. V>За попытки лезть в коллекции ручками можно пожурить и показать как правильно. Схватывают на лету обычно. V>Надёжный код складывается из использования надёжных библиотек и надёжных языковых приёмов. Вот и весь "секрет".
Это хорошие студенты тебе попадаются... Вон недавно одного студента собеседовал (по резюме 16 лет коммерческого опыта программирования) — не знает как символ "0" перевести в численное int значение, ни на C++, ни на Java — всегда видимо делал parseInt и не задумывался.
V>>>Ну это к тебе вопрос, почему совсем небольшие конторы предпочитают Java. V>·>Потому что дешевле обходится с теми же результатами. Мелким конторам приходится работать эффективнее, чтобы выживать. V>Ну это же законы бизнеса чистой воды. Меньше вложишь, меньше получишь. Кто-то собирает сливки с биржи, а кто-то остатки.
Т.е. ты согласен, что java позволяет вкладывать меньше?
V>>>Нисколько. V>>>Что-то стоит только профессиональная версия и выше, но это уже для суровой командной работы ср-вами самой студии (что тоже редкость). V>·>Ну IDEA Community тоже бесплатна, или Эклипс. А сурово работать иногда таки приходится. V>Сурово — это разрозненный набор инструментария, отдельно для PM, отдельно для разработки архитектуры, отдельно issue tracking, отдельно git + куча плагинов разной степени курьёзности для объединения всего этого вместе? )) V>Просто мало кто пользует инфраструктуру MS для командной разработки. Под "ср-вами самой студии" подразумевалось именно это.
А, в этом смысле? Ну собственно IDEA Community обычно для всего достаточно. Единственное что в Ulitmate для меня полезно это SQL console, ну и, изредка JS, CSS.
V>>>·>C++ в блокноте тоже не фонтан. V>>>Проще намного, в отсутствии иерархий. V>·>Опять занос какой-то... Каких ещё иерархий? V>Наследования и переопределения виртуальных ф-ий. Потому что тут для понимания кода надо часто сказать вверх-вниз по иерархии.
Наследования и виртуальных ф-ций нет в C++?
V>>>Достаточно какой-нить Kate. V>>>Кода всегда меньше, локальные типы можно объявить и заюзать по месту, а не искать их в других папках/файлах и т.д. и т.п. V>>>Разнообразие функторов, декларативный биндинг и т.д. и т.п. V>>>Кароч, надобности в навигации резко меньше. V>·>И получаются файлики на 10000 строк. Спасибо. V>Не за что. В С++ порой отдельные методы в отдельные файлы выносятся.
Но ведь тогда Kate недостаточно.
А уж постоянная навигация .h/.cpp...
V>·>А если ты не знал, в одном файле можно делать множество java-классов (заметь, и .h-файлы не нужны!). V>Открытый в соседнем окне h-файл, — это как открытый справочник. Есть такое. )) V>В джаве для аналогичного надо специфическое представление кода.
Если очень хочется иметь два файла — вынеси интерфейс, то же самое будет. Но — неудобно. Лучше иметь возможность смотреть разные представления, чем иметь две разных сущности.
V>>>Там, где есть выход на скрипты, там уже совсем-совсем ни джава, ни дотнет не нужны. )) V>·>Я не знаю зачем ты скрипты хочешь... Но если надо — они есть и в огромном количестве. Как легко прикрутить, скажем JS к С++? Ну, чтобы можно было C++ классы использовать и всё такое? V>Я давал тебе ссылку.
Напомни.
V>>>Ну, маппинг XML для DB, как часто бывает в Джава, — это еще хуже, ИМХО. V>>>Поэтому, указал и другой способ. V>·>А что там хуже-то? V>В разрыва второго рода. Неверный макрос хоть компилятор проверит, а тут в рантайме всё тазиком накроется.
Что конкретно накроется? В Джава аннотации есть, их тоже великолепно компилятор проверяет.
V>·>С рефлексией-то из коробки? В худшем случае аннотацию воткнуть на класс придётся. V>Твоя "аннотация" плохо вяжется с такими комментами: V>
V>Как в старом добром QT...
V>)) V>Да, я считаю, что на сегодня безопасней аннотаций ничего нет и быть не может, потому как рефакторинг и прочие глобальные поиски-замены ничего не ломают. Это моё ИМХО, но пока лучших подходов чем это я не видел.
Аннотации не требуют специального кастомного комплиятроа. Я не понимаю что ты тогда критикуешь.
Мало того, даже аннотации не всегда нужны. Можно, например, сделать так, чтобы имя поля класса соответсвовало имени тега в XML. (но такое я не очень жалую)
V>·>Тут кодогенерация нужна на уровне исходников, чтобы в IDE работало всякое автодополнение и прочее. А так кодогенерацию можно в run-time делать (в Плюсах — невозможно). V>А зачем в рантайм кодогенерация? Чтобы каждый раз выполнять ту самую однократную работу? )) V>Мы как-то давным давно юзали предыдущее поколени BL Toolkit, там тоже есть рантайм-генерация акцессоров, так специально допилили код, чтобы эта генерация была как часть compile-time.
Например, можно генерировать код сериализации как ты упомянул, чтобы не надо было использовать рефлексию для "RMI". Два способа:
1. Описываем класс -> компилируем -> генерируем сериализатор -> компилируем -> запускаем.
2. Описываем класс -> компилируем -> запускаем -> генерируем сериализатор.
Второй путь чуть короче и требует меньшей инфраструктуры.
V>·>Но ведь можно не использовать Hibernate или JPA. Так и быть, разрешу тебе и это. V>Остальное в чем-то хуже всегда.
А думаешь с кого сдирали все эти твои "новые" C++ библиотеки?
V>·>А что тогда? V>Тогда здравый смысл: V>https://dev.mysql.com/downloads/connector/
Согласен, с закрытыми исходниками я немного перегнул, не в исходниках дело, а в протоколе. Протокол mysql закрытый, в том смысле что он не стандарт. Т.е. реализовать один раз и забыть mysql jdbc на java не получится, ибо они не обещают совместимость. А публичный mysql client API c library — он документирован и стандартизирован — с обеспечением совместимости и прочего. Поэтому пишется простой java wrapper, который практически никогда не меняется.
Ещё кстати один аргумент в пользу того, что mysql — говно. В postgres такой проблемы нет.
Ты б ещё sqlite в пример привёл
V>Ну конечно никто с 0-ля даже эти коннекторы не пишет, они сидят поверх вот этого: V>https://dev.mysql.com/doc/refman/5.7/en/c-api-function-overview.html
V>А структура этих ф-ий очень близка к АПИ ODBC (разве что одна операция ODBC описывается 2-3-мя из списка по ссылке, т.е. стандарт ODBC чуть более высокоуровневый).
V>По первой ссылке есть и для C++ обертки, написано, что АПИ совместимо с JDBC. Т.е. это является прямым ответом на твой вопрос. V>Единственно что, это АПИ почти никогда в С++ проектах не используют.
Суть jdbc в том, что он позволяет коннектится к большому числу субд единообразным способом, а не в том, что mysql c++ обёртка на него похожа.
V>Дело в том, что к БД лезут через какой-нить ORM-фреймворк, а у него свои типы-абстракции и их проще (и намного эффективнее) закодить через более низкоуровневый слой.
Т.е. через jdbc.
V>>>·>К Скале претезнии обычно в том, что язык слишком перегружен фичами и они не всегда друг с другом хорошо согласуются. V>>>Ну да. Идущие для джава-машинки фичи плохо согласуются с основной философией Скалы. )) V>·>А конкретно? V>Тут тоже были развернутые обсуждения. )) V>Лень начинать заново, можно попробовать поискать. V>Для затравки, "всё является объектом" с т.з. Скалы и сущность "объект" с т.з. JVM — это сильно разные вещи.
Это важно когда надо сращивать Java и Scala код. А так — непонятно чем мешает сам JVM.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Ок, согласен, что с simd у jvm дело плохо. Может когда-нибудь научится. _>·>В общем-то я не утверждал, что всегда. Ты заявил, что "в разы медленнее". Я воспринял это как "обычно в разы медленнее", а ты, видимо, имел в виду "встречаются задачи, когда в разы медленнее". _>Вообще основная моя мысль была в другом — в возражение твоему тезису, что при желание любой java код можно дооптимизировать до производительности C++. Очевидно, что с любым это не пройдёт, причём даже не учитывая такие вещи как simd (сам же видел, что C++ код без simd всё равно в пару раз быстрее). В Java и т.п. языках есть принципиальные архитектурные недостатки не позволяющие этого.
Согласен. Все обобщающие утверждения — ложны.
Обычно можно. Понятное дело, что у С++ всегда есть доступ к уровням ниже, чем у java, но это обычно не нужно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>>>> За счет того, что JIT не сильно оптимизирующий компилятор. Кстати в UUnity там пошли в IL2CPP S>>>·>Это потому что в dotnet плохая реализация JIT, ну не смогли. В java такой проблемы в общем случае нет. S>>>·>ART кстати тоже через С компилирует. Т.к. AOT оказалась более подходящей в условиях мобильных девайсов, т.к. там пользователям важно, чтобы приложения стартовали как можно быстрее, а не раскочегаривались. В серверных же применениях явы — JIT рулит и бибикает. S>>> Ну вот видишь уже подвижка. Согласился что нужен натив для андроида. S>·>Нужен не натив как таковой, а АОТ. А вот у тебя подвижек нет, с терминами полный швах — AOT != натив. Подумай на досуге, что является результатом работы JIT? S>JIT-компиляция (англ. Just-in-time compilation,
Ок. Подытож двумя словами: Что является результатом работы JIT? Что является результатом работы AOT?
И ещё попробуй понять как из приведённой тобой информации можно сделать вывод, что "JIT не сильно оптимизирующий компилятор"?
S>>> Специально для тебя выделил твои же слова. S>·>У тебя путаница с ЖЦ приложения. S> Значит я тебя понять не могу. NGEN ускоряет загрузку приложения. Будешь с эти спорить?
Да, может ускорять. Дальше что? Как это влияет на жизнь батареи в типичном юзкейсе?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
V>>>·>Ну собственно намёк был в том, что твоя гениальная оптимизация пулами аллокаторов уже есть в gc. V>>>Намек был на твоё полное невладение предметом, вообще-то. V>>>Сорри, намек ты не понял, поэтому пришлось написать явно. V>·>Ничего себе! Сочувствую. Было не очень больно? Может ты пиши всегда прямо писать будешь, а не намёками, мы не на свидании, вроде как. V>Человек, который смело так берется рассуждать о Джаве в общем, на мой взгляд, должен быть достаточно подкован в подробностях её механики. Вот я и подумал, что ты прекрасно в курсе, как в Джаве выделяются объекты большого размера.
Опять меня ловить пытаешься. Говоришь загадками, потом заявляешь какую-то банальность и объявляешь себя победителем. Ладно, ты — победитель, я слил. Можешь радоваться.
V>>>Ну конечно, в GC такой оптимизации нет, т.к. процесс освобождения памяти крайне дорогой. V>·>Так я ж пишу — TLAB такая оптимизация и есть — тред использует свою персональную память по возможности. V>Этим улучшается локальность, но не получается избежать стандартного пробега по ссылочному графу.
Ещё уменьшается взаимодействие между тредами. Между тредами бегать не надо.
V>>>·>Чем оправдываешь переизобретение велосипеда? V>>>Технологии современного велосипеда меняются приблизительно каждые 5 лет. V>·>И что в аллокаторах поменялось 5 лет назад? V>Новые реализации выходят, библиотеки/инфраструктуры для дешевой разработки своих и т.д. V>Даже твой GC — это тоже разновидность аллокатора.
Логично. GC тоже постоянно точат.
V>·>Что такое "Куча GC" V>Что такое GC?
Сборщик мусора.
V>>>·>И что такое "честный образ"? V>>>Это обычный аллокатор. V>·>Что такое "обычный аллокатор" в java? V>Это который такой же как для любой нейтивной программы.
malloc в смысле? Он, особенно в HFT, вызывается ровно один раз — в момент старта приложения. К чему ты клонишь-то?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Представь на минуту, что в Джава вообще запретили динамическое приведение типов. Ну вот включи воображение. Всё, с этого момента такой операции тупо нет в JVM. Вот как ты будешь писать код? ·>Да те же хаки как и в плюсах
В плюсах без хаков.
·>виртуальный GetType
И без GetType.
Да и большинство типов идут без таблицы виртуальных ф-ий.
·>или хитроумные макросы, сам же мне C++ ORMы показывал — страх и ужас же.
Не ужаснее описания маппинга на XML, с той разницей, что компилятор статически проверяет соответствие по крайней мере со стороны типов С++.
·>Ещё раз повторяю, что "динамика" как ты называешь идёт не от языка, а от задачи.
От способа решения задачи, т.е. от доступного инструментария в языке.
·>Ага. Шаблоны. Так бы сразу и сказал. Да, в С++ метапрограммирование развито сильнее. Непонятно почему ты это называешь динамичностью.
Это, наоборот, называется статичностью. В C++ прилично логики и проверок переносят в compile-time, вот и вся разница, собсно.
ОК, больше не буду грузить подробностями.
Здравствуйте, ·, Вы писали:
EP>>·>Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором. EP>>Ещё раз, не язык становится динамическим, а в коде используется больше динамических подходов. Простейшее для понимания утверждение жеж ·>Динамические подходы зависят от задач, а не от языка.
От языка в том числе — так как в одном языке статический полиморфизм реализуется легко, а в другом нет — и как следствие используется динамический
·>Использование std::map — динамический подход?
В каком-то смысле да. Точнее его бывает используют для случаев когда все входные данные (а бывает ещё и выходные) известны в статике. В C++ для таких случаев есть например boost::mpl/fusion/hana::map — в которых соответственно бОльшая часть ошибок ловится во время компиляции
·>Ок, могу согласится, что использование динамических подходов в Java проще, чем в Плюсах. Это что, плохо?
Я не знаю с чем ты соглашаешься, ибо я такого утверждения не делал. Моё утверждение в том что статика на C++ распространённые и легче.
Динамика например немного проще и лаконичней в C# как раз за счёт упомянутого тобой dynamic.
EP>>Замени на dynamic_ec.call("exampleMethod1", 10, 4); — типизация статическая, ·>Ровно такая же конструкция может быть и в С++. Почему возможность такой конструкции ставится в упрёк именно Яве, хотя ровно то же можно сделать и в С++?
Ставится в упрёк (точнее констатируется как факт) не возможность использовать динамические конструкции, а:
а) фактические засилье динамических конструкций в коде, библиотеках
б) слабые языковые средства для перевода в статику
EP>>а код такой же динамический как и с dynamic в C#, со всеми вытекающими недостатками (типа меньшего количества статических проверок). ·>Нет, не такой же. "exampleMethod1" это просто строковой литерал, а exampleMethod1 — символ языка.
Это лишь форма. Что это меняет с точки зрения обсуждаемой проблемы статики/динамики/отлова ошибок?
EP>>·>в java таких "фич" нет, и не надо. EP>>Нормальная фича. ·>А смысл? Ни автодополнения, ни рефакторингов, ни goto definition, нифига.
Лаконичность динамического кода. Со строками у тебя точно также не будет рефакторингов и т.п. только форма менее удобная и выразительная.
Да и в какой definition ты собираешься переходить? dynamic'ом например может быть xml документ: xml_root.person.name = "John";
EP>>>>Утрированный пример: something.call("function_name"); — ошибка в имени функции вылезет только в runtime даже в языке со статической типизацией. EP>>·>Утрированный пример: std::map<std::string, std::function<void> >something; something.at("function_name")();. Ну как? Запишем таки С++ в динамические языки? EP>>Ты не понимаешь о чём речь. И на C++ можно писать с кучей динамики, более того можно вообще дёргать eval какого-нибудь динамического языка. EP>>Речь же о том что обычно на Java больше динамики чем на C++, а не о том что у него типизация динамическая. ·>Так какой такой особенной динамики? ·>Может ты имеешь в виду рефлексию?
Нет, в основном не рефлексию — хотя и тут видны отличия — ибо в C++ добавят compile-time рефлексию, а не runtime — для многих задач нужна именно она, и из неё при необходимости можно перейти в runtime рефлексию, а вот наоборот не получится.
Самый обыденный пример динамики — это динамический полиморфизм со стиранием типов, вместо статистического.
·>Обычно делают хрень с макросами или какой-нибудь генерацией исходников каким-нибудь жутким m4.
Зачем m4? — это у тебя какие-то предрассудки. Без проблем для этих целей используется например Python, либо напрямую, либо через шаблонизатор типа Jinja, либо и вовсе препроцессор типа Cog. В систему сборки это добавляется одной строчкой
EP>>·>Ты похоже путаешь "статический|динамический полиморфизм" и "статический|динамический язык". EP>>Прикольно, вообще-то это ты тут запутался. Я не говорил что у Java динамическая типизация — перечитай сообщение ещё раз. ·>Я не понимаю что ты имеешь в виду "больше динамики".
Стирание типов. Например с последующими dynamic cast'ами и runtime проверками, вместо параметрического полиморфизма и статических проверок (перегрузки, static_assert, etc).
·>Скажем, весь такой жутко динамический PHP и Пайтон написаны на C++ — это означает, что в C++ больше динамики?
Ещё раз, речь не про возможность использовать динамику, а про невозможность обширно использовать статику и фактическое засилие динамики.
EP>>>>Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны EP>>·>Потому что ничем не грозит. В Java неправильное приведение типа — исключение, в Плюсах — UB. EP>>Ты опять не понимаешь о чём речь. ·>Тут мне vdimas говорил, что в Java программе чаще используются касты (похоже, там у них специальный человек с плёткой стоит и заставляет всех касты в java код вставлять).
Это из-за того что типы чаще стираются, отсюда и касты.
EP>>Дело не в UB или ещё в чём-то (в одной из форм dynamic_cast как раз исключение) — ещё раз посмотри на dynamic_ec.call — там никакого UB. ·>Ок. В чём тогда разница между Явой и плюсами в этом смысле?
Разница в том что в C++ больше статических выразительных средств, многие библиотеки имеют именно статические интерфейсы, и по факту намного меньше стирания типов за счёт повсеместного использования параметрического полиморфизма.
·>Ксати, dynamic_cast вообще в Яве не существует. Опять получается, что С++ более динамичный!
Прикалываешься? Там не динамический cast отсутствует, а статический
EP>>>>к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно. EP>>·>Потому что обычный полиморфизм тормозит. EP>>В этой под-теме не важно почему — факт того что в C++ больше статики налицо. Больше статики — больше проверок времени компиляции. ·>Может и налицо, но это мнение, зависящее от твоей интерпретации понятий, а не факт.
Всё что я говорю зависит от моей интерпретации понятий
EP>>>>Возможно EP>>·>А есть что-то реальное, а не заброшенный 10 лет назад студенческий курсовик? EP>>Твоё утверждение о невозможности — не верно. ·>На текущий момент — верно.
Нет.
·>Ты вообще читал-то сам что это, прежде чем предлагать это как возможность кодогенерации в Плюсах? "a simplified, C-like sub-language with first-class arrays and no pointer arithmetic" — так ещё никто Плюсы не оскорблял.
Я не предлагаю это как возможность, я лишь показываю что это без проблем реализуется. В частности в приведённом примере реализован библиотечный runtime DSL, AST которого налету оптимизируется под конкретные данные, и компилируется для CPU или GPU.
EP>>Банально с собой можно тасккать компилятор — и получаешь runtime кодогенерацию. ·>Компилятор не является частью языка или платформы. javax.tools.JavaCompiler — является. Вот когда появится std::cpp_compiler или ладно, я даже согласен на boost::cpp_compiler — поговорим. ·>Плюс ещё java.lang.instrument есть.
А зачем ты ставишь какие-то непонятные искусственные рамки сферической платформы? Вот make — это часть чего? А Clang? А почему его нельзя таскать с собой?
Есть например Cling — интрепретатор/JIT C++ на базе Clang, посылай ему код и выбирай нужный уровень оптимизации
Здравствуйте, ·, Вы писали:
V>>Ограничивают это пространство через, да-да, ту самую суровейшую статическую типизацию. Дешевый шаблонный механизм С++, отсутствие пенальти за абстракции (средний мелкий объект/структура шириной всего в один int может являть из себя агрегат из кучи шаблонных типов, 3-5 уровней агрегации — запросто, хоть 10), меньше имерархий и диспетчеризации по конкретным типам. ·>Ага. Шаблоны. Так бы сразу и сказал. Да, в С++ метапрограммирование развито сильнее.
Шаблоны это не обязательно метапрограммирование, это например ещё и обобщённое программирование, параметрический полиморфизм.
Собственно их добавляли в язык не ради метапрограммирования — метопрограммирование появлялось позже как побочный эффект от мощной/гибкой спецификации.
V>>В итоге, тестов для С++ понадобится тоже меньше, т.к. всевозможные неверные вызовы, которые можно осуществить в Джава и на потенциальную возможность которых стоит написать тесты, в хорошей С++-программе даже в исходнике выразить невозможно — компилятор же не даст! ·>Тут тоже сложно однозначно сказать. Написать такую "хорошую" программу, которая корректно выражает в виде типов-шаблонов некие бизнес-требования вещь нетривиальная.
Этот подход возможен, но это ты в какие-то дербри полез, отличие в подходах к статики/динамики между C++ vs Java начинаются намного раньше — например при стирании типов и динамическом vs статическом полиморфизме — это НЕ метапрограммирование.
Здравствуйте, ·, Вы писали:
V>>Или это была просьба слить тебе базу данных клиентов? ·>Нет, хоть какие-нибудь реальные цифры, хоть что-то похожее на проверяемые факты, а не простое форумное блаблабла.
Я тебе именно факты привел.
Контора продаёт нейтивные, дотнетные и джавовские решения, нейтивных намного больше.
·>Я могу например предложить погуглить HFT-позиции — java составляет не менее трети, остальное native, c# — в микроскоп не видно, и в основном GUI (что не совсем HFT в общем-то). Притом многие позиции в top 10 IB, а их бедными назвать язык не поворачивается.
V>>Я не могу уловить, где именно ты проводишь границу. Похоже, прямо по Джаве, ы-ы-ы. )) ·>По Language Specification, очевидно.
В самом языке нет потоков. А вот в системной библиотеке, являющейся частью стандарта, уже есть.
Очевидно, что это всё спор вникуда.
V>>·>Шустрость не нужна разве? Ведь dotnet уже почти работает быстрее натива... V>>Шустрость джаве нужна, конечно. Но, боюсь у меня для тебя плохие новости. В этом плане в Джаве не ожидается НИЧЕГО в ближайшие лет 10 уж точно. ·>Не увиливай. Почему HTTP не реализован с unsafe, а в FIX приходится? В HTTP не нужна шустрость?
Я тебе уже ответил, но ты не понял ни слова, как обычно.
асинхронные сокеты на IOCP реализованы в нейтиве
V>>·>Ты ошибся с тестом BlockingQueue, назвав его тестом дизраптора V>>Это ты ошибся с дисраптором, не поняв принцип его работы. ·>Врёшь. Или цитату в студию.
Вот твоя цитата:
Ты ошибся с тестом BlockingQueue, назвав его тестом дизраптора
Очевидно, что ты НЕ понимаешь, что есть дисраптор и на какой именно тест я дал тебе ссылку.
·>"Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. " — ты всё ещё уверен, что дизраптор так и делает? Повторяю, с дизраптором объекты не генерятся, а переиспользуются преаллоцированные. Ссылку которую ты привёл в качестве "доказательства" — дизраптор не использовался вообще.
Это и есть дисраптор. Это его базовый Lego-кубик (один из 3-х, вернее, с идентичным интерфейсом).
Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди, ссылку на тест которой (очереди) я тебе дал.
Здравствуйте, vdimas, Вы писали:
V>·>Да те же хаки как и в плюсах V>В плюсах без хаков.
Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче?
V>·>виртуальный GetType V>И без GetType. V>Да и большинство типов идут без таблицы виртуальных ф-ий.
А моки как делаются?
Большинство классов в Java обычно ни от чего не наследуются, т.е. виртуальность не используется.
V>·>или хитроумные макросы, сам же мне C++ ORMы показывал — страх и ужас же. V>Не ужаснее описания маппинга на XML, с той разницей, что компилятор статически проверяет соответствие по крайней мере со стороны типов С++.
Соответствие типов чему? Пишешь pojo-класс с нужными типами полей — он и маппится. Что ещё за описание?
V>·>Ещё раз повторяю, что "динамика" как ты называешь идёт не от языка, а от задачи. V>От способа решения задачи, т.е. от доступного инструментария в языке.
Выбор способа лежит на тебе, как программисте. Если ты выбираешь RMI через CORBA для доступа к JPA — это твой выбор.
V>·>Ага. Шаблоны. Так бы сразу и сказал. Да, в С++ метапрограммирование развито сильнее. Непонятно почему ты это называешь динамичностью. V>Это, наоборот, называется статичностью. В C++ прилично логики и проверок переносят в compile-time, вот и вся разница, собсно. V>ОК, больше не буду грузить подробностями.
Это называется выразительностью системы типов. Динамика это возможность менять типы объектов или систему типов в рантайм.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Но мы естественно такие "читы" использовать в дискуссии не будем. )))
Вот make — это часть чего? А Clang? А почему его нельзя таскать с собой?