Здравствуйте, alex_public, Вы писали:

_>>>"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.
_>·>Различного вида буферы, кеши, пулы — это оно. Они никому не интересны??!
_>Не интересно время их выделения/уничтожения, потому как сам же говоришь, что это происходит редко.
Редко, но метко. А есть ещё сами объекты в кешах — приходят, уходят.
Контролировать их время жизни явно — сущий ужас.

_>>>Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).
_>·>Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.
_>Не очень понятно. Эти самые потоки "Б, В, Г, и, иногда Д" должны получить изначальную версию объекта, обработанную версию объекта, или обе? )
Да
В Яве-то без разницы...

_>>>Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))
_>·>Если уж по правде говорить, то С++ синтаксис на порядок сложнее java (надеюсь, не будешь спорить?). А поэтому да, с таким же комфортом. Однако этот комфорт ниже типичного в Яве. Особенно при наличии IDE.
_>Это уже скорее дело вкуса (ну или квалификации)... Для кого-то чем проще, тем комфортнее, а для другого чем больше возможностей, тем комфортнее. )
Зачем возможности, если можно проще? Оккам — бог, и бритва — пророк его. Усложнять — просто. Упрощать — сложно.

_>·>А вот теперь представь, что этим компиляторам дают не только исходный код, но и статистику реального выполнения программы с реальными данными.
_>Такое тоже уже давным давно используется в мире C++ https://blog.mozilla.org/tglek/2010/04/12/squeezing-every-last-bit-of-performance-out-of-the-linux-toolchain/ и иногда действительно даёт неплохие результаты. Но тут дело совершенно не в этом. Вопрос не в инструментах, а в задаче. Проблема выбора оптимальные контейнеров и алгоритмов не идёт ни в какое сравнение с проблемой оптимизации ассемблерного кода под современные процессоры. И то с последней сколько лет возились...
PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.

Здравствуйте, Serginio1, Вы писали:

EP>>Вот практически готовый пример.
S> Воо уже более интересно. У питона есть информация о типе.

Конечно есть, это же динамически типизированный интерпретируемый язык — а в них это реализуется легко. Это было даже в древнем Smalltalk.

S>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.

Не проблема — импортировать модуль можно по строковому имени в любом месте.

Здравствуйте, ·, Вы писали:

dot>>>>>Да пусть доказывает, он железный, зарплату не просит.
EP>>>>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей.
dot>>>Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.
EP>>На C++ зачем это доказывать? Мы же про EA говорим.
dot>Чтобы писать надёжные программы.

Вот здесь есть escape, при этом сам объект типа vector передаётся по стеку.

auto foo()
{
    vector<Widget> xs;
    // ...
    return xs;
}

То есть та оптимизация которую делает EA есть даже при escape.

EP>>>>Оно бы грохнулось в тот же самый момент и без EA.
dot>>>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
EP>>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
dot>С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен.

Возможен, я делал. Но это опять соскакивание с темы.

dot>Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.

Это понятно. Речь про размещение в куче, например большого массива, и вот для некоторых типов куч имеет смысл ставить условный delete как можно раньше (что может сделать EA).

dot>>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.
EP>>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
dot>Ты принимаешь решение в compile time — какой размер считать small.

Да, и этот размер обычно очевиден для конкретной задачи.

EP>>Да и RVO/NRVO прекрасно работает даже на старых MSVC.
dot>Но код нужно писать определённым способом, чтобы этот RVO был возможен.

Если он вдруг по какой-то причине невозможен — будет гарантированное перемещение.

dot>>>>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).
EP>>>>Меняет — поиск и удаление константы в худшем случае.
dot>>>А добавление?
EP>>С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
dot>В точности то же и с gc.

Решили? Для хеш-таблиц-то есть легкодоступные альтернативы.

EP>>>>Очень много, это практика, реальный код.
EP>>>>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.
dot>>>Не факт, что это принесёт хоть какую-то пользу. compile time же.
EP>>В смысле?
dot>JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.

1. JIT ограничен по времени — не все оптимизации доступны. Его задача в том числе работать быстро.
2. JIT не превращает массив указателей на классы в массив структур — а именно про такие данные идёт речь.
3. В данном случае информации не больше.

