Здравствуйте, ·, Вы писали:
V>>·>Блин, я, видимо, неоднозначно выразился. Под утечкой я не утечку памяти имел в виду, а логическую утечку данных или ссылок на них из контекста. V>>Я прекрасно понял и поэтому сослался на статическую типизацию того же std::vector<>. V>>В общем, поскольку ты не захотел на него посмотреть, скопирую его объявление сюда сугубо для истории аргументов: ·>Я знаю об аллокаторах. Говорил бы прямо, а всё то какими-то загадками и увёртками, подловить пытаешься.
Подловить?
Мне оно и даром не приснилось, я русским по белому написал, что я от тебя хотел:
ты тут приводил как аргумент std::vector<>, посмотри на все типы-параметры этого шаблонного класса.
Достаточно было вбить в гугл "std::vector" и по первой же ссылке обнаружить:
template<
class T,
classAllocator = std::allocator<T>
> class vector;
V>>Т.е., определив через typedef некий "региональные вектор": ·>А что мне помешает, передать, например, ссылку/указатель на элемент вектора куда-нибудь?
Ну тебе же ничто не помешало скипнуть заранее данный ответ на этот вопрос:
Такая техника работает для любых пользовательских типов в т.ч.
V>>Увы, увы, никакой "true agile" в таких областях IT не живет, там обитает только водопад и отсутствие внезапности. ·>В LMAX живёт. Релизы каждые две недели, все всё коммитят сразу в master. Кстати, java как раз очень способствует agile.
Вот поэтому такие тормоза.
V>>Там когда что-то меняется — то это совсем из-за сдвигов тектонического масштаба. Например, в Windows 8 и Server 2012 появилось новое АПИ Registered IO. Но это в любом случае голову включать надо и смотреть/экспериментировать — будут ли полезные плюшки для конкретного кейза или нет. ·>Причём тут API. Может поменяться бизнес-логика.
В сетевом слое? Или в стандартах FIX?
·>Кстати, я не даром поменял сабж. Я говорю о разных приложениях, не только HFT.
Как удобно-то! Но коллег изволишь ругать, когда они тебе разные примеры приводят.
Ай, молодца!
V>>·>Согласен. Но я, надеюсь, что ты не будешь спорить с тем, что управление памятью значительно влияет на структуру приложения? V>>Если речь об эффективности? Ес-но. ·>Эффективности чего? Проиводительности — нет, пусть это не будет первоочередным приоритетом.
Пусть мы вообще "в стол" программы писать будем. Вот так будет легко и просто обсуждать. А главное, можно будет делать какие угодно предположения и выводы, верно?
V>>Остальное ложно, бо есть такая подмеченная фигня — люди с опытом в управляемых средах поначалу испытывают трудности в С++ в определении иерархии владения. )) Городят много shared_ptr на ровном месте, ну просто тоннами. Через год уже смотришь — всё прошло. Нужные навыки въедаются в мозжечок и более не требуют мыслительных затрат. ·>Может быть. Именно потому что думает только мозжечок, мало кто пишет, скажем, веб-приложение на Плюсах.
На плюсах вообще мало кто пишет и как следствие, все в один голос утверждают, что средний уровень программиста резко упал за последние лет 15.
Но веб-приложений на плюсах дохрена, ес-но. И что самое прикольное — год от года их всё больше.
Были грандиозные забеги, так вот, веб-приложухи на плюсовых фреймворках рвут как тузик грелку вообще любые управляемые или скриптовые многократно.
Кому надо — пользуется. Кому не надо — нет. Какие проблемы-то?
V>>·>Даже в Яве управление любыми ресурсами (всякими там соединениями, открытыми файлами, транзакциями, етс) вечная беда V>>В C# есть using(IDisposable), а в плюсах так и вовсе RAII — наше фсё. )) ·>Ну в java есть try(AutoCloseable), не велика разница.
Угу, появилось когда? В 2011-м? Когда уже спасибо не надо? ))
·>Это тривиальный случай, если ресурс хорошо укладывается в синтаксический скоуп. Но когда создание отделено от освобождения (т.е. не on-stack переменная в терминах C++), то начинается шаманство.
Зато в С++ не начинается при разделяемом владении ввиду гарантированной своевременной финализации.
V>>·>Вот... А java — пофиг, пиши как пишется и не надо заботиться об этих алгоритмах, ибо он один единственный — gc. V>>Но именно в Джава пулы объектов сверх-популярны. Как так? ·>Кто тебе это сказал, что популярны?
Более опытные товарищи в Джаве.
Которые реально смотрят на мир, без вот этих розовых очков.
V>>·>А в яве — никогда V>>О чем и речь. Потому что низзя. ·>Можно, но нафиг нужно?
V>>Конечно быстрее, тем более, что дефолный хип в С++ — он многопоточный и вызывает конфликты при аллокации/деаллокации. Но как раз спасает то, что в типичном С++-приложении во многие разы меньше операций выделений памяти (я же уже расписывал — почему). ·>Практически любой контейнер — выделение памяти в куче.
Характер выделений там однократный.
Иначе берут какой-нить аллокатор на основе пула.
·>А если попытаться замутить что-то с иммутабельными объектами...
То доступ к глобальным объектам в С++ — это прямая адресация, в отличие от косвенной в джаве.
V>>Большинство операций по выделению памяти в С++ можно отнести к разряду "однократных". Вот, подключились к бирже, у нас образовался объект "Сессия", отключились — исчез. По сравнению с десятками тыщ перемалываемых этой сессией событий в секунду (одиночный фид даёт до 40 тыс событий в секунду на некоторых биржах, а фидов может быть много), частоту событий создания/удаления объектов верхнего уровня (Сессий) можно принять нулевой. ·>На Java пишут точно так же. Не понимаю что тут особого.
На джава постоянно создают объекты в куче.
V>>В общем, в специфике С++ для 99% сценариев самописные аллокаторы нафик не нужны (для объекта-Сессии), но иногда возможность их использовать очень даже в кассу (для объектов-сообщений). ·>Ээээ. Зачем? Чем что-то типа преаллоцированного во время создания сессии List<Message> плохо?
А если мне надо кучей ордеров оперировать одновременно?
Ну и за раз из сокета можем принять несколько сотен сообщений из 10-гигабитной картейки.
V>>Весь твой TLAB — это один из объектов, хранимых в TLS, не более того. V>>Вернее, в TLS хранится указатель на TLAB. ·>Который именно TLS?
А другого механизма не существует.
·>Доказать можешь свою фантазию?
Мне показалось или ты опять сделал некое утверждение, ась?
Кароч, сформулируй СВОЁ утверждение относительно TLAB таким образом, чтобы мне было удобно на него потом ссылаться, т.е. тыкать тебя в него, когда тебе опять захочется похамить.
Здравствуйте, ·, Вы писали:
V>>Да ладно, если тебе письмо вовремя не дошло, то это редко бывает проблемой. А если ордера вовремя не снял, то потерять десятки-сотни тыщ за один день можно запросто. ·>Но не из-за JPG иконки, инфа 146%.
Теперь ты видишь, как мне сложно? ))
Десяток постов пришлось потратить на то, чтобы ты и сам понял, что не в нейтивном коде обычно засада.
V>>>>·>Потом, сравни JPG-кодек, созданный много лет назад и не меняющийся с тех пор, отлаженный, перелопаченный просмотренный и тп., и какую-нибудь очередную секретную алго-фичу, которую нужно срочно запилить до вчера. V>>>>Во-первых, сам JPEG меняется, как и MPEG. Во-вторых, реализации меняются. V>>·>Когда последний раз менялся стандарт JPEG? И сколько раз за свою жизнь? V>>JPEG-LS, JPEG XR — относительно новые. ·>Цифирки назови.
42
·>И сравни хотя бы с количеством композиций базовых стратегий/операций/условий и как часто они меняются.
Не важно. Потенциально-опасного кода в самой композиции нет.
V>>·>Ты среднюю температуру по больнице посчитай. И как скоро и как часто выходят патчи после первой версии какой-либо игры. V>>Ну вот как раз в данных и патчат более всего. ·>Хотя да, согласен. В игромире тоже десяток игровых движков, а игра это по сути скрипты, да текстуры, а нативного кода пишут всё меньше, везде дураки — нет бы написали на Плюсах и порвали бы всех, ведь там библиотеки под все случаи жизни.
Ну да. Типичная современная игра на каком-нить движке — это миллионы строк исходника движка и десяток тыщ строк сриптов.
Именно такие игры и рвут всех, не знаю, чего ты так разбушевался-то...
V>>Возможно. Но на практике проход по памяти в С++ случается на порядки реже, чем ошибки типизации в сильно динамическом джавовском коде. ·>Мнение. С док-вами этого фактоида возникнут трудности, не так ли?
Так и ты себя не утруждаешь от слова совсем. А у меня есть весьма активно наполняемая система баг-трекинга конторы с кучей программеров. Там за несколько лет ни одной ошибки выхода за границы массива, зато куча типичных логических ошибок. И на динамическом коде их намного больше, ес-но.
V>>·>В общем какая-то гипотетическая ситуация с гипотетическими проблемами, не хочу фантазировать и спекулировать. V>>Ну а я тебе случай из реальной жизни привожу. V>>Ты еще попробуй дозвонись, когда на бирже паника. ·>В таких ситуациях проблемы языка на сотом месте. Начинать надо с качества QA, а не с того, что там какие-то проблемы с типами.
Эротические фантазии поперли.
Я еще ни разу не видел, чтобы под Джаву писали в 10 раз больше тестов, чем исходного кода. А это вообще минимальная граница, с которой только можно начинать хоть как-то полагаться на тестирование. На типичные джавовские юнит-тесты без слёз не взглянешь.
V>>Ну т.е. доступ к элементам вектора по индексу — это что-то из ряда вон выходящее и причина обратить внимание на происходящее. ·>Так на практике элементарные случаи типа "for(Elem elem : elemList)" на раз оптимайзятся RangeCheckElimination.
Я привел аргументы, почему явным образом итераторы используются редко.
Так у тебя в ответ на это в Киеве дядька.
·>А в нетривиальных случаях, когда RangeCheckElimination ниасиливает — человеку тоже асилить непросто. Хотя да, ведь зачем напрягать компьютер, девушки С++-сники хорошо справляются.
Открой для себя т.н. "алгоритмы" буста и STL. Прекрасно компьютер справляется. Просто JIT-у некогда справляться, в отличие от полноценного оптимизатора С++.
V>>>>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end(). V>>·>В каких? Кто сравнивает? std::vector — не сравнивает.
template<class SinglePassRange, class UnaryPredicate>
typename range_difference<const SinglePassRange>::type
count_if(const SinglePassRange& rng, UnaryPredicate pred);
count_if returns the number of elements x in rng where pred(x) is true.
template<
class SinglePassRange,
class UnaryFunction
>
UnaryFunction for_each(SinglePassRange& rng, UnaryFunction fun);
for_each traverses forward through rng and for each element x it invokes fun(x).
V>>Любой алгоритм сравнивает два итератора. ·>Ну т.е. явно делает range check (который, кстати, может и остаться в runtime, в отличие от RangeCheckElimination).
OMG ))
Ты эта... В общем, хоть бы предварительно почитал бы, о чем пишешь.
Твой RangeCheckElimination убирает ДОПОЛНИТЕЛЬНУЮ (т.е. избыточную) сугубо джавовскую проверку. Но основная никуда не девается, ес-но.
В приведенных мною примерах (там по ссылке их множество) избыточной проверки и не было никогда.
V>>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы. V>>Дык, уровень косвенности на единицу меньше. ·>Расшифруй.
Ы?
V>>·>Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы. V>>90% кода типичной HFT-системы не требует вообще ничего из того, что дают управляемые среды. ·>Неправда. Скажем, в HFT-системе может быть несколько web-интерфейсов, работа с субд, гейты с разными WebService/Rest. А ещё, скажем, может быть инфраструктура мониторинга, тестирования, деплоймента и т.п. Ты правда считаешь, что native для этого лучше, чем managed??
Конечно.
В реалтайме идёт заливка в файл в транзакционную файловую систему, а не в БД. Там никакая БД не справится, ес-но. Ес-но это всё происходит через нейтив. Периодически в БД сливают только снапшоты. Это другой процесс/узел, ему надо проводить бешеную агрегацию исходных данных, там ничего кроме нейтива не выживает. Инфраструктура мониторинга так и работает, как отдельный узел, куда в бешеном режиме сливаются вообще все данные и на этом узле обычно и происходит та самая суровая агрегация и потом неторопливая выдача данных по запросам в XML или другом текстовом формате. В том числе клиентам на Джаве, ес-но.
Инфраструктура тестирования/сертифицирования, все эти эмуляторы — это нейтивное АПИ с выходом на скрипт, там нечего делать никакой джаве, потому что требуется работать БЕЗ развернутых ср-в разработки, т.е. подправил скрипт — тут же запустил. Деплойментом тоже обычно занимаются скриптовые утилиты (сейчас их много, в т.ч. писаных на руби), джавовские тут самые неуниверсальные, хорошо работают только для экосистемы джавы, а не гетерогенность сценария.
Кароч, добро пожаловать в реальный мир, Нео. ))
V>>А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но. ·>Верно. Но обратное-то не верно. Бывают и не сложные системы, которые тоже могут быть требовать.
Ну вот ты снова спутал необходимое с достаточным и проиграл. ))
V>>>>Пол-сотни — это ни о чем от слова совсем. Когда в базе или в прикладном коде одних прикладных запросов несколько тысяч, вот это уже хоть какая-то информационная сложность. V>>·>И даже с этой полусотней работать проще из Java чем из native. V>>Давнее заблуждение, родом из 95-го года, когда объем библиотек в поставке джавы натурально поражал воображение. )) V>>Сейчас библиотек под С++ уже просто тонны под все случаи жизни. ·>Ах, ну да-да, ведь все те джавовские библиотеки — испарились. И с 95-го запретили писать новые злобные С++-ники.
Увы, в плане доступа к БД ничего круче Hibernate джава-сообщество до сих пор не родило, остальное — это более простые ORM-мапперы. Кароч, тут в джаве творится сплошное позорище какое-то. В плюсах давно есть намного более мощные, чем Hibernate системы. Ну т.е. действительно на порядки более мощные и удобные. А уж более простых мапперов/хелперов — как собак нерезанных.
А если взять дотнетный linq, то про джаву вообще вспоминать стыдно.
========
Еще, или ну его?
Или ты решил уйти с Джавы и выбить из коллег все аргументы в пользу такого решения? ))
Здравствуйте, Ikemefula, Вы писали:
I>Ты не заметил, что здесь противоречие ? quicksort в чистом виде числодробилка.
Это ж какие числа она дробит? Сравнение ключей это малая и в принципе не оптимизируемая часть работы. А так — quicksort это чистейшая управляющая, а не вычислительная, задача, причём фактически RAM-bound. Это не формат работы "числодробилок".
I> Отсюда ясно, что сколько перформанса не дай, всё равно мало. Ассемблерными вставками вылизать трудно прежде всего потому, что это надо делать под разные процессоры, не говоря про семейства процессоров. I>Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.
Сишный компайлер как раз может не понять, что шаблон поведения включает в себя движение назад по памяти, а средства типа JVM вполне способны это увидеть и вставить prefetch на 1-2 предшествующих строки кэша.
Здравствуйте, ·, Вы писали:
I>>И это оно же. Если речь про перформанс, то такие методы вообще говоря и должны быть платформенно-зависимым, это в чистом виде числодробилка. ·>Не должны (но могут, если язык недостаточно быстр). Как quicksort зависит от платформы? quicksort не числодробилка. Почему реализация std::sort в C++ не зависит от платформы? Могли бы уж вылизать ассемблерными вставками...
В случае, когда даже подставление компаратора выливается неизвестно во что?
Здравствуйте, Ikemefula, Вы писали:
I>>>Собтсвенно именно это и есть основание для применения off-heap решений. Гарантии вот этой бесплатности надо обеспечить руками за счет исключения гц вообще, тотально I>·>off-heap решения для огромных куч, для старого поколения, а не для молодого. Кстати, с развитием GC необходимость off-heap решений падает.
I> Ты в одном сообщении умудряешься сам себе противоречить. Если твоя софтина не вылазит за пределы нулевого поколения, ей off heap не нужен. off heap нужен не для поколений, а для того, что бы gc бегал исключительно по объектам молодого поколения. Для этого надо руками гарантировать небольшое количество выделений в молодом поколении.
Не нужно такого гарантировать, можно вообще ничего не выделять после прогрева и принудительного GC перед началом основной работы. А выделения в G0 сами по себе возникнут, к сожалению.
I>Как только ты перебрал определенный лимит, часть объектов уходит в старое поколение и ты на это никак повлиять не можешь
I>То есть, off-heap нужен для того, что бы исключить gc по максимуму
Не так. Задача — исключить тормозную часть GC, которая на текущих реализациях возникает в основном по старому поколению. Для этого можно убрать новые аллокации вообще, или увести их из managed heap, или заменить алгоритм GC.
Последний вариант был бы самым вкусным, тем более, что инкрементальный GC даже с дефрагментацией это сейчас задача студенческого уровня, но за счёт сильно бо́льших затрат памяти и чистого времени процессора этот вариант невкусен авторам VM. Хотя уже появляются realtime VM такой нацеленности...
Здравствуйте, Ikemefula, Вы писали:
I>И это оно же. Если речь про перформанс, то такие методы вообще говоря и должны быть платформенно-зависимым, это в чистом виде числодробилка. I>То есть, любая самая распрекрасная реализация числодробилки на менеджед сливает нативному коду. I> Как бы ты ни старался, менеджед код не может и никогда не будет работать так же быстро, как и нативный. У него особенность — он менеджед аккурат за счет того, что перформанс на втором месте.
Эти слова открыто противоречат идее JIT.
I>Более того, с т.з. быстродействия, строки и массивы как раз и определяют всё, вообще всё — 80-90% операций происходит с этими двумя типами. I>Особенно критично для маршалинга, интеропа, больших размеров данных и тд.
Но в теме HFT, которую обсуждает твой оппонент, это всё как раз мало значимо, и в сортировке — тоже.
I>Это было известно примерно в 2001м году, когда были опубликованы исходники Rotor. Ты как то запоздало срываешь покровы
Если речь про мелкомягкую VM с лицензией, которая делает её бесполезной, то я таки не понимаю, при чём она. Можешь подробнее?
Здравствуйте, Serginio1, Вы писали:
S> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
Судя по его словам, у него C++, C++/CLI и C#. Так что реально 3 языка, хоть и достаточно близких.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, netch80, Вы писали:
N>>Чуть более, чем все "софтины" на 17GB это нечто из полусотни, если не больше, отдельных цельных компонент, как с точки зрения разработки, так и с точки зрения использования. Если они внутренние, могут быть тонкие зависимости "buka 1.3.14 требует zuka от 2.7.25 до 2.8.4", но они решаются своими инсталляторами, и обновления загружают только часть из этих правок. N>>В цельную, неразделимую, софтину на 17GB, даже если это почти всё — толстые данные типа карт, я не верю при всём желании.
Ops>А если "толстые данные в виде текстур", все равно не веришь? У меня для тебя плохие новости.
Исключительные и маргинальные ситуации есть всегда. (На будущее: все мои (и не только) "никогда", "всегда" и т.п. воспринимать только как "95-99%", это относится и к данному утверждению!) И поверить в пакет текстур на 17GB я могу, если есть такая цель. Но, боюсь, это таки действительно плохие новости, о том, что авторы пакетирования не думают головой Если бы думали — нарезали бы.
(Хотя и в этом случае им никто не мешает наготовить дельта-пакетов.)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>Конечно. Но я немного о других вопросах говорил. И даже не о соотношение полиморфных/неполиморфных объектов в классическом ООП коде. Пускай даже стоит задача создать массив неполиморфных (во всяком случае на данном этапе разработки). Вопрос, а какой инструмент возьмёт для этого средний C# программист (это тот самый, который занимается ваянием формочек и никогда не интересовался особенностями работы кэша современных процессоров)? Ты уверен, что он выберет структурку? ) EP>Думаю вероятнее что средний ваятель формочек на C# выберет struct нежели средний ваятель формочек(или какой там аналог) на Java нарежет вручную память на структуры.
Безусловно. ) Но ты же понимаешь, что в реальности в большинстве случаев не будет ни того, ни другого. Будет просто обычный класс (реализующий при этом ещё и кучу каких-нибудь интерфейсов), а в случае возникновения тормозов появится запрос на новое железо (а не на оптимизацию кода). Это же мир Java/C#, а не C++. Так вот этом мире решения на Java могут начать тормозить чуть позже аналогов на C#, как раз за счёт интересных приём в их ВМ.
А если углубляться в оптимизацию, то конечно же всё становится совсем по другому и тут Java безусловно слабее. Только вот это не характерный путь в данной области индустрии. Более того, если уж уходить на уровень железа, то непонятно зачем останавливаться на C# (такая слабая полумера) — тогда уж есть смысл брать максимально подходящий для этого инструмент (типа C++).
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>>·>java native тоже было, см. GCJ, но померло, ибо не нужен, как оказалось, JIT мало в чём уступает AOT. Если понадобится — возродят, проблем нет. S>>>> .Net Native хорош для мобильных устройств. На яблоках кстати Java нет, а .Net есть. S>>·>А это что? http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html S>>·>Блин, урезанную java вон на банковских и SIM-картах запускают, а тут мобилы многоядерные... S>> Которые взрыватюся ·>А ты не пори чушь, что "На яблоках кстати Java нет, а .Net есть.", и увиливать не придётся.
Ну заметь яблоки меньше взрываются. На самом деле смысл в .Net Native не только в скорости и меньше расхода батареи, но и главное это обфускация.
И распространение приложений только через магазин. С привязкой к телефону. S>> Ну и какие там задачи решают на симкартах? ·>Я не интересовался.
Главное, что бы было.
S>> В .Net може есть https://ru.wikipedia.org/wiki/.NET_Micro_Framework ·>Это аналог https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition , Java Card ещё микрее.
Только непонятно зачем.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Serginio1, Вы писали:
S>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
N>Судя по его словам, у него C++, C++/CLI и C#. Так что реально 3 языка, хоть и достаточно близких.
Но если ты на них постоянно пишешь, то разницы особой нет. Мне пришлось писать на С++, полсе C# он прекрасно изучается.
Просто нужна постоянная практика. У меня 1С (7,8), С++, C#, JavaScript, TypeScript, XAML.
Постоянно приходится учиться.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
_>>Я смотрю тут дискуссия упёрлась во вроде как парадокс. С одной стороны C# как язык очевидно лучше Java, и просто сам по себе и с точки зрения потенциальной оптимизации. Это факт. А с другой стороны на практике Java показывает лучшие результаты и индустрия явно выбирает Java. Это тоже факт. I>Индустрия выбирает открытые технологии. Упоминаемый здесь elasticsearch как раз такой, и основан на lucene, который с 1999 снова такой же — открытый. I>Надо только добавить к твоим высказывания, что распрекрасную джаву очень сильно теснят всякие тормозные Python, PHP и даже JS. У них тоже особо серьезный эскейп анализ ?
"Python, PHP и даже JS" (а так же ещё куча подобных скриптовых языков, включая даже древний Perl) теснят Java/C# не вообще везде, а исключительно в одной специфической области — в написание серверных скриптов для веба. В той самой области, в которой изначально всю основную работу делает давным давно написанный нативный код (http-демоны, СУБД, нативные библиотеки и интерпретаторы для этих языков), а указанные скрипты являются всего лишь тонким слоем клея, задающего логику работы конкретного сайта. Быстродействие для таких задач не принципиально в 99% случаев, а для оставшегося одного процента (всякие там гуглы, яндексы, социальные сети и т.п. высоконагруженный веб) выбирают как раз между Java или вообще C++.
Но кроме веб'а есть ещё очень много разных областей. И в большинстве из них (включая обсуждаемые тут движки бирж и т.п.) даже не слышали про всякие там php и т.п. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Я смотрю тут дискуссия упёрлась во вроде как парадокс. С одной стороны C# как язык очевидно лучше Java, и просто сам по себе и с точки зрения потенциальной оптимизации. Это факт. А с другой стороны на практике Java показывает лучшие результаты и индустрия явно выбирает Java. Это тоже факт. I>>Индустрия выбирает открытые технологии. Упоминаемый здесь elasticsearch как раз такой, и основан на lucene, который с 1999 снова такой же — открытый. I>>Надо только добавить к твоим высказывания, что распрекрасную джаву очень сильно теснят всякие тормозные Python, PHP и даже JS. У них тоже особо серьезный эскейп анализ ?
_>"Python, PHP и даже JS" (а так же ещё куча подобных скриптовых языков, включая даже древний Perl) теснят Java/C# не вообще везде, а исключительно в одной специфической области — в написание серверных скриптов для веба. В той самой области, в которой изначально всю основную работу делает давным давно написанный нативный код (http-демоны, СУБД, нативные библиотеки и интерпретаторы для этих языков), а указанные скрипты являются всего лишь тонким слоем клея, задающего логику работы конкретного сайта. Быстродействие для таких задач не принципиально в 99% случаев, а для оставшегося одного процента (всякие там гуглы, яндексы, социальные сети и т.п. высоконагруженный веб) выбирают как раз между Java или вообще C++.
_>Но кроме веб'а есть ещё очень много разных областей. И в большинстве из них (включая обсуждаемые тут движки бирж и т.п.) даже не слышали про всякие там php и т.п. )))
Здравствуйте, vdimas, Вы писали:
V>Нет никакого противоречия. Виндовый дотнет быстрее джавы, но линуховый не быстрее. Поэтому, если брать линуха, то дотнет не даёт никаких плюшек.
Линуксового дотнета вообще пока нет в природе. Совсем недавно появился некий нестабильный обрезок, который возможно пойдёт для специфических целей.
_>>который при срабатывание (абсолютно не гарантированном, но всё же) позволяет достигать даже большей чем у C# локальности (прямо как у правильного C++ кода). V>Это рассуждения вникуда. Дотнет изначально поставлялся с офф-лайн компилятором в нейтив. Тут вся претензия к нему, что хороший оптимизатор этому компилятору прикрутили вот только в 2012-м.
До сих пор не прикрутили. Если уж ты сравниваешь с C++. )))
_>>Более того, там даже есть парочка мелких забавных трюков, которые не реализуемы (в смысле автоматически, компилятором, — руками то можно что угодно) даже на C++. V>Ну это грубая реклама уже. )) V>На С++ реализуемы очень многие трюки, которые никакому хот-споту и не снились. V>Просто потому, что на сегодня во всей индустрии не существует более продвинутых в плане оптимизации компиляторов, чем компиляторы С++.
Ого, убеждать меня в преимуществах C++ — такого на этом форуме кажется ещё не было. Ну давай попробуем, всегда интересен новый опыт. )))
Если же говорить о конкретике... Расскажи о реализации компилятором C++ возможности предсказания выбора нужной виртуальной функции на основе статистики по текущим данным (скажем в полиморфном массиве).
_>>Естественно в целом это не позволяет Java коду обходить C++, но сам факт любопытен. Ну а уж помочь обогнать обычный (не оптимизированный специально) C# код это позволяет без проблем. V>А мужики-то и не знают! )) V>И где ты эту фантастику берешь?
Это не фантастика, а суровая реальность. )
_>>Т.е. в итоге у нас получается такой расклад: _>>1. Пишем канонический код на C++ и получаем бесплатно гарантированное (ну если правильные опции компилятора стоят) максимальной быстродействие. _>>2. Пишем канонический код на Java и есть шанс, что после прогрева он тоже будет работать довольно шустро. Ну а если нужны гарантии, то надо уже писать свою ВМ под конкретную узкую задачу. Что впрочем тоже не проблема в Java мире, благодаря открытости данной платформы, и вполне применяется (в той теме были ссылки). _>>3. Пишем канонический код на C# и получаем тормознутый результат. Плюс есть возможность заморочиться и написать более менее оптимизированный код (только структуры, unsafe операции, своё выделение памяти и т.п.), но тогда требуется соответствующая квалификация и теряется большая часть смысла от управляемой платформы (тогда уж лучше сразу на C++ писать). V>Ясно, смешались в кучу кони-люди. )) V>На самом деле в итоге у нас получается такой расклад: V>- хейтеры MS; V>- все остальные. V>Хейтеры MS согласны работать только на Linux, все остальные согласны на что угодно, даже на FreeBSD, Windows, iOS или SunOS. V>Потому что хейтеры MS собрались в кучку сугубо из любителей Linux, ну вот просто Windows у них исторический враг #1, бо если бы не Windows, вот уж они бы тогда показали! ))
Смешиваешь тут только ты. Затаскивая зачем-то в разговор об инструментах разработки древний холивар о разных ОС. Нет что ли аргументов непосредственно по делу и хочется замылить дискуссию это темой?
_>>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8). V>Никакому Net Native никакой JS никуда не наступает и близко. И не наступит никогда, ес-но, пока речь будет идти о JIT-компиляции.
Для начала пускай "Net Native" займёт хотя быть один процент от и так небольшой ниши самого .net'a. ))) Тогда можно будет начинать упоминать его в спорах. )
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, vdimas, Вы писали:
V>>Нет никакого противоречия. Виндовый дотнет быстрее джавы, но линуховый не быстрее. Поэтому, если брать линуха, то дотнет не даёт никаких плюшек.
_>Линуксового дотнета вообще пока нет в природе. Совсем недавно появился некий нестабильный обрезок, который возможно пойдёт для специфических целей.
То есть ты знаток .Net ?
public int Method1()
{
var arr = new[] { 1, 2, 3, 4 };
var q = 2;
return arr.Where(x => x > q).Select(x => x + 3).Sum();
}
Allocations: input array, array enumerator, closure for q , Where delegate, Select delegate, Where enumerator, Select enumerator.
Decompiled output code
public int Method1()
{
int[] arr = new[] { 1, 2, 3, 4 };
int q = 2;
return this.Method1_ProceduralLinq1(arr, q);
}
private int Method1_ProceduralLinq1(int[] _linqitems, int q)
{
if (_linqitems == null) throw new ArgumentNullException();
int num = 0;
for (int i = 0; i < _linqitems.Length; i++)
{
int num2 = _linqitems[i];
if (num2 > q)
num += num2 + 3;
}
return num;
}
Я это к тому, что и Linq to SQL сразу будет формировать строку запроса и оптимальное заполнение модели.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
I>>Это демонстрация заблуждения "Сборка молодого поколения практически бесплатна." ·>Если откалибровать во время разработки. ·>Почему аллокаторы калибровать можно, а параметры gc вдруг нельзя?
Дай мне забесплатно 1000$ ? Ну как предложение ? Калибровать — можно. И это очень дорого, только издержки переносятся в разработку.
Когда говорят "бесплатно" это значит всё само работает, искаропки и пилить ничего не надо. А у тебя постоянный майнтенанс, соответсвенно, часть фич приходится откладывать на потом, ибо этот тюнинг требует времени и его просто так не выбросишь.
I>>Разница в частоте срабатываний примерно 2-3 порядка. Это и есть "исключить". Необходимость не только offheap падает, но и растёт Объемы данных растут быстрее, чем улучшаются алгоритмы и соответсвенно качество работы GC. I>>Сейчас вобщем не редкость, когда приходится хранить миллиарды объектов в памяти. Самый распрекрасный GC сосёт не нагибаясь. ·>Отношение количества таких специфичных задач к общему числу задач падает, могу смело предположить.
У меня другие ощущения. В дотнете относительно недавно начали появляться либы для работы с конским количеством объектов, миллиард и больше. Более того, даже в пейтоне, и JS тоже пошли такие фокусы, только масштаб меньше.
Здравствуйте, vdimas, Вы писали:
V>·>Ну собственно намёк был в том, что твоя гениальная оптимизация пулами аллокаторов уже есть в gc. V>Намек был на твоё полное невладение предметом, вообще-то. V>Сорри, намек ты не понял, поэтому пришлось написать явно.
Ничего себе! Сочувствую. Было не очень больно? Может ты пиши всегда прямо писать будешь, а не намёками, мы не на свидании, вроде как.
V>Ну конечно, в GC такой оптимизации нет, т.к. процесс освобождения памяти крайне дорогой.
Так я ж пишу — TLAB такая оптимизация и есть — тред использует свою персональную память по возможности.
V>·>Чем оправдываешь переизобретение велосипеда? V>Технологии современного велосипеда меняются приблизительно каждые 5 лет.
И что в аллокаторах поменялось 5 лет назад?
V>Оправдывают переизобретения тем, что иначе до сих пор на великах были бы деревянные колёса, примерно как в давным давно протухшей Джаве.
Алгоритмы GC в java тоже меняются, и вроде, с тем же темпом, последним вон G1 сделали, в планах shenandoah есть.
V>·>но можно расшифровать что такое "хип GC"? V>Можно. "Куча GC".
Что такое "Куча GC" и какие ещё кучи бывают в java?
V>·>И что такое "честный образ"? V>Это обычный аллокатор.
Что такое "обычный аллокатор" в java?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>>>Абсолютное большинство клиентов так и делают, ес-но. V>·>А доказать? V>Да какие проблемы? Как станете топовой конторой, так тоже будете претендовать на роль первоисточника. V>Или это была просьба слить тебе базу данных клиентов?
Нет, хоть какие-нибудь реальные цифры, хоть что-то похожее на проверяемые факты, а не простое форумное блаблабла. Я могу например предложить погуглить HFT-позиции — java составляет не менее трети, остальное native, c# — в микроскоп не видно, и в основном GUI (что не совсем HFT в общем-то). Притом многие позиции в top 10 IB, а их бедными назвать язык не поворачивается.
V>·>Ок. Системный — связанный с операционной системой. V>Как запись в сокет? Создание потока? V>Я не могу уловить, где именно ты проводишь границу. Похоже, прямо по Джаве, ы-ы-ы. ))
По Language Specification, очевидно. Треды в JLS есть? А сокеты? А в c# этого разве нет?
V>>>Если требуется шустрость, то берут нейтивные HTTP-серваки, ес-но. V>·>Интересно, почему в dotnet http клиент не реализован в нативе? V>Потому асинхронные сокеты на IOCP реализованы в нейтиве.
Причём тут IOCP-сокеты? Найди мне упоминание IOCP-сокетов в RFC2616 и подобных, плиз.
V>·>Шустрость не нужна разве? Ведь dotnet уже почти работает быстрее натива... V>Шустрость джаве нужна, конечно. Но, боюсь у меня для тебя плохие новости. В этом плане в Джаве не ожидается НИЧЕГО в ближайшие лет 10 уж точно.
Не увиливай. Почему HTTP не реализован с unsafe, а в FIX приходится? В HTTP не нужна шустрость?
V>·>Ты ошибся с тестом BlockingQueue, назвав его тестом дизраптора V>Это ты ошибся с дисраптором, не поняв принцип его работы.
Врёшь. Или цитату в студию.
V>А теперь хамишь, вместо того, чтобы попросить объяснить, что там, собственно, происходит.
"Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. " — ты всё ещё уверен, что дизраптор так и делает? Повторяю, с дизраптором объекты не генерятся, а переиспользуются преаллоцированные. Ссылку которую ты привёл в качестве "доказательства" — дизраптор не использовался вообще.
V>·>ты ошибся с пониманием приведённого тобой документа о "closely matches" (близкие результаты), но не захотел признать свои ошибки, просто обвинив во лжи. V>Ну ты слишком много лжешь в каждом посте, чтобы я разбирался с очередным твоим набросом. V>Передергиваешь, ты пытаешься как шуллер тасовать факты, задаешь вопросы исключительно в форме утверждений, как последний тролль какой-то.
Цитату в студию, или бери свои слова обратно.
V>Если то была цитата из ЧУЖОГО документа (не по ONIXS), то это твой косяк, ес-но, бо ты сказал, что из МОЕГО.
Ты привёл ссылки на два документа. С авторством документов я не разбирался, я не заметил что ты оказывается автор одного из них, и под "твой документ" я понимаю "документ, ссылку на который ты опубликовал в этом топике".
V>Т.е. тебе стоило извиниться и за свой косяк и за последующее хамство и за невнимательность, бо я до этого дал цифры порядка 6 мкс по нашему продукту. Получается, что ты нагло игноришь данные тебе цифры, а потом на голубом глазу утверждаешь, что некие протухшие 50 мкс близки к моим цифрам. Да еще требуешь извинений непонятно за что. Хорошо себя чувствуешь, эй?
Погоди... Ты хочешь меня убедить делать какие-то выводы из сравнения абсолютных цифры, полученных в перфтестах разных имплеметаций, разными людьми, с разной инфраструктурой, в разное время с разными данными?
V>Кароч, в своем рвении обелить Джаву ты многократно перегнул палку, не останавливаешься ни перед каким мухлежом, да еще пытаешься разговаривать с коллегами с высока. Поржал. ))
Ты привёл ссылку на своё сообщение. В твоём сообщении может быть только твой мухлёж, и таки да, твой мухлёж меня не останавливает.
V>На неоднократные намеки-просьбы отойти от опасной границы прямого троллинга ты реагируешь слишком вяло — тебя хватает буквально на пару постов, потом ты опять тупо накидываешь невообразимой какой-то херни и передергиваний. V>Ну и еще мне сложновато вести беседу с людьмы, которые, так скажем, показывают медленную реакцию. Если человеку надо объяснять более одного раза, то это уже пытка какая-то, а не обсуждение. Нуегона.
Ты перестань говорить увёртками и уловками. Нет такого понятия "честный образ" в java, а что ты под ним подразумеваешь — мне пофиг, нет желания шарады разгадывать, а на прямые вопросы ты ответить прямо не можешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>Линуксового дотнета вообще пока нет в природе. Совсем недавно появился некий нестабильный обрезок, который возможно пойдёт для специфических целей. S> То есть ты знаток .Net ?
Ты с каким конкретно тезисом в моей фразе не согласен? С тем что оно недавно появилось? Или с тем, что это обрезок от полноценного .net'a? Поясни, а то из твоего потока ссылкок и т.п. совершенно не понятна твоя мысль.
Здравствуйте, alex_public, Вы писали:
I>>Надо только добавить к твоим высказывания, что распрекрасную джаву очень сильно теснят всякие тормозные Python, PHP и даже JS. У них тоже особо серьезный эскейп анализ ?
>Быстродействие для таких задач не принципиально в 99% случаев, а для оставшегося одного процента (всякие там гуглы, яндексы, социальные сети и т.п. высоконагруженный веб) выбирают как раз между Java или вообще C++.
'для оставшегося одного процента' выбирают в основном открытые технологии, даже в ущерб производительности. Производительность можно компенсировать разными способами, а ущерб от закрытой технологии может привести к смерти самого бизнеса.
Кроме того, этот 'оставшийся процент' гораздо больше 1%. В банковской отрасли полно дотнета, от этого никуда не деться.
