Здравствуйте, Ikemefula, Вы писали:
I>>>Это враньё. Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код.
N>>"Это враньё" ((c) Ikemefula). Перепахиванию RAM пофиг нативность кода, до тех пор, пока интерпретатор хоть как-то разумен — даже самый тупой JIT тут даёт достаточный результат.
I>Разумности интерпретатора мешает время на принятие решений. В компайлтайм компилер может хоть час думать. У джыта этого фокуса нет.
А зачем ему думать час? Все случаи торможения C++ это или хедера неподъёмного масштаба, или сверхтяжёлые шаблоны. Java и C# одинаково избавлены от этих проблем, а JIT компилятор тем более, что всё уже превращено в IL того или иного вида.
Генератор кода — совершенно шаблонная штука, хотя он даже в этом случае умудряется делать оптимизации типа "соберём цепочку умножений в SSE".
I>>> У тебя даже тупой проход по массиву интов на сишном коде даст вопиющую разницу. N>>Не даст. I>А даёт.
Ты получил из HotSpotʼа оптимизированный прогретый код и дизассемблировал? Дай инструкцию на повторить.
I>>>Если речь про перформанс, то он обязан быть самым лучшим, а не просто внятным. У джавы перформанс никогда не был на первом месте. У ней на первом месте кроссплатформенность, менеджед со своими плюшками. Все что угодно, но не перформанс. I>>>Хочешь перформанс — есть только Си и тот без плюсов. N>>С чего это без плюсов? I>А их никто толком и не знает, кроме нескольких реликтов из 90х
Здравствуйте, vdimas, Вы писали:
V>В дотнете и джаве может происходить аналогичное, кста, при каком-нить thread abort.
В java нет thread abort (или ты имеешь в виду прибить тред как-то извне?)
V>·>К неинициализированнй/освобождённой памяти не обращались? И segfault-ы не падали? V>В биржевой проге?
Молодцы, или повезло.
V>·>В каком ещё "динамическом" коде? javascript что-ли? Причём тут вообще динамический код? V>Джавовский код весьма динамичный. Сплошные приведения типов и все как один — динамические.
В биржевой проге?
V>·>Тебя куда-то заносит постоянно. Вначале в dotnet vs java запихал native, а теперь ещё и динамику. V>Курить, что есть динамика.
В C++ есть http://en.cppreference.com/w/cpp/language/dynamic_cast . Так и запишем: "C++ — динамический язык".
Что сказать-то хотел?
V>>>Я еще ни разу не видел, чтобы под Джаву писали в 10 раз больше тестов, чем исходного кода. V>·>Из-за того, что у тебя проблемы со зрением, не значит, что их нигде не пишут. V>·>Тем более лишь только потому что это джава. Или ты возьмёшься утверждать, что все написанные С++-системы имеют 10х объём тестов? V>В С++ надо примерно 2x, в джаве примерно 20x.
Не сочиняй.
V>Потому что уровень типизации исходника несопоставим от слова совсем.
Что такое "уровень типизации"?
V>Там, где в джава разруливается на рантайм-полиморфизме и динамическом приведении, там в 90% на С++ идёт статическая диспетчеризация, а не рантайм. Соответственно, нет "рантайм" — не надо ЭТИ моменты тестировать запуском на исполнение, их тестирует сам факт компиллируемости. Иначе это будет тест компилятора, а не программы, ы-ы-ы.
Не понял, можно пример? Что мешает в java сделать так же?
V>>>А это вообще минимальная граница, с которой только можно начинать хоть как-то полагаться на тестирование. На типичные джавовские юнит-тесты без слёз не взглянешь. V>·>Давай я напишу слёзогонные тесты на Плюсах, это улучшит Джаву в твоих глазах? V>Нет конечно. Что еще можно ожидать от мира Джавы? ))
Это я к тому, что наличие плохих тестов на Джава, не означает невозможность писать хорошие тесты. И наоборот.
V>Дело не в этом. "Без слёз" — это по логике самого тестирования. Тест должен тестировать вообще все ветки прохождения кода из исходника, а в джаве этих веток слишком много на ровном месте, по меркам того же С++, из-за слабой типизации. У нас тесты покрывают 100% веток, в джаве я и 50% покрытия НИ РАЗУ за всю свою жизнь не видел. И, если ты мне пришлешь свой код и тесты к нему под DNA — и не увижу, ес-но. )) Я свой код и тесты могу прислать, кста. Ну что ченж?
Ну меня могут побить, если я исходники из внутренней сети выносить буду, так что рисковать не буду, а официальный запрос создавать — не хочу заморачиваться, да и обосновать будет тяжко.
Открой любой Getting Started любого testing framework... Не понимаю что там может быть такого особенного. Наоборот, реализовывать моки и проверки проще, благодаря наличию рефлексии и виртуальности всех методов.
V>>>·>А в нетривиальных случаях, когда RangeCheckElimination ниасиливает — человеку тоже асилить непросто. Хотя да, ведь зачем напрягать компьютер, девушки С++-сники хорошо справляются. V>>>Открой для себя т.н. "алгоритмы" буста и STL. Прекрасно компьютер справляется. Просто JIT-у некогда справляться, в отличие от полноценного оптимизатора С++. V>·>Доказательства есть? V>Того, что оптимизатор C++ круче оптимизатора JIT? V>В школу срочно!
Количество информации доступной JIT — больше, так что не всё так однозначно.
V>>>Алгоритмы сравнивают: V>·>Не понимаю чем это будет принципиально отличаться от java. V>В плане безопасности такого кода? — ничем. V>О чем и речь, собсно. V>Чтобы выйти за пределы диапазона vector, его надо дёргать ручками. V>Но любое такое "дергание" — это какой-то алгоритм. V>В С++ принято оформлять телодвижение в пересчете на элемент, а пробегаться по коллекциям через подходящие т.н. "алгоритмы". V>В дотнете для таких вещей есть расширения коллекций System.Linq, чтобы ручками по ним не бегать. V>Конечно, можно ручками и в дотнете бегать и в С++ и получать ошибки и там и там, но есть правила хорошего тона.
Дело не в алгоритмах, а в архитектуре. Скажем, у тебя есть какой-то контейнер с текущими сессиями клиентов. На эти самые сесси могут быть ссылки откуда-то ещё, и ещё какие-нибудь события летают, и, в итоге, надо аккуратно заботиться о времени жизни и не налажать.
V>>>>>Дык, уровень косвенности на единицу меньше. V>Не понял, так не понял. V>Я не удивлён.
Газанул в лужу и убёг.
V>>>В реалтайме идёт заливка в файл в транзакционную файловую систему, V>·>FileOutputStream.write? V>Да пофиг на конкретное АПИ. V>Я отвечал на то, что в HFT, видите ли, идёт обращение к БД и веб-сервисам и поэтому джава удобней. ))
В HFT-системе (бирже, например) вполне можно обращаться к БД (но не из всех частей этой системы).
V>>>а не в БД. Там никакая БД не справится, ес-но. V>·>Смотря где. V>В реальном HFT.
Наличие реального HFT не означает отсутствие нереального HFT.
V>·>Вести бд счетов, движение средств, и контактные и прочие данные клиентов. Архивы трейдов. Описание инструментов. V>30-40 таблиц, я же давал тебе цифры уже.
И что?
V>·>Ты уверен, что это всё требует реалтаймную заливку в транзакционную фс? V>Я уверен, что такая размерность задачи не требует никакой джавы от слова совсем. ))
Не знаю, что ты понимаешь тут под "требует". Джава работает прекрасно и даёт кучу бенефитов, уменьшает стоимость разработки. Разве не прекрасно просто вызвать метод интерфейса в LL-Core сервисе, а имплементация интерфейса будет в другом DB-сервисе, который выполнит тормозной SQL? Не надо выдумывать совместимых сериализаций и протокола взаимодействия между разными языками. Сразу видишь и читаешь весь код — goto definition, find usages, и т.п. редактируешь как надо:
V>Такую "сложность" сейчас делают студенты на коленке на чем угодно.
Не надо ждать изменений от C++-икзпертов, когда java-"студентам" понадобилось внести изменение в "свою" часть.
V>>>Ес-но это всё происходит через нейтив. Периодически в БД сливают только снапшоты. Это другой процесс/узел, ему надо проводить бешеную агрегацию исходных данных, там ничего кроме нейтива не выживает. Инфраструктура мониторинга так и работает, как отдельный узел, куда в бешеном режиме сливаются вообще все данные и на этом узле обычно и происходит та самая суровая агрегация и потом неторопливая выдача данных по запросам в XML или другом текстовом формате. В том числе клиентам на Джаве, ес-но. V>·>А почему таки на Джаве? Писали бы уж всё на плюсах, ведь там Алгоритмы есть. V>Потому что вес клиента и вес биржи несопоставимы. Клиентами бывают совсем маленькие брокерские конторы. Ну и ОК.
Так почему не Плюсы-то? Они экономят 0.00001% всех затрат что-ли?
V>>>Инфраструктура тестирования/сертифицирования, все эти эмуляторы — это нейтивное АПИ с выходом на скрипт, там нечего делать никакой джаве, потому что требуется работать БЕЗ развернутых ср-в разработки, т.е. подправил скрипт — тут же запустил. V>·>А какие средства разработки надо разворачивать для Явы? Ну там git скачать, чтобы исходники из репо забрать и.... ну можно ещё Идею поставить, чтобы подправлять "скрипты" пришлось не в тупом notepad, а с автодоплнениями и подсказками. Собственно всё. V>Вот этого всего и даром не надо и гонится ссаными вениками.
Не нужно для чего? Обеспечивать QA?
V>Оператор на целевой машине всегда удалённо работает.
Оператор чего? Оператор тестовой инфраструктуры??
V>>>>>А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но. V>>>·>Верно. Но обратное-то не верно. Бывают и не сложные системы, которые тоже могут быть требовать. V>>>Ну вот ты снова спутал необходимое с достаточным и проиграл. )) V>·>Это ты спутал. Не обязательно иметь "действительно" сложную систему, чтобы в ней потребовалась java с целью минимизировации затрат на разработку и поддержку. V>Обязательно. Иначе дороговизна джавы по всем своим зависимостям (ср-ва разработки + инфраструктура) — это чистой воды суровый убыток.
Какая инфраструктура нужна для Java? Единственное что там дорого, это IDEA (кстати, разве $300 /year*dev дорого для организации?). Ну ещё может Azul. Всё.
А сколько там Студия стоит? А если ты
V>И не надо мне про Джаву в блокноте. На ней в блокноте писать невозможно от слова совсем, это будет идиотизм, а не разработка.
C++ в блокноте тоже не фонтан. А скрипты... Ну подключи groovy/javascript или просто jsr223 если так скриптов хочется.
V>Нового? )) V>Да это "новое" льется широкой полноводной рекой нон-стоп.
V>Тема настолько обширна и настолько разнообразна по своим подходам, что тут лучше самому по гуглу, а здесь спрашивать лишь непонятные моменты.
V>Могу лишь указать основные два направления оперирования метаинформацией для С++: V>1. Ручное перечисление полей для сериализации. Часто берут boost::serialization и просто подставляют ему свой "архив". Или вот: V>https://github.com/the-alien/metacpp/blob/master/test/SqlTest.cpp V>По ссылке библиотека биндинга на JS, но этот биндинг — это биндинг метаинформации, задешево еще и SQL прикрутили. ))
Жуть. Макросы макросами погоняют. Как и в старом добром MFC, даже CObject есть. Нового-то что? Вот тут, если кодогенерацией не брезговать.
V>2. Всевозможные кодогенераторы, которые генерят акцессоры к объектам по примерно вот такому валидному (полезному) С++ исходнику:
Как в старом добром QT... Притом выглядит хуже, чем даже жуткий Spring data.
V>·>Универсальный коннектор сделали наконец-то по типу jdbc? V>У меня рука уже устала ко лбу её прикладывать. )) V>Интересно, на какую букву заменить первую в "jdbc", чтобы получить нечто, что на 20 лет старше самой джавы? )) V>И да, вот еще интересно. Я вот видел некие провайдеры jdbc, писанные как JNI-обертки не напомнишь над чем? (рука-лицо снова)
Они оборачивают closed source пропиетарные native only коннекторы к субд, тут тупо других нет вариантов.
V>Причем, это всё г-но мамонта, ес-но, есть и более новые стандарты.
Ага. Более новые стандарты... "Современные традиции", блин.
V>>>А если взять дотнетный linq, то про джаву вообще вспоминать стыдно. V>·>Да много всякого уже напридумывали, честно говоря не слежу за этим. Ещё и другие jvm языки есть, в scala вроде аналог линка. V>В Скале нет аналога Linq, но ср-ва композиции алгоритмов не уступают как минимум С++, есть такое.
Scala slick?
V>Скала — это язык с хорошей исходной концепцией, но сильно загрязнённый артефактами вынужденной интероперабельности с джава-машинкой.
Что за такие артефакты?
V>Собсно, к F# аналогичные претензии.
К Скале претезнии обычно в том, что язык слишком перегружен фичами и они не всегда друг с другом хорошо согласуются.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>> Еще раз это аналог .NGEN. Он мало, что дает. И оптимизации для андроид версии там скорее всего нет, ибо батарея будет садиться быстро. S>·>.net native делается с целью убрать зависимость от fw (который изначально был непереносимым и неотъемлимым компонентом системы, засунутый по самые гланды), а производительность за счёт чего? (ну кроме как за счёт исправления косяков ngen). S> За счет того, что JIT не сильно оптимизирующий компилятор. Кстати в UUnity там пошли в IL2CPP
Это потому что в dotnet плохая реализация JIT, ну не смогли. В java такой проблемы в общем случае нет.
ART кстати тоже через С компилирует. Т.к. AOT оказалась более подходящей в условиях мобильных девайсов, т.к. там пользователям важно, чтобы приложения стартовали как можно быстрее, а не раскочегаривались. В серверных же применениях явы — JIT рулит и бибикает.
S>·>Цели убрать такую зависимость в ART нет, поэтому сделали именно так. S>·>Компиляторы java->native были, есть и будут если понадобится. Каких-то принципиальных проблем их использовать — нет. S>·>Я, кстати, много лет назад использовал GCJ, чтобы собрать из java-кода standalone (в смысле без каких либо зависимостей) dll. S> Еще раз есть кроссплатформенный .Net Core, который кстати позволяет работать только с используемыми библиотеками. S>https://habrahabr.ru/post/311520/ и не зависить от Фреймворка. Так что твои умозаключения об зависимости от фреймвока нет.
Я запутался. Зачем и core, и native?
S> Главное скорость, расход батареи, обфускация.
Скорость чего? Инстолляции? Кого это парит? Расход батареи тут не причём, т.к. ART компилирует только в install time (времени расходутеся как правило меньше, чем на скачку). Сколько раз в день ты ставишь новый софт на свой мобильник?
Зачем повторяешься? Обфускация практически никому не нужна, а кому нужна — есть обфускаторы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>https://benchmarksgame.alioth.debian.org/u64q/java.html _>·>В "разы", конечно, не стоит так уверенно заявлять. Тут в среднем отставание раза в 1.5-2. Притом, как я вижу, java код там написан вообще без каких-либо забот о перформансе и это простой main(), без всякого прогрева (т.е. шанса выполнить все оптимизации до начала замеров). _>·>Если же потратить немного усилий для оптимизации, то разницу можно свести к десятку процентов, а то и уровнять, вплоть до точности измерений. _>·>Единственное что в managed языках плохо, что количество потребляемой памяти будет всегда больше.
_>Говоришь максимум в 2 раза разница и потратив немного усилий её можно свести к десятку процентов? ) Ну-Ну) _>Я вот в прошлом году делал один простенький тест для своих целей. Вот тут http://rsdn.org/forum/philosophy/6117201.1
можно увидеть упрощённую сводную табличку результатов. Там же есть ссылка на Java код данного теста (меньше 20 строчек) — покажешь как этот простенький примерчик довести до уровня быстродействия C++? )))
Это же числодробилка чистейшая. Я говорю о среднем случае, для типичных задач.
Да и кстати C++ no-simd как раз в 2 раза быстрее таки. JIT похоже не умеет simd.
ИЧСХ — c# оказался ещё медленнее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
_>>Твои рассуждения конечно верны, но в глубокой теории, а на практике всё наоборот. Если рассуждать абстрактно, то подобные платформы (работающие под управлением ВМ, типа jvm, clr, многие скриптовые языки) могут обходить по быстродействию любые нативные языки, потому что имеют возможность применить все их статические оптимизации и потом ещё добавить к ним кучу своих рантаймовых. Именно так обычно и рассуждают пропагандисты данных технологий. Однако нас, практиков, интересуют не их влажные фантазии о счастливом будущем, а текущая суровая реальность. Так вот в данный момент на практике все компиляторы подобных платформ не обеспечивают даже половины мощнейших статических оптимизации (работающих по дефолту скажем во всех основных компиляторах C++) и добавляют при этом всего одну-две слабенькие рантайм оптимизации. В итоге на практике Java/C# (про скриптовые и не говорим) отстаёт от аналогичного C++ кода в разы. ·>https://benchmarksgame.alioth.debian.org/u64q/java.html ·>В "разы", конечно, не стоит так уверенно заявлять. Тут в среднем отставание раза в 1.5-2. Притом, как я вижу, java код там написан вообще без каких-либо забот о перформансе и это простой main(), без всякого прогрева (т.е. шанса выполнить все оптимизации до начала замеров).
Какой прогрев, ты о чём? Ты код-то открой — там аллокаций практически нет — O(1), везде массивы byte и double. Такой код действительно будет меньше всего отставать, так как в нём нет никаких тех ужасов которыми пестрит обычный код и которые здесь обсуждаем
То есть вот это твоё отверждение "Тут в среднем отставание раза в 1.5-2" — это мухлёж жеж, ибо не в среднем, а в вырожденных случаях
Здравствуйте, ·, Вы писали:
V>>·>В каком ещё "динамическом" коде? javascript что-ли? Причём тут вообще динамический код? V>>Джавовский код весьма динамичный. Сплошные приведения типов и все как один — динамические. ·>В биржевой проге?
Да, я охотно верю, что в пути кода, обрабатывающего FIX-сообщение, нет приведений типов. Но это один процент от всего приложения, пусть и самый критичный к эффективности. В остальном его будет дофига. А еще если брать совсем остальное что ты предложил: базы, отчеты, платежи и т.д., то там в джаве динамика динамикой погоняет.
V>>·>Тебя куда-то заносит постоянно. Вначале в dotnet vs java запихал native, а теперь ещё и динамику. V>>Курить, что есть динамика. ·>В C++ есть http://en.cppreference.com/w/cpp/language/dynamic_cast . Так и запишем: "C++ — динамический язык". ·>Что сказать-то хотел?
Возьми огромные проекты на С++ (мильоны открытых) и поищи грепом этот dynamic_cast. В подавляющем большинстве их не встретишь ни одного.
Сейчас вообще модно компилить с отключением RTTI. В коммерческом коде так и вовсе dynamic_cast — нонсенс.
V>>Потому что уровень типизации исходника несопоставим от слова совсем. ·>Что такое "уровень типизации"?
Имелась ввиду статическая типизация.
·>Не понял, можно пример? Что мешает в java сделать так же?
Даункасты мешают. Это просто такой принцип построения архитектуры и привычки девелоперов, что без даункаста никуда.
·>Это я к тому, что наличие плохих тестов на Джава, не означает невозможность писать хорошие тесты. И наоборот.
Я не придирался к кач-ву отдельных тестов, я же однозначно выразился — речь идёт о покрытии 100% веток кода. Т.е. речь о полноте набора тестов, принятых в мире Джавы. Сколько видел — позитивных тестов больше негативных. А их должно быть намного-намного больше. Но в Джава малость другая философия, а именно — выплюнул исключение наверх и дело с концом.
·>Количество информации доступной JIT — больше, так что не всё так однозначно.
Откуда больше?
·>Дело не в алгоритмах, а в архитектуре. Скажем, у тебя есть какой-то контейнер с текущими сессиями клиентов. На эти самые сесси могут быть ссылки откуда-то ещё, и ещё какие-нибудь события летают, и, в итоге, надо аккуратно заботиться о времени жизни и не налажать.
Ну вот как раз Сессия — объект самого верхнего уровня и создаётся в куче. Но таких объектов во всём приложении — просто мизерный мизер.
Например, все справочные данные можно хранить в коллекциях по-значению.
За время работы такие данные только добавляются, но никогда физически не удаляются (лишь помечаются как неактивные).
Справочники хранятся как сбалансированное дерево или мультииндекс, итераторы остаются валидными после добавления нового элемента.
V>>>>>>Дык, уровень косвенности на единицу меньше. V>>Не понял, так не понял. V>>Я не удивлён. ·>Газанул в лужу и убёг.
Самокритично.
·>В HFT-системе (бирже, например) вполне можно обращаться к БД (но не из всех частей этой системы).
Если часть системы — отдельный от, собственно, HFT-матчинга процесс, то и стоит рассматривать именно его — что это за процесс, какие требования и т.д. Тем более, что такие вспомогательные процессы обычно на других физических узлах исполняются.
V>>>>а не в БД. Там никакая БД не справится, ес-но. V>>·>Смотря где. V>>В реальном HFT. ·>Наличие реального HFT не означает отсутствие нереального HFT.
И снова в Киеве дядька.
V>>·>Вести бд счетов, движение средств, и контактные и прочие данные клиентов. Архивы трейдов. Описание инструментов. V>>30-40 таблиц, я же давал тебе цифры уже. ·>И что?
Что Джава не сэкономит ни йоту времени на разработку на задачах такой размерности.
V>>·>Ты уверен, что это всё требует реалтаймную заливку в транзакционную фс? V>>Я уверен, что такая размерность задачи не требует никакой джавы от слова совсем. )) ·>Не знаю, что ты понимаешь тут под "требует".
Я понимаю под этим экономию на разработке и обслуживании.
·>Джава работает прекрасно и даёт кучу бенефитов, уменьшает стоимость разработки.
Для задач уровня a+b никаких бенефитов нет.
·>Разве не прекрасно просто вызвать метод интерфейса в LL-Core сервисе, а имплементация интерфейса будет в другом DB-сервисе, который выполнит тормозной SQL? Не надо выдумывать совместимых сериализаций и протокола взаимодействия между разными языками.
RMI жрет ресурсы сам по себе, чтобы пользоваться им из узла основного сервиса. ))
Ну реально, не смешно уже. Сегодня все задачи сетевые и C++ отлично себя в этих задачах чувствует.
От совсем уж лени можно взять точно такую же CORBA, я ей пользовался в некритичных к быстродействию приложениях.
И то она гораздо легковеснее, чем RMI.
Да и вообще. В С++ другая философия. В этом языке вообще не принято создавать всякие иерархии, абстрактные базы/интерфейсы и т.д.
Это большая редкость — некий абстрактный интерфейс.
·>Сразу видишь и читаешь весь код — goto definition, find usages, и т.п. редактируешь как надо:
C CORBA аналогично, только это будет вижуал бейсик, как по мне.
V>>Такую "сложность" сейчас делают студенты на коленке на чем угодно. ·>Не надо ждать изменений от C++-икзпертов, когда java-"студентам" понадобилось внести изменение в "свою" часть.
С++-студентов тоже хватает.
V>>Потому что вес клиента и вес биржи несопоставимы. Клиентами бывают совсем маленькие брокерские конторы. Ну и ОК. ·>Так почему не Плюсы-то? Они экономят 0.00001% всех затрат что-ли?
Ну это к тебе вопрос, почему совсем небольшие конторы предпочитают Java.
V>>Обязательно. Иначе дороговизна джавы по всем своим зависимостям (ср-ва разработки + инфраструктура) — это чистой воды суровый убыток. ·>Какая инфраструктура нужна для Java? Единственное что там дорого, это IDEA (кстати, разве $300 /year*dev дорого для организации?). Ну ещё может Azul. Всё. ·>А сколько там Студия стоит?
Нисколько.
Что-то стоит только профессиональная версия и выше, но это уже для суровой командной работы ср-вами самой студии (что тоже редкость).
V>>И не надо мне про Джаву в блокноте. На ней в блокноте писать невозможно от слова совсем, это будет идиотизм, а не разработка. ·>C++ в блокноте тоже не фонтан.
Проще намного, в отсутствии иерархий.
Достаточно какой-нить Kate.
Кода всегда меньше, локальные типы можно объявить и заюзать по месту, а не искать их в других папках/файлах и т.д. и т.п.
Разнообразие функторов, декларативный биндинг и т.д. и т.п.
Кароч, надобности в навигации резко меньше.
·>А скрипты... Ну подключи groovy/javascript или просто jsr223 если так скриптов хочется.
Там, где есть выход на скрипты, там уже совсем-совсем ни джава, ни дотнет не нужны. ))
V>>Могу лишь указать основные два направления оперирования метаинформацией для С++: V>>1. Ручное перечисление полей для сериализации. Часто берут boost::serialization и просто подставляют ему свой "архив". Или вот: V>>https://github.com/the-alien/metacpp/blob/master/test/SqlTest.cpp V>>По ссылке библиотека биндинга на JS, но этот биндинг — это биндинг метаинформации, задешево еще и SQL прикрутили. )) ·>Жуть. Макросы макросами погоняют. Как и в старом добром MFC, даже CObject есть. Нового-то что?
Ну, маппинг XML для DB, как часто бывает в Джава, — это еще хуже, ИМХО.
Поэтому, указал и другой способ.
·>Вот тут, если кодогенерацией не брезговать.
А если речь о кодогенерации, то опять управляемые среды не дают профита.
V>>2. Всевозможные кодогенераторы, которые генерят акцессоры к объектам по примерно вот такому валидному (полезному) С++ исходнику: ·>Как в старом добром QT... Притом выглядит хуже, чем даже жуткий Spring data.
В Джава выглядит аналогично при использовании Hibernate или любого другого маппера по стандарту JPA. Т.е. я не вижу профита брать джаву для таких задач.
V>>Интересно, на какую букву заменить первую в "jdbc", чтобы получить нечто, что на 20 лет старше самой джавы? )) V>>И да, вот еще интересно. Я вот видел некие провайдеры jdbc, писанные как JNI-обертки не напомнишь над чем? (рука-лицо снова) ·>Они оборачивают closed source пропиетарные native only коннекторы к субд, тут тупо других нет вариантов.
Ох, наивный. ))
V>>>>А если взять дотнетный linq, то про джаву вообще вспоминать стыдно. V>>·>Да много всякого уже напридумывали, честно говоря не слежу за этим. Ещё и другие jvm языки есть, в scala вроде аналог линка. V>>В Скале нет аналога Linq, но ср-ва композиции алгоритмов не уступают как минимум С++, есть такое. ·>Scala slick?
Да ну. В таком виде и на С++ писать можно:
// SELECT ... LEFT JOIN ... ORDER BY ... LIMIT ...
val topics = T.topics.sortBy(_.created.desc)
.drop((page - 1)*topicsPerPage)
.take(topicsPerPage)
val topicsSeq = (topics leftJoin T.users on (_.author === _.id)).map {
case (t, u) => (t.id, t.title, u.login, t.created)
}.list
V>>Скала — это язык с хорошей исходной концепцией, но сильно загрязнённый артефактами вынужденной интероперабельности с джава-машинкой. ·>Что за такие артефакты? V>>Собсно, к F# аналогичные претензии. ·>К Скале претезнии обычно в том, что язык слишком перегружен фичами и они не всегда друг с другом хорошо согласуются.
Ну да. Идущие для джава-машинки фичи плохо согласуются с основной философией Скалы. ))
Здравствуйте, ·, Вы писали:
·>А то внезапно у тебя не получится сделать std::vector<MyType> и придётся лепить std::vectior<some_smart_pointer<MyType>> и прочее.
Может придётся, а может и нет, и по-умолчанию скорее нет чем да. В Java же эта индерекция будет всегда, не считая варианты с байт-буферами и прочим ручным нарезанием.
EP>>>> Собственно поэтому и извращаются на байт-буферах чтобы эти самые косвенности пересилить N>>>Да. Или на структурах, в дотнете. И будут точно так же на структурах в Java 9. EP>>О, в Java наконец появятся структуры? ·>О java 9 он вроде поторопился, фичефриз уже прошел, релизят через пол года (но пробовать можно уже сейчас), но есть планы в 10ке https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language) через года полтора-два.
Во-во, а ты спрашивал что за косвености(индерекции), вот же они:
Memory access performance and the efficiency of 'boxed' value access are a major area to be addressed by these features. 'Value Type' features and 'Generic specialization' (when applied to lists or collections) reduce memory usage, but more importantly avoid pointer indirection which typically causes a cache miss.[3][4]
Instead of a list or array of object references, pointing to data values scattered throughout memory, Project Valhalla enhancements will enable list or array values to potentially be laid out linearly—without indirection—as a consecutive block of memory.
·>В общем .net должен бежать ещё быстрее, чтоб окончательно не отстать по своим фичам.
Здравствуйте, ·, Вы писали:
V>>>>А у меня есть весьма активно наполняемая система баг-трекинга конторы с кучей программеров. Там за несколько лет ни одной ошибки выхода за границы массива, зато куча типичных логических ошибок. И на динамическом коде их намного больше, ес-но. EP>>·>И с памятью никаких проблем не было? Утечек не было? EP>>Утечки вообще не в кассу, так как возможны и в управляемых языках ·>Тут надо отличать. Логические утечки: утечки ресурсов (незакрытые файлы, невозвращённые коннекты в пул, етс), утечки данных (вечнорастущий контейнер или забитый диск) возможны вообще в любом ЯП. А я имею в виду утечки памяти на уровне самого ЯП.
На C++ тот же механизм что и для памяти, применим и для ресурсов. На управляемых языках же начинаются всякие полумеры типа using/with/try-with-resources — которые не спасают от транзитивности "быть ресурсом" и т.п. — и потерять ресурс там намного легче, что намного хуже ибо приводит к логическим ошибкам, а не просто OOM.
·>утечки данных (вечнорастущий контейнер или забитый диск) возможны вообще в любом ЯП
На C++ подобные утечки (видимо которые ты называешь "языковыми") могут быть только в случае цикла в ref-counted графе.
Да и то вопрос — если там ресурсы, это уже "языковая" утечка, или как? Ибо если ресурсы c prompt finalization то и на Java будет тот же ref-counting, только кривой
Отсутствие же утечек других родов легко гарантировать (в том смысле который ты называешь "языковым") — не используй голый new, используй RAII — и проблема решена (именно в плане "языковых" утечек). Легко верифицируется простым grep'ом (либо Clang'ом, но чуть сложнее).
Они могут лишь появится в коде с сильно кастомными структурами данных, да и то далеко не в каждой структуре данных требуется именно голый new/delete.
·>А я имею в виду утечки памяти на уровне самого ЯП.
Тут грань очень тонкая, ибо никогда не используемые данные на которые есть ссылка — это тоже утечка, и могла бы например разруливаться на уровне ЯП/компилятора (особенно если язык не полный по Тьюрингу).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>https://benchmarksgame.alioth.debian.org/u64q/java.html EP>·>В "разы", конечно, не стоит так уверенно заявлять. Тут в среднем отставание раза в 1.5-2. Притом, как я вижу, java код там написан вообще без каких-либо забот о перформансе и это простой main(), без всякого прогрева (т.е. шанса выполнить все оптимизации до начала замеров). EP>Какой прогрев, ты о чём? Ты код-то открой — там аллокаций практически нет — O(1), везде массивы byte и double. Такой код действительно будет меньше всего отставать, так как в нём нет никаких тех ужасов которыми пестрит обычный код и которые здесь обсуждаем EP>То есть вот это твоё отверждение "Тут в среднем отставание раза в 1.5-2" — это мухлёж жеж, ибо не в среднем, а в вырожденных случаях
Так в данном тесте всего в 1.2 раза медленнее. Открой другие тесты, там с мапами и прочими тасками/тредами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
EP>>То есть вот это твоё отверждение "Тут в среднем отставание раза в 1.5-2" — это мухлёж жеж, ибо не в среднем, а в вырожденных случаях ·>Так в данном тесте всего в 1.2 раза медленнее. Открой другие тесты, там с мапами и прочими тасками/тредами.
И соответственно большее отставание.
Вот в КСВ делали тест
— заменили структуры на объекты и получили 3.5х. Перетасовку на Java так никто и не показал, на C# перетасовка дала проседание > 40x. Можешь кстати на Java попробовать с перетасовкой — тоже будет приличное проседание
Здравствуйте, netch80, Вы писали:
I>>То есть, в качестве способа отличного от offheap ты привел пример offheap
N>То есть, я не приводил и даже не собирался приводить такого способа, а все идеи, что я должен был его привести — твои фантазии и капризы. Я говорил, что это таки реально используется для фактического отключения GC без его отрезания. Ровно это и ни слова больше.
Спасибо, капитан, если буквально, то offheap не отрезает GC.
Здравствуйте, netch80, Вы писали:
I>>И когда уже Джава вытеснит плюсы из обработки видео, звука, изображений ? N>Не знаю, надо на конкретные кодеки и реализации смотреть. Везде, где реализация это не C-оболочка вокруг ассемблера — шансы неплохие.
Хорошая шутка!
P.S. Я конечно надеюсь что правильно понял, что это шутка. Потому что в обратном случае это означало бы полное не понимание тобой самых базовых принципов в программирование.
Здравствуйте, vdimas, Вы писали:
V>>>Джавовский код весьма динамичный. Сплошные приведения типов и все как один — динамические. V>·>В биржевой проге? V>Да, я охотно верю, что в пути кода, обрабатывающего FIX-сообщение, нет приведений типов. Но это один процент от всего приложения, пусть и самый критичный к эффективности. В остальном его будет дофига. А еще если брать совсем остальное что ты предложил: базы, отчеты, платежи и т.д., то там в джаве динамика динамикой погоняет.
Какой динамикой? Ты о чём? Почитай учебники что-ли, хоть ту же вики:
V>>>·>Тебя куда-то заносит постоянно. Вначале в dotnet vs java запихал native, а теперь ещё и динамику. V>>>Курить, что есть динамика. V>·>В C++ есть http://en.cppreference.com/w/cpp/language/dynamic_cast . Так и запишем: "C++ — динамический язык". V>·>Что сказать-то хотел? V>Возьми огромные проекты на С++ (мильоны открытых) и поищи грепом этот dynamic_cast. В подавляющем большинстве их не встретишь ни одного. V>Сейчас вообще модно компилить с отключением RTTI. В коммерческом коде так и вовсе dynamic_cast — нонсенс.
Ты первый начал чушь пороть. Но я хоть что-то похожее на аргументы привёл. А вот ещё: DYNAMIC_DOWNCAST
Доказать-то сможшешь, что java — динамический?
V>>>Потому что уровень типизации исходника несопоставим от слова совсем. V>·>Что такое "уровень типизации"? V>Имелась ввиду статическая типизация.
предложение "Потому что статической типизации исходника несопоставим от слова совсем." тоже смысла не имеет. Что сказать-то хочешь?
V>·>Не понял, можно пример? Что мешает в java сделать так же? V>Даункасты мешают. Это просто такой принцип построения архитектуры и привычки девелоперов, что без даункаста никуда.
Так увольте вы, наконец, этих девелоперов, наймите нормальных.
V>·>Это я к тому, что наличие плохих тестов на Джава, не означает невозможность писать хорошие тесты. И наоборот. V>Я не придирался к кач-ву отдельных тестов, я же однозначно выразился — речь идёт о покрытии 100% веток кода. Т.е. речь о полноте набора тестов, принятых в мире Джавы. Сколько видел — позитивных тестов больше негативных. А их должно быть намного-намного больше. Но в Джава малость другая философия, а именно — выплюнул исключение наверх и дело с концом.
Ну покрывай сколько хочешь, хоть 101%. Причём тут исключения? Я перестал понимать о чём ты говоришь, какой-то поток ворчания.
V>·>Количество информации доступной JIT — больше, так что не всё так однозначно. V>Откуда больше?
Потому что он видит реальные данные, с которыми работает программа, наиболее частые потоки выполнения, реально используемые в данный момент классы, и т.п.
V>·>Дело не в алгоритмах, а в архитектуре. Скажем, у тебя есть какой-то контейнер с текущими сессиями клиентов. На эти самые сесси могут быть ссылки откуда-то ещё, и ещё какие-нибудь события летают, и, в итоге, надо аккуратно заботиться о времени жизни и не налажать. V>Ну вот как раз Сессия — объект самого верхнего уровня и создаётся в куче. Но таких объектов во всём приложении — просто мизерный мизер.
Текущие данные в сессии — тоже могут быть сложными объектами со сложным lifecycle.
V>Например, все справочные данные можно хранить в коллекциях по-значению.
Всяко бывает, не только справочники.
V>За время работы такие данные только добавляются, но никогда физически не удаляются (лишь помечаются как неактивные).
А почему нельзя удалить-то?
V>Справочники хранятся как сбалансированное дерево или мультииндекс, итераторы остаются валидными после добавления нового элемента.
И ради чего?
V>·>В HFT-системе (бирже, например) вполне можно обращаться к БД (но не из всех частей этой системы). V>Если часть системы — отдельный от, собственно, HFT-матчинга процесс, то и стоит рассматривать именно его — что это за процесс, какие требования и т.д. Тем более, что такие вспомогательные процессы обычно на других физических узлах исполняются.
Пусть отдельный, пусть на других узлах. И что? Почему это должно как-то серьёзно отличаться в ЯП?
V>>>>>а не в БД. Там никакая БД не справится, ес-но. V>>>·>Смотря где. V>>>В реальном HFT. V>·>Наличие реального HFT не означает отсутствие нереального HFT. V>И снова в Киеве дядька.
Моя телепатия меня всегда подводит, а ты как всегда сам слабо понимаешь о чём пишешь.
V>>>·>Вести бд счетов, движение средств, и контактные и прочие данные клиентов. Архивы трейдов. Описание инструментов. V>>>30-40 таблиц, я же давал тебе цифры уже. V>·>И что? V>Что Джава не сэкономит ни йоту времени на разработку на задачах такой размерности.
Спекуляция.
V>·>Джава работает прекрасно и даёт кучу бенефитов, уменьшает стоимость разработки. V>Для задач уровня a+b никаких бенефитов нет.
Заблуждение.
V>·>Разве не прекрасно просто вызвать метод интерфейса в LL-Core сервисе, а имплементация интерфейса будет в другом DB-сервисе, который выполнит тормозной SQL? Не надо выдумывать совместимых сериализаций и протокола взаимодействия между разными языками. V>RMI жрет ресурсы сам по себе, чтобы пользоваться им из узла основного сервиса. ))
Ну не используй RMI. У нас UDP-multicast в качестве транспорта.
V>Ну реально, не смешно уже. Сегодня все задачи сетевые и C++ отлично себя в этих задачах чувствует.
Я рад за его здоровье. Но в Java это таки проще.
V>От совсем уж лени можно взять точно такую же CORBA, я ей пользовался в некритичных к быстродействию приложениях.
CORBA вроде сдохла давно. И даже уже закопали.
V>И то она гораздо легковеснее, чем RMI.
V>Да и вообще. В С++ другая философия. В этом языке вообще не принято создавать всякие иерархии, абстрактные базы/интерфейсы и т.д. V>Это большая редкость — некий абстрактный интерфейс.
А что делать? У этого же интерфейса может быть пару других имплеметаций. Например этот же TradeReporting может в FIX-drop слать (LL-кстати).
V>·>Сразу видишь и читаешь весь код — goto definition, find usages, и т.п. редактируешь как надо: V>C CORBA аналогично, только это будет вижуал бейсик, как по мне.
V>>>Такую "сложность" сейчас делают студенты на коленке на чем угодно. V>·>Не надо ждать изменений от C++-икзпертов, когда java-"студентам" понадобилось внести изменение в "свою" часть. V>С++-студентов тоже хватает.
Студенты в C++ такое понапишут... segfault это самое удачное будет.
V>>>Потому что вес клиента и вес биржи несопоставимы. Клиентами бывают совсем маленькие брокерские конторы. Ну и ОК. V>·>Так почему не Плюсы-то? Они экономят 0.00001% всех затрат что-ли? V>Ну это к тебе вопрос, почему совсем небольшие конторы предпочитают Java.
Потому что дешевле обходится с теми же результатами. Мелким конторам приходится работать эффективнее, чтобы выживать.
V>>>Обязательно. Иначе дороговизна джавы по всем своим зависимостям (ср-ва разработки + инфраструктура) — это чистой воды суровый убыток. V>·>Какая инфраструктура нужна для Java? Единственное что там дорого, это IDEA (кстати, разве $300 /year*dev дорого для организации?). Ну ещё может Azul. Всё. V>·>А сколько там Студия стоит? V>Нисколько. V>Что-то стоит только профессиональная версия и выше, но это уже для суровой командной работы ср-вами самой студии (что тоже редкость).
Ну IDEA Community тоже бесплатна, или Эклипс. А сурово работать иногда таки приходится.
V>>>И не надо мне про Джаву в блокноте. На ней в блокноте писать невозможно от слова совсем, это будет идиотизм, а не разработка. V>·>C++ в блокноте тоже не фонтан. V>Проще намного, в отсутствии иерархий.
Опять занос какой-то... Каких ещё иерархий?
V>Достаточно какой-нить Kate. V>Кода всегда меньше, локальные типы можно объявить и заюзать по месту, а не искать их в других папках/файлах и т.д. и т.п. V>Разнообразие функторов, декларативный биндинг и т.д. и т.п. V>Кароч, надобности в навигации резко меньше.
И получаются файлики на 10000 строк. Спасибо. А если ты не знал, в одном файле можно делать множество java-классов (заметь, и .h-файлы не нужны!).
V>·>А скрипты... Ну подключи groovy/javascript или просто jsr223 если так скриптов хочется. V>Там, где есть выход на скрипты, там уже совсем-совсем ни джава, ни дотнет не нужны. ))
Я не знаю зачем ты скрипты хочешь... Но если надо — они есть и в огромном количестве. Как легко прикрутить, скажем JS к С++? Ну, чтобы можно было C++ классы использовать и всё такое?
V>·>Жуть. Макросы макросами погоняют. Как и в старом добром MFC, даже CObject есть. Нового-то что? V>Ну, маппинг XML для DB, как часто бывает в Джава, — это еще хуже, ИМХО. V>Поэтому, указал и другой способ.
А что там хуже-то? С рефлексией-то из коробки? В худшем случае аннотацию воткнуть на класс придётся.
V>·>Вот тут, если кодогенерацией не брезговать. V>А если речь о кодогенерации, то опять управляемые среды не дают профита.
Тут кодогенерация нужна на уровне исходников, чтобы в IDE работало всякое автодополнение и прочее. А так кодогенерацию можно в run-time делать (в Плюсах — невозможно).
V>>>2. Всевозможные кодогенераторы, которые генерят акцессоры к объектам по примерно вот такому валидному (полезному) С++ исходнику: V>·>Как в старом добром QT... Притом выглядит хуже, чем даже жуткий Spring data. V>В Джава выглядит аналогично при использовании Hibernate или любого другого маппера по стандарту JPA. Т.е. я не вижу профита брать джаву для таких задач.
Но ведь можно не использовать Hibernate или JPA. Так и быть, разрешу тебе и это.
V>>>Интересно, на какую букву заменить первую в "jdbc", чтобы получить нечто, что на 20 лет старше самой джавы? )) V>>>И да, вот еще интересно. Я вот видел некие провайдеры jdbc, писанные как JNI-обертки не напомнишь над чем? (рука-лицо снова) V>·>Они оборачивают closed source пропиетарные native only коннекторы к субд, тут тупо других нет вариантов. V>Ох, наивный. ))
А что тогда?
V>·>Scala slick? V>Да ну. В таком виде и на С++ писать можно: V>
V>// SELECT ... LEFT JOIN ... ORDER BY ... LIMIT ...
V>val topics = T.topics.sortBy(_.created.desc)
V> .drop((page - 1)*topicsPerPage)
V> .take(topicsPerPage)
V>val topicsSeq = (topics leftJoin T.users on (_.author === _.id)).map {
V> case (t, u) => (t.id, t.title, u.login, t.created)
V>}.list
V>
Не понял я тогда что тебе надо.
V>·>К Скале претезнии обычно в том, что язык слишком перегружен фичами и они не всегда друг с другом хорошо согласуются. V>Ну да. Идущие для джава-машинки фичи плохо согласуются с основной философией Скалы. ))
А конкретно?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>Ну если это так (кстати не уверен, но разбираться нет никакого желания), то это соответственно означает, что все эти .net core и т.п. обречены быть обрезками. Т.к. WPF — это официально часть .net. S> Это не часть, а библиотека.
Угу, libc — это тоже просто библиотека, а не часть языка. И kernel32 — это тоже просто библиотека, а не часть винды. Ну да, ну да. )))
S>Вместо WPF используется XAML
Никчемная хрень, не используемая даже про программирование под винду. Просто потому что нормальные "старые" (win32) приложения и так спокойно работают на win10, а мобильная винда мертва.
S>http://metanit.com/sharp/xamarin/2.4.php
Проприетарная хрень для мобильников, заставляющая делать интерфейс под каждую платформу отдельно (а не общий, как в нормальных кроссплатформенных gui библиотеках).
Да, и главное: даже если бы ты тут и указал бы что-то реально дельное (кстати та же avalonia выглядит вполне перспективно), то это всё равно не имело бы никакого отношения к тому факту, что .net core и т.п. — это огрызки полноценного .net.
Здравствуйте, ·, Вы писали:
_>>Говоришь максимум в 2 раза разница и потратив немного усилий её можно свести к десятку процентов? ) Ну-Ну) _>>Я вот в прошлом году делал один простенький тест для своих целей. Вот тут http://rsdn.org/forum/philosophy/6117201.1
можно увидеть упрощённую сводную табличку результатов. Там же есть ссылка на Java код данного теста (меньше 20 строчек) — покажешь как этот простенький примерчик довести до уровня быстродействия C++? ))) ·>Это же числодробилка чистейшая. Я говорю о среднем случае, для типичных задач.
Согласен что числодробилка. И согласен что в среднем по приложению будет совсем не такое громадное отставание, а как ты и говорил в пару раз. Но как на счёт упомянутых тобой небольших усилий, с помощью которых можно свести отставание к десятку процентов? ) Какая у нас будет оптимизация в случае данного кода? )))
·>Да и кстати C++ no-simd как раз в 2 раза быстрее таки. JIT похоже не умеет simd.
Насколько я слышал умеет, но не для таких целей (автовекторизацию циклов действительно не умеет). Но как бы это не оправдание для отставания, как ты понимаешь. )))
·>ИЧСХ — c# оказался ещё медленнее.
Да, причём совершенно неожиданно для меня. Потому что по идее никаких предпосылок для этого нет. Ведь как язык то C# всё же получше. И никакого escape-анализа и т.п. тут по идее не возникает. Но практика вот показывает такое...
Здравствуйте, netch80, Вы писали:
N>>>Для Java тут может потребоваться финт, обратный type erasure, но если мы говорим, как раньше в треде, про сортировку int[], то там и компаратор тривиальный, и доступ. EP>>Не, тут я про общий случай. Если на Java взять сортировку прибитую к int[], да ещё и без компаратора — то там никаких косвеностей нет, и действительно будет быстро. N>А не в общем случае надо смотреть, что JIT умеет, а не что кажется до его включения.
То что он умеет это как раз понятно. Также понятно то что для общего случая получается ерунда по построению, из-за косвеностей, который JIT может убрать только в редких случаях типа escape analysis.
N>Ну я в этих спецолимпиадах участвовать не хочу. А аналоги таких действий мы успешно реализуем. Да, громоздко. Но работает.
Так о том и речь что громоздко, к этому и претензия. Одна из задач языков программирования заключается как раз в том чтобы эту громоздкость убирать и подниматься на более высокий уровень абстракции, а не заставлять нарезать байт-буфера вручную
EP>>Тогда что имелось в виду вот здесь: EP>>
N>>>соответственно, свалиться в плохой случай ей в разы легче.
EP>>Когда с одной стороны worst-case O(N*log(N)), а с другой O(N*N)? N>Плохой случай для introsort это когда она исчерпала бюджет рекурсии и переключается на heapsort. Я именно его имел в виду. А с тем, что данный sort рекурсию ведёт только налево — попасть в него ну очень легко.
В какую сторону ведётся рекурсия это вообще не причём, и на попадание в плохой случай никак не влияет. Это влияет только на глубину стэка. То есть выбирая меньшую часть для рекурсии можно получить логарифмическую гарантию по глубине стэка, но на сложность алгоритма по времени это не влияет (на шансы попадания в плохой квадратичный случай).
И Степанов знал про этот трюк, так как это всё было описано в оригинальной статье Хоара. И собственно в тех случаях когда он реализует именно quicksort — он это использует. Для introsort же видимо не использует потому что там и так есть гарантия на логарифмическую глубину стэка, поэтому можно убрать лишний условный переход
На плохие случаи например влияет правильный выбор алгоритма partition — например алгоритм Ломуто даёт более частые вырождения чем алгоритм Хоара.
N>Известный плохой случай для quicksort без intro — сейчас обходится сразу несколькими методами, банальными и не очень — начиная со случайного выбора разделяющего элемента (теоретически некошерно, практически же работает в 100% случаев), и вплоть до жёсткой (увеличение затрат в 1.5-2 раза), но железобетонно работающей медианы медиан. Можно делать и комбинированно — случайным до исчерпания бюджета, медиана медиан — после.
Медиана медиан имеет смысл только в комбинации, иначе introsort (которая комбинация) её спокойно обойдёт.
Здравствуйте, ·, Вы писали:
V>>>>Джавовский код весьма динамичный. Сплошные приведения типов и все как один — динамические. V>>·>В биржевой проге? V>>Да, я охотно верю, что в пути кода, обрабатывающего FIX-сообщение, нет приведений типов. Но это один процент от всего приложения, пусть и самый критичный к эффективности. В остальном его будет дофига. А еще если брать совсем остальное что ты предложил: базы, отчеты, платежи и т.д., то там в джаве динамика динамикой погоняет. ·>Какой динамикой? Ты о чём? Почитай учебники что-ли, хоть ту же вики: ·>
·>... ·>Ты первый начал чушь пороть. Но я хоть что-то похожее на аргументы привёл. А вот ещё: DYNAMIC_DOWNCAST ·>Доказать-то сможшешь, что java — динамический?
Язык со статической типизацией. Но даже на статическом языке можно переходить в динамику, из чего вытекает меньшее количество статических проверок.
Утрированный пример: something.call("function_name"); — ошибка в имени функции вылезет только в runtime даже в языке со статической типизацией.
Вещей типа вылета pure virtual call в рантайме при статическом полиморфизме нет. Они появляются при переходе на динамические конструкции.
Чем больше типов стирается, тем меньше ошибок может поймать компилятор. Например если использовать везде штуки типа boost::any — то и ошибки будут рантаймовые.
Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно.
·>А так кодогенерацию можно в run-time делать (в Плюсах — невозможно).
Здравствуйте, Ikemefula, Вы писали:
I>>>Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код. У тебя даже тупой проход по массиву интов на сишном коде даст вопиющую разницу. EP>>Нет, не даст — на уровне массива интов отличия как раз непринципиальные. I>Вообще то разница уже видна
Сколько? Десятки процентов? Я же говорю, не принципиально. Может быть конечно и больше из-за вещей типа авто-векторизации (а иногда и авто-параллезации) — но этот козырь я не использую — даю так сказать фору, но даже с этой форой на коде отличным от работающего с массивами int'ов получаем существенное проседание.
Вот кстати пример в тему — взяли сортировку массива int64, с прибитыми гвоздями типами и компаратором — на C++ и Java сделали практически идентичный код (с поправкой на отсутствие указателей), и произвели замер: 36:16
В итоге получили как раз разницу в те самые десятки процентов
I>>>Хочешь перформанс — есть только Си и тот без плюсов. EP>>Нет, наоборот. I>Если наоборот, то надо учесть, что современный ++ осваивают единицы, остальные только думают что освоили или просто не заморачиваются на этом.
Это же совсем другое утверждение нежели "xочешь перформанс — есть только Си и тот без плюсов"
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>А то внезапно у тебя не получится сделать std::vector<MyType> и придётся лепить std::vectior<some_smart_pointer<MyType>> и прочее. EP>Может придётся, а может и нет, и по-умолчанию скорее нет чем да. В Java же эта индерекция будет всегда, не считая варианты с байт-буферами и прочим ручным нарезанием.
Но далеко не всегда эта индирекция будет создавать хоть какие-то заметные проблемы.
EP>>>О, в Java наконец появятся структуры? EP>·>О java 9 он вроде поторопился, фичефриз уже прошел, релизят через пол года (но пробовать можно уже сейчас), но есть планы в 10ке https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language) через года полтора-два. EP>Во-во, а ты спрашивал что за косвености(индерекции), вот же они:
Я вроде и не спрашивал, ты меня с кем-то путаешь. Я знаю что эти индирекции создают перф проблемы. Однако, не всегда эти проблемы заметны. Там где эти проблемы заметны — можно пофиксить, да, не так красиво как со структурами или подобным, но можно.
EP>·>В общем .net должен бежать ещё быстрее, чтоб окончательно не отстать по своим фичам. EP>Как язык C# по фичам давно обогнал Java.
А толку-то... И Scala обогала, и python, и Rust, и Go, и куча менее известных языков, а Perl6 обогнал их всех вместе взятых, но фичи это ещё не всё.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