EP>>>>1. Если малое — то уж точно не нужна, тут разногласия нет.
EP>>>>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме
EP>>>>3. Ключ может хранится отдельно от значения, причём без индерекции.
dot>>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.
EP>>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
dot>Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.

Вообще-то здесь про хеш-таблицу, а не сканирование массива.

dot>>>>>Если значение маленькое, то это скорее всего будет примитив.
EP>>>>С чего бы это?
dot>>>Потому что примитив это те же 8 байт, что уже не так уж мало.
EP>>На C++ там где удобно без проблем оборачиваю даже одно значение примитивного типа в класс
dot>Да, система типов и шаблоны в С++ — мощнее, аж Turing complete.

Не в этом дело. Это работает даже без шаблонов. Дело в том что это бесплатно, либо практически бесплатно.

dot>>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.
EP>>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
dot>Это как? Кастомные аллокаторы что-ли?

Да, как один из вариантов.

dot>>>>>Ну и кому эти микробенчмарки нужны?
EP>>>>Тем кого интересует скорость
dot>>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.
EP>>Так говоришь как будто быстрое означает не полезное.
dot>Я говорю, что быстрое не означает полезное.

Оно не означает ни "полезное", ни "не полезное". Ты же явно противопоставляешь полезное быстрому "что-то полезное делало, а не быстрое".

dot>>>>>Ты давай пример системы на плюсах, компилированных под jvm.
EP>>>>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.
dot>>>Потому и не знаешь, что принципиально невозможно.
EP>>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
dot>Возможно, но практически — бесполезно. JS — однопоточный.

И что из этого следует? Нельзя сделать многопоточно на Java?
По теме: https://groups.google.com/forum/#!topic/emscripten-discuss/gQQRjajQ6iY

dot>>>>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.
EP>>>>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.
dot>>>Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.
EP>>1. В том тесте вообще GC остался за бортом, его действия не замеряли. Замеряли только обход массива с простой операцией.
EP>>2. Причём тут вообще JS GC? В случае C++ -> JS — там практически все данные находятся в одном большом буфере.
dot>Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.
dot>Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.

Практический смысл в том, что можно будет писать быстрый код на высоком уровне, и легко портировать готовый код.

Здравствуйте, ·, Вы писали:

EP>>>>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.
EP>>>>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
dot>>>"new int[1<<30]" тоже за одну.
EP>>Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
dot>В итоге что тут получится — простенькая формула как по индексу массива и положению вычислить индекс внутри int[1 << 30].

1. Перед этим придётся вручную выпрямить иерархию агрегирования.
2. Данные могут быть разных типов — придётся брать сырой буфер.
3. Нельзя использовать стандартные готовые алгоритмы — придётся писать новые.

EP>>>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
dot>>>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
EP>>Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
dot>Остаётся как минимум простота поддержки и разработки,

Есть же более гибкие/удобные и при этом достаточно не сильно сложные языки. Тот же C#.

dot>скорость внесения изменений без страха что-то нечаянно поломать.

Чем это достигается? И почему думаешь что этого нет в других управляемых, но более гибких языках?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Serginio1, Вы писали:

EP>>>Вот практически готовый пример.
S>> Воо уже более интересно. У питона есть информация о типе.

EP>Конечно есть, это же динамически типизированный интерпретируемый язык — а в них это реализуется легко. Это было даже в древнем Smalltalk.

S>>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.

EP>Не проблема — импортировать модуль можно по строковому имени в любом месте.
Как это сделать из 1С?

Здравствуйте, Serginio1, Вы писали:

S>>>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.
EP>>Не проблема — импортировать модуль можно по строковому имени в любом месте.
S> Как это сделать из 1С?

Вызывать Python функцию которая импортирует модуль по заданному строковому имени.

Здравствуйте, ·, Вы писали:

_>>Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.
·>Ты что-то фигню говоришь полную. Может что-то из давнего прошлого помнишь просто? Такое уж как минимум 6 лет неактуально.
·>Специально сейчас посчитал. В проекте 965 вхождений " = null" на ~2 миллиона строк.

Ну вот ты наконец то увидел аналог ситуации в C++. В старых проектах или у заставших в древности авторов ещё можно найти множественные delete, а в нормальных проектах такого не увидишь.

Здравствуйте, ·, Вы писали:

_>>·>Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.
_>>Не очень понятно. Эти самые потоки "Б, В, Г, и, иногда Д" должны получить изначальную версию объекта, обработанную версию объекта, или обе? )
·>Да
·>В Яве-то без разницы...

Ага, без разницы) И при этом работает с кучей тормозов и блокировок. )))

_>>Это уже скорее дело вкуса (ну или квалификации)... Для кого-то чем проще, тем комфортнее, а для другого чем больше возможностей, тем комфортнее. )
·>Зачем возможности, если можно проще? Оккам — бог, и бритва — пророк его. Усложнять — просто. Упрощать — сложно.

Это верно, но при одном условие — отсутствие потери возможностей. Если же упрощение достигается путём сокращения возможностей, то его ценность уже далеко не так однозначна.

·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.

Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода конкретного алгоритма и конкретных типов (в существование такого у меня нет сомнений) и некую оптимизацию, выбирающую алгоритмы и типы данных (существование подобных эффективных оптимизаторов — это миф).

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Serginio1, Вы писали:

S>>>>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.
EP>>>Не проблема — импортировать модуль можно по строковому имени в любом месте.
S>> Как это сделать из 1С?

EP>Вызывать Python функцию которая импортирует модуль по заданному строковому имени.
Ну я же не знаток Питона. То есть как реализовать следющее

Врапер=Новый ComОбъект(ПрогИДВрайпераПитона);
Врапер.ЗагрузитьСборку(ФайлГдеНаходитсяОписаниеНужногоКласса);
Объект=Врапер.СоздатьОбъект(СтроковоеИмяОбъектаНужногоКласса);

Здравствуйте, alex_public, Вы писали:

_>·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.

_>Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода

Не надо путать архитектуру с низкоуровневыми оптимизациями. Тебя послушать, так только на плюсах все и можно писать. Однако, даём слово разработчикам Варгейминга:

...а у «Танков» внутри — в основном Python.

Если ты не в курсе, то танки варгейминга это нынче один из лучших примеров, как менеджед решение отлично справляется с конской нагрузкой.

"если хоть одна функция написана на С++... " @alex_public

Здравствуйте, Ikemefula, Вы писали:

_>>·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.
_>>Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода
I>Не надо путать архитектуру с низкоуровневыми оптимизациями.

Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))

I>Тебя послушать, так только на плюсах все и можно писать. Однако, даём слово разработчикам Варгейминга:
I>

I>...а у «Танков» внутри — в основном Python.

I>Если ты не в курсе, то танки варгейминга это нынче один из лучших примеров, как менеджед решение отлично справляется с конской нагрузкой.
I>"если хоть одна функция написана на С++... " @alex_public

Ты похоже бредишь) Я уже много раз (в том числе и в этой темке) высказывал своё полное одобрение использованием схемы со встроенным в C++ приложение Питоном (или другим скриптовым языком) для сложных проектов.

Здравствуйте, alex_public, Вы писали:

I>>Не надо путать архитектуру с низкоуровневыми оптимизациями.

_>Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))

Удивляюсь, как ты ухитряешь прочесть написаное.

I>>"если хоть одна функция написана на С++... " @alex_public

_>Ты похоже бредишь) Я уже много раз (в том числе и в этой темке) высказывал своё полное одобрение использованием схемы со встроенным в C++ приложение Питоном (или другим скриптовым языком) для сложных проектов.

Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?

Здравствуйте, Ikemefula, Вы писали:

_>>Ты похоже бредишь) Я уже много раз (в том числе и в этой темке) высказывал своё полное одобрение использованием схемы со встроенным в C++ приложение Питоном (или другим скриптовым языком) для сложных проектов.
I>Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?

В танчиках то? ) Так они у меня установлены... )))

Здравствуйте, alex_public, Вы писали:

I>>Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?

_>В танчиках то? ) Так они у меня установлены... )))

Типа ты не понял, что речь про серверный софт

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Вот здесь есть escape, при этом сам объект типа vector передаётся по стеку.
А что такого в этом векторе? Он же маленький, соответствует 4 или 8 байтной ссылке в Яве. Самое интересное это то, на что он указывает в куче.

EP>

EP>auto foo()
EP>{
EP>    vector<Widget> xs;
EP>    // ...
EP>    return xs;
EP>}
EP>

То есть та оптимизация которую делает EA есть даже при escape.
EA работает не на уровне одного метода, а для довольно большого куска кода, притом даже если у тебя методы виртуальные (что для C++ компиляторов очень неприятное обстоятельство).

dot>>>>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
EP>>>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
dot>>С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен.
EP>Возможен, я делал. Но это опять соскакивание с темы.
Но как? Или опять оборачиванием указателей в специальную песочницу типа как gc_root?

dot>>Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.
EP>Это понятно. Речь про размещение в куче, например большого массива, и вот для некоторых типов куч имеет смысл ставить условный delete как можно раньше (что может сделать EA).
В яве — не имеет смысла что-то ставить.

dot>>>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.
EP>>>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
dot>>Ты принимаешь решение в compile time — какой размер считать small.
EP>Да, и этот размер обычно очевиден для конкретной задачи.
не факт, размер может варьироваться от реальных условий. И всякие стандартные vector это, вроде не умеют.

dot>>>>А добавление?
EP>>>С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
dot>>В точности то же и с gc.
EP>Решили? Для хеш-таблиц-то есть легкодоступные альтернативы.


dot>>>>Не факт, что это принесёт хоть какую-то пользу. compile time же.
EP>>>В смысле?
dot>>JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.
EP>1. JIT ограничен по времени — не все оптимизации доступны. Его задача в том числе работать быстро.
Это практически миф, особенно для долгоиграющих серверов. JIT не оптимизирует весь код, а только самый горячий, в отличие от обычного compile time оптимизатора или даже PGO, который старается оптимизировать абсолютно всё, даже куски которые в реальности может быть и не будут выполнены вообще. И времени на долгоиграющем сервере ему предостаточно.

EP>2. JIT не превращает массив указателей на классы в массив структур — а именно про такие данные идёт речь.
Собственно у меня есть сомнения по поводу ценности такого превращения. Ценным может быть превращение в структуру массивов (а такое и С++ не умеет), либо компактификация кучи (чем занимается gc).

EP>3. В данном случае информации не больше.
jit может принести пользу, если перенесёт массив объектов на стек.

dot>>>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.
EP>>>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
dot>>Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.
EP>Вообще-то здесь про хеш-таблицу, а не сканирование массива.
Даже и хеш-таблица — всё равно. Два случая
— массив хеш-таблицы поместился в кеш и значения маленькие, лежат в самом массиве.
— массив хеш-таблицы поместился к кеш лишь потому, что значения лежат по ссылкам, т.е. индирекция используется.
И собственно и то и другое аналогично делается и в С++ и в Яве.

dot>>>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.
EP>>>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>>>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
dot>>Это как? Кастомные аллокаторы что-ли?
EP>Да, как один из вариантов.
Ну собственно не сильно отличается от Явы, там кастомное расположение данных в массиве.

dot>>>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.
EP>>>Так говоришь как будто быстрое означает не полезное.
dot>>Я говорю, что быстрое не означает полезное.
EP>Оно не означает ни "полезное", ни "не полезное". Ты же явно противопоставляешь полезное быстрому "что-то полезное делало, а не быстрое".
Компиляция C++ -> JVM или JS не полезное, пусть хоть и быстрое.

dot>>>>Потому и не знаешь, что принципиально невозможно.
EP>>>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
dot>>Возможно, но практически — бесполезно. JS — однопоточный.
EP>И что из этого следует? Нельзя сделать многопоточно на Java?
Можно, но думаю получится медленно, либо с ограничениями.

EP>По теме: https://groups.google.com/forum/#!topic/emscripten-discuss/gQQRjajQ6iY
Поживём, увидим. А пока это лишь PoC.

dot>>Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.
dot>>Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.
EP>Практический смысл в том, что можно будет писать быстрый код на высоком уровне, и легко портировать готовый код.
Может быть и можно будет. А пока — облом.
Хотя я не верю что можно будет с таким дизайном языка как в C++. Может что-то в духе C++/CLI прокатит...

Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>"new int[1<<30]" тоже за одну.
EP>>>Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
dot>>В итоге что тут получится — простенькая формула как по индексу массива и положению вычислить индекс внутри int[1 << 30].
EP>1. Перед этим придётся вручную выпрямить иерархию агрегирования.
EP>2. Данные могут быть разных типов — придётся брать сырой буфер.
EP>3. Нельзя использовать стандартные готовые алгоритмы — придётся писать новые.
Часто это всё не является проблемами. Но в общем случае, конечно, да.

EP>>>>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
dot>>>>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
EP>>>Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
dot>>Остаётся как минимум простота поддержки и разработки,

EP>Есть же более гибкие/удобные и при этом достаточно не сильно сложные языки. Тот же C#.
Ну давай примеры C# в LL.

dot>>скорость внесения изменений без страха что-то нечаянно поломать.
EP>Чем это достигается? И почему думаешь что этого нет в других управляемых, но более гибких языках?
В .net особо не видно. А в jvm есть и другие языки, да.

Здравствуйте, alex_public, Вы писали:

_>>>Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.
_>·>Ты что-то фигню говоришь полную. Может что-то из давнего прошлого помнишь просто? Такое уж как минимум 6 лет неактуально.
_>·>Специально сейчас посчитал. В проекте 965 вхождений " = null" на ~2 миллиона строк.
_>Ну вот ты наконец то увидел аналог ситуации в C++. В старых проектах или у заставших в древности авторов ещё можно найти множественные delete, а в нормальных проектах такого не увидишь.
Да и x=null особо в Яве никогда не было. Я никогда в реальном коде такого не видел, даже в старом. Превратилось из баек в миф.
Зато в С++ можно найти ptr.reset() и всякие извращения с владением, и */&-указатели, и битые указатели, и утечки из-за циклических зависимостей...

Здравствуйте, alex_public, Вы писали:

_>>>·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.
_>>>Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода
I>>Не надо путать архитектуру с низкоуровневыми оптимизациями.
_>Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))
Ты, как плюсовик, считаешь частью архитектуры разные комбинации _ptr, [], &, *. В яве это частью архитектуры не является. Всё выражается одним абстрактным понятием — ссылка. А как оно будет в итоге расположено — JIT умеет не лету корректировать для лучшей производительности.

Здравствуйте, Ikemefula, Вы писали:

I>>>Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?
_>>В танчиках то? ) Так они у меня установлены... )))
I>Типа ты не понял, что речь про серверный софт

Вроде бы же речь шла о сочетание C++ + Python, а это как раз устройство их клиента. Что касается сервера, то там у них вообще адская мешанина включая не только C++ и Python, но и Ruby и ещё чёрт знает что.)))

Здравствуйте, ·, Вы писали:

I>>>Не надо путать архитектуру с низкоуровневыми оптимизациями.
_>>Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))
·>Ты, как плюсовик, считаешь частью архитектуры разные комбинации _ptr, [], &, *. В яве это частью архитектуры не является. Всё выражается одним абстрактным понятием — ссылка. А как оно будет в итоге расположено — JIT умеет не лету корректировать для лучшей производительности.

Всё верно. Только я как раз выражаю свои сомнения в способности современного оптимизатора сделать это лучше человека. На самом деле аналогичная ситуация была и с ручным ассемблерным кодом vs C/C++ оптимизаторы лет 20 назад. Тогда нормальный спец. по ассемблеру легко писал код эффективнее C++ компилятора. Сейчас же это почти не реально. Так вот выше обсуждаемый оптимизатор в Java в данный момент не способен создавать ничего сравнимого с человеком. Теоретически когда-нибудь может и сможет, но я сомневаюсь, что это случится в ближайшем будущем. Потому как слишком сложная и неформализованная задача.