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

I>>В целом изжержки на джыт вполне осязаемы. Обычно джыт идет где то в первых трех позициях по расходу процессора и памяти, если верить профайлеру. Издержки меньше, чем от ГЦ, но тем не менее заметные.
·>Я знаю, поэтому dalvik и заменили на ART.

То есть, ты знаешь, что издержки заметные, но не знаешь как эти издержки связаны с батареей ?

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

_>>Вообще основная моя мысль была в другом — в возражение твоему тезису, что при желание любой java код можно дооптимизировать до производительности C++. Очевидно, что с любым это не пройдёт, причём даже не учитывая такие вещи как simd (сам же видел, что C++ код без simd всё равно в пару раз быстрее). В Java и т.п. языках есть принципиальные архитектурные недостатки не позволяющие этого.
·>Согласен. Все обобщающие утверждения — ложны.
·>Обычно можно. Понятное дело, что у С++ всегда есть доступ к уровням ниже, чем у java, но это обычно не нужно.

Нуу скажем ситуация с обходом буффера вложенным циклом (как раз пример выше) является не то чтобы особо редкой в программирование. А как раз она не решается эффективно на управляемых языках.

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

_>>Да, и главное: даже если бы ты тут и указал бы что-то реально дельное (кстати та же avalonia выглядит вполне перспективно), то это всё равно не имело бы никакого отношения к тому факту, что .net core и т.п. — это огрызки полноценного .net.
S> Проблема WPF в том, что он прибит к DirectX. Поэтому процессоры для Win Mo должны поддерживать DirectX.
S> Ну и оновное направление сейчас это не Декстоп. https://habrahabr.ru/post/313202/

Как бы OpenGL ничем не хуже DirectX, так что никаких проблем с этим нет. Ну т.е. понятно что надо переписать немного кода, но для такой конторы как MS это очевидно не проблема. Если бы было соответствующее желание...

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

S>Есть универсальная обёртка с поддержкой XAML над нативными для платформ фреймворками https://github.com/picoe/Eto

Хыхы, попытка работать через нативные контролы на всех платформах — некое слабое подобие wxWidgets. Лично мне такой подход очень нравится идеологически, но к сожалению он вызывает большие проблемы при столкновение с платформами, на которых родной GUI недоступен из нативного кода. Именно поэтому у wxWidgets так и нет нормального порта для Андроида. И у этих товарищей тоже нет (и скорее всего не будет).

S>(набор контролов достаточно богатый, сейчас вот заснял как оно с GTK-бакэндом на убунте выглядит https://youtu.be/2QJpdI0Wjos).
S> А что касается аналога WPF с полностью своим рендерингом, то мы работаем над этим. https://github.com/AvaloniaUI/Avalonia

Ты уже кидал ссылки на Авалонию. И я тебе уже писал, что сам проект вполне симпатичный (ну не считая того что он пока напоминает всего лишь убогий html gui, но это же пока альфа-релиз — ему простительно). Но это не имеет никакого отношения к обсуждаемой теме. Потому что чтобы сделать полноценную реализацию .net на других платформах требуется не просто написать ещё одну стороннюю GUI библиотечку, а портировать именно сам WPF (т.к. он является официальной частью .net). Если MS этого не делает, то это означает просто не желание предоставлять полноценный .net на другие платформы.

Двойного повтора этого тезиса достаточно тебе для понимания? Или пойдём на третий круг? )

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

·>SIMD на мобильниках?? Бывает разве?

Вообще то оно (Neon завётся на ARM и классический SSE4 на Atom'ах) там живёт уже очень давно как. И только из-за него дохлые мобильные процессоры нормально ворочаются с некоторыми вопросами (которые параллельные, но не относятся к GPU).

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

V>·>Может просто ваше джава решение не лучшее? И за джавой идут к другим?
V>Наше лучшее. Просто самих таких клиентов резко меньше и они обычно не крупные.
V>А всякие JP-Morgan и прочие крупные клиенты нейтивные.
Ой, а почему они мне оффер на позицию java algo trading dev давали? У них там всё есть.

V>В общем, одна восемнадцатая от одной трети отличается нормально так.
V>Передёрнул так уж передёрнул. ))
Ок победил. Тут можно считать так и эдак, статистика вещь такая.

V>>>В самом языке нет потоков. А вот в системной библиотеке, являющейся частью стандарта, уже есть.
V>·>Прежде чем заявлять очередную глупось — погугли хоть 10 сек. Ключевое слово "jls-17".
V>Глупости заявляешь здесь только ты и вот это предложение погуглить — тоже, ес-но.
V>Я не хуже тебя представляю, что там с потоками в Джава и как оно устроено. И при чем тут язык или системные библиотеки.
А что причём? Твоё личное мнение?

V>А для борьбы с глупостью стоило посмотреть на язык go, где потоки встроены в сам язык.
Каким образом они там "встроены"? Судя по твоим рассужениям так же — часть библиотеки.

V>·>Ещё намёк — в каком пакете находится класс Thread?
V>Плевать с большой колокольни.
Плюй, не плюй, а факт остаётся фактом.

V>·>А вот всякие сетевые сокеты, файлы, коллекции, регекспы и прочее — да, это часть стандартной библиотеки, а не языка.
V>Я правильно понимаю, что от одного лишь имени собственного пакета "lang" у тебя малость зрение меняется?
А у тебя зрение меняется когда факты противоречат твоим убеждениям.

V>Треды — это отъемлимая часть аж бегом.
V>Ты демонстрируешь тут повадки новичков в Джаве, которые на голубом глазу путают язык и VM.
Ну погугли что такое monitorenter/monitorexit и описание поведения других инструкций в многопоточном окружении.

V>·>Причём тут вообще сокеты? Зачем ты упомянул их? Как они с протоколами HTTP или FIX связаны?
V>Напрямую связаны, ес-но.
Нет, конечно, не связаны. Или у тебя есть какие-то доказательства?

V>·>В смысле у вас только IOCP сокеты в нативе
V>В смысле виденные мною HTTP-серваки на дотнете используют такие сетевые ср-ва (асинхронный IO), которые были разработаны в нейтиве.
Не путай HTTP-сервер и HTTP-протокол.
на джаве обычно есть pure-java реализация стандартными средствами и нативные модули для работы со специфичными под конкретную систему нативными имплементациями, если есть что-то специфичное, конечно.

V>>>·>"Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. " — ты всё ещё уверен, что дизраптор так и делает? Повторяю, с дизраптором объекты не генерятся, а переиспользуются преаллоцированные.
V>Торопишься. Не думаешь.
V>

V>Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди

V>Тут стоило помедитировать. Это СТАНДАРТНЫЙ подход. Это, блин, сверх-мега-стандартный подход для таких вещей. Это база, уровень 0. ))
Где в дизрапторе происходит генерация объектов? Что ты вообще назвал генерацией объектов?

V>Две встречные очереди образуют "кольцо". Эдакие чётки, как у попа, только вместо пальцев правой и левой руки у нас производитель и потребитель. Один берет из пула объект, подготавливает его и пихает "туда". Другой обрабатывает и пихает "обратно".
Что-то какое-то странное представление. Обычная очередь, одна, как в ларёк за пивом. Очереди образуют кольцо?.. Брр. Как-то всё переусложнено.

V>Чем ring-buffer отличается от двух встречных очередей? Да ничем, кроме того, что реализован не на связанном одностороннем списке объектов, а через прибитый к реализации массив фиксированного размера, что считается самой худшей схемой из всех известных. )) Ну, кроме случая, где генерирование и потребление происходит заведомо с одинаковой скоростью,
Нет, когда потребление в среднем не медленнее продьюсинга. Т.е. буфер не переполняется (хотя в пики может расти в глубину).

V>как при воспроизведении аудио, например. Более того, запись и чтение из кольцевого буфера на один CAS дороже, чем в стандартной схеме межпотокового буфера. Ну и, самое главное, часто мы имеем обращение к одной и той же линейке кеша из разных потоков (ядер) в такой схеме, что до 6 раз (в среднем) тормозит любую межпоточность. Ладно аудио, там десятки-сотня пакетов в секунду от силы, но для HFT это смерть. ))
Там в одну линейку _пишут_ только продьюсеры, консьюмеры только читают. В приведённом тобой тесте было три продьюсера. Тут уже мало что можно сделать иначе. В случае одного продьюсера дизраптор действительно раскочегаривается по полной.
Собственно это как раз одно из преимуществ дизраптора, что он дружелюбен к железу, учитывает все эти кеши и прочие нумы.

V>>>Это и есть дисраптор. Это его базовый Lego-кубик (один из 3-х, вернее, с идентичным интерфейсом).
V>·>А доказать?
V>Я всё доказал, пояснив общее устройство такой схемы (две встречных очереди).
Я не понимаю почему ты это называешь двумя очередями. В тесте на который ты привёл — очередь одна. В один конец происходит добавление, с другого конца забирают. Никакого "возвращения" нет.

V>Какие еще нужны доказательства?
Что в приведённом тобой тесте используется дизраптор.

V>Я, конечно, могу ошибаться, но мне кажется, что тебя сбивает с толку именно ring buffer. Он в этой схеме вообще не причем, но кажется тебе главной деталью.
Конечно главная деталь. Потому что это не очередь. По ринг-буферу могут ползать сразу несколько потребителей. И их можно огораживать барьерами — потребители C и D могут отработать только после того, как отработали предыдущие A и B (притом не важно — в каком порядке — A/B или B/A). Вот тут с картиночками: http://martinfowler.com/articles/lmax.html
Т.е. этот один единственный паттерн позволяет реализовывать довольно сложное взаимодействие между множествами тредов просто складывая их как кубики.

V>Без ring buffer можно получить лучшее быстродействие, за счёт (в порядке убывания важности):
V>- отсутствия блокирующих ожиданий при переполнении буфера;
V>- на одну операцию CAS меньше;
V>- лучшей локальности данных.
V>- меньшей требуемой памяти;

V>По последнему. Без ring buffer можно организовать НЕСКОЛЬКО веток consumer-producer с ОДНИМ всего пулом у каждого producer и хорошим автоматическим load balancing, в то время как в случае кольцевого буфера у нас пул объектов привязан к конкретной ПАРЕ consumer-producer, а не к именно producer (ведь пул нужен именно ему).
Нет, RTFM.
Вот скажем 2 продьюсера делают балансинг на 2 консьюмера https://github.com/LMAX-Exchange/disruptor/blob/master/src/perftest/java/com/lmax/disruptor/workhandler/TwoToTwoWorkProcessorThroughputTest.java

V>>>Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди, ссылку на тест которой (очереди) я тебе дал.
V>·>Бред. Ты дал ссылку на тест, который реализует three producers -> one consumer используя стандартный BlockingQueue.

V>Кинь мне плиз мою ссылку.
https://github.com/LMAX-Exchange/disruptor/blob/master/src/perftest/java/com/lmax/disruptor/queue/ThreeToOneQueueThroughputTest.java

V>Да, я теперь внимательно посмотрел исходник и охренел.
Хоть посмотрел, и на том спасибо.

V>Писали нубы, нихрена не соображающие в устройстве современных систем. ))
Голословно.

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

V>·>Но не подходит .net. Что и требовалось доказать.
V>А что мешает написать аналог азула под .Net?
Майкрософт.

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

S>>> Ну ты вроде тут соглашался про оптимизации SIMD и прочими оптимизациями.
S>·>SIMD на мобильниках?? Бывает разве?
S> Появятся. https://habrahabr.ru/post/153015/
Так и SIMD оптимизации в JIT тоже когда-нибудь появятся (кстати уже есть в каком-то виде).

S>>> Мы вроде говорим об отм, что предварительная компиляция экономит батарею?
S>·>Мы вроде говорим о том, что экономия батареи не означает запрет на компиляцию в нативный код самом на девайсе. Что вовсе не обязательно апп-магазину распространять непосредственно нативный код как ты предлагаешь с .net native.
S> Тогда я тебя не понял. Я говорю о том, что нативный код уменьшает время потребления энергии за счет уменьшения времени загрузки и скорости работы за счет уменьшения косвенности (инлайнинг) и Большей оптимизации нативного кода за счет использования оптимизирующих компиляторов. Кроме того например для .Net Native не нужна среда CLR, а значит и её не нужно загружать и она не расходует ресурсы
Правильно. Я говорю лишь о том, что подход с .net native не единственно верный. И он может быть когда-нибудь появится и не повалит сервера апп-стора, в то время как ART с твоей любимой предварительной компиляцией работает уже три года на миллионах девайсов.

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

V>>>·>И как это всё вообще относится к нашему разговору?
V>>>·>Напомню: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"".
V>>>Именно так.
V>·>Ссылочку плиз.
V>

V>The maximum size of an object HotSpot JVM may allocate in young generation is nearly as large as the size of Eden (YoungGen minus two Survivor spaces).

V>За пределами этого размера (на самом деле задолго до этого размера) объект выделяется в обычной куче и отправляется сразу во 2-е поколение (Old generation в терминах Джавы).
Во как. Ты оказывается имел в виду не "хип GC" (чтобы это не значило), а область (area, generation) кучи. И что ты хотел сказать-то этим? Если у тебя что-то не стало помещаться в YG, но надо — его размер можно увеличить.

V>>>Я имею ввиду обычную кучу, вне кучи GC.
V>·>Нет никаких "обычных куч" в Яве. Есть только Java Heap. И все объекты живут именно там, независимо от размера.
V>Это не так.
Это так. RTFM: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html

V>·>Бывает off-heap подход, но это не об объектах и их размерах, а по сути это просто in memory database. И off-heap как раз используется для хранения данных огромного кол-ва _мелких_ объектов.
V>>>Чем куча GC отличается от обычной?
V>·>Откуда я знаю что такое "обычная куча", этот термин ты придумал.
V>Этому термину больше лет чем тебе.
Ну какая разница когда ты его придумал.

V>·>Скажем, в zing куча операционки может не использоваться, и там есть ядрённый модуль, который выделяет Java-кучу прямо в физической памяти.
V>А бывает как-то иначе? ))
Бывает.

V>Ясно, понятий ровно ноль.
V>В обычной куче есть только две операции — выделение и освобождение памяти.
Можно ссылку на понятие "обычная куча"?

V>В куче GC дополнительно есть операции перемещения объектов, с целью уплотнения (дефрагментации).
GC и дефрагментация вещи ортогональные.

V>Так вот, основной профит от GC как раз в этой дефрагментации, иначе не получится затем выделять память простым инкрементом указателя. Но эта фишка не работает для больших объектов, бо они выделяются в тех областях памяти, где дефрагментация не производится.
Как эти области памяти называются? Ссылку плз.
Ты наверное путаешь с dotnet LOH, там да, есть какие-то особенности.

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

V>>>·>Есть ли БД написанные на .net? Если нет, то почему?
V>>>RavenDB, к примеру.
V>·>С пачками unsafe.
V>Ссылку?
https://github.com/ravendb/ravendb/search?utf8=%E2%9C%93&q=%22unsafe%22&type=Code

V>·>Я не против интеропа, я против сравнения производительности java с "гетероненностью". Т.е. не надо говорить, что dotnet производительнее java основываясь на результатах сравнения нативного кода с java.
V>Нет ты именно против, потому что переворачиваешь всё с ног на голову, насилуя банальную логику.
V>Обильное наличие интеропа в дотнете НЕ является показателем тормознутости дотнета, оно является показателем только лишь низкой трудоёмкости сопряжения дотнета с нейтивом, что только в плюс этой технологии.
Низкой, но не нулевой. Поэтому трудоёмкость чистого шарпа строго меньше шарпа с сопрягалками. Так объясни — зачем сопрягать-то что попало? Чем простой c# не устраивает?
Понимаю когда системные веши сопрягают, сокеты там какие-нибудь новомодные, но когда пишут sort или string...

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

V>>>·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.
V>>>Ссылка?
V>·>dotnet vs java 2016-2020
V>Продолжаем врать?
Это твоё сообщение? dotnet vs java 2016-2020

V>Я НЕ приводил этот пример. Это ты нарыл рекламную строчку и по-своему интерпретировал.
Ты мне сам прислал ссылку на этот документ.

V>Свои цифры я приводил — 4-6 мкс для нейтива и более 120 мкс по Джаве.
V>А вот твоих по Джаве так и не дождался.
Ты привёл достаточно цифр. Других я не искал.

V>Так шта, поздравляю соврамши.
Ты похоже путаешься в том что ты мне даёшь. Потом меня во лжи обвиняешь.

V>И да.
V>

V>Посмотри картинки — синие линии на них это cheetah и b2bits — они примерно одинаково расположены.

V>Во-первых, не одинаково, а с разницей в полтора раза.
Не фантазируй, там цифры текстом написаны и их я тебе их цитировал.

V>Во-вторых, на тех графиках Rapid vs b2bits и оба они нейтивные, безо всякой Джавы.
Продолжаем врать?

B2BITS FIX Antenna engine was a C++ version; Rapid Addition‟s Cheetah engine was Java

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

I>>>В Cи зависит от того, какой код пишешь
I>·>Ок. А почему в С++ вдруг перестаёт зависеть?
I>Смотря что ты называешь плюсами. Там реально три разных языка — Си, собственно плюсы и шаблоны. Одна и та же задача решается в этих трех языках по разному. В си норма использовать void* а вот в плюсах это идея так себе, в шаблонах такое в своем уме вообще не пишут.
Ну так и в Java нет нормы использовать Object, всегда плохая идея. Да и в С это не совсем норма, а собственно единственный вариант.

I>>>·>Касты не означают динамику, каст это приведение типов.
I>>>Все зависит от того, какой тип компилятор предпочитает по дефолту. Иногда это object(any и тд), иногда — точный(string, List). Когда первое, это динамика. Когда второе — статика.
I>·>Что такое "предпочтение компилятора"? Можно ссылочку на language specification?
I>Очень просто
I>

I>def (a) { return ... }
I>

I>тип переменной a будет или точным или нет. Это вроде бы и вывод типа,но с другой стороны, вывод типа может выдать тебе <any> если не найдет ничего точного. Опаньки !
А в Яве такого и нет.

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

I>>>В целом изжержки на джыт вполне осязаемы. Обычно джыт идет где то в первых трех позициях по расходу процессора и памяти, если верить профайлеру. Издержки меньше, чем от ГЦ, но тем не менее заметные.
I>·>Я знаю, поэтому dalvik и заменили на ART.
I>То есть, ты знаешь, что издержки заметные, но не знаешь как эти издержки связаны с батареей ?
Ничего не понял. Не рассуждай о том что я знаю, что не знаю. А говори по сути.

Здравствуйте, ·, Вы писали:
·>Правильно. Я говорю лишь о том, что подход с .net native не единственно верный. И он может быть когда-нибудь появится и не повалит сервера апп-стора, в то время как ART с твоей любимой предварительной компиляцией работает уже три года на миллионах девайсов.
Я так понимаю, что это аналог NGEN которому огромное количество лет и с теми же недостатками. Нет оптимизации при компиляции, нужна среда выполнения для компиляции при рефлексии и подгрузке сборок.
Net Native не зависит от установленного Фреймворка.

Ну и учитывая, что ты утверждал, что предварительная компиляция не нужна, то это шаг вперед

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

I>>>>В Cи зависит от того, какой код пишешь
I>>·>Ок. А почему в С++ вдруг перестаёт зависеть?
I>>Смотря что ты называешь плюсами. Там реально три разных языка — Си, собственно плюсы и шаблоны. Одна и та же задача решается в этих трех языках по разному. В си норма использовать void* а вот в плюсах это идея так себе, в шаблонах такое в своем уме вообще не пишут.
·>Ну так и в Java нет нормы использовать Object, всегда плохая идея. Да и в С это не совсем норма, а собственно единственный вариант.

Потому в Си все сильно средне


I>>тип переменной a будет или точным или нет. Это вроде бы и вывод типа,но с другой стороны, вывод типа может выдать тебе <any> если не найдет ничего точного. Опаньки !
·>А в Яве такого и нет.

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

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

_>_>Ты уже кидал ссылки на Авалонию. И я тебе уже писал, что сам проект вполне симпатичный (ну не считая того что он пока напоминает всего лишь убогий html gui, но это же пока альфа-релиз — ему простительно). Но это не имеет никакого отношения к обсуждаемой теме. Потому что чтобы сделать полноценную реализацию .net на других платформах требуется не просто написать ещё одну стороннюю GUI библиотечку, а портировать именно сам WPF (т.к. он является официальной частью .net). Если MS этого не делает, то это означает просто не желание предоставлять полноценный .net на другие платформы.

_>Двойного повтора этого тезиса достаточно тебе для понимания? Или пойдём на третий круг? )

Я не думаю, что для MS интересно делать WPF кроссплатформенным учитывая процент декстопов на котором стоит Windows.
А вот для мобильных устройств будут развивать Xamarin Forms.

А вот для серверов WPF не нужен, а интересны им юниксы линуксы именно из-за облаков.

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

S>Здравствуйте, ·, Вы писали:
S>·>Правильно. Я говорю лишь о том, что подход с .net native не единственно верный. И он может быть когда-нибудь появится и не повалит сервера апп-стора, в то время как ART с твоей любимой предварительной компиляцией работает уже три года на миллионах девайсов.

S> Я так понимаю, что это аналог NGEN которому огромное количество лет и с теми же недостатками.
Насколько я знаю, главный недостаток NGEN для мобильных девайсов в том, что его нет. Вот что пишут о .NET Micro Framework:

The CLR is an interpreter rather than a just-in-time compiler, and uses a simpler mark-and-sweep garbage collector instead of a generational approach.

Т.е. вообще тупой интерпретатор с примитивным GC. Вот они и стали пилить этот самый .net native.

S> Нет оптимизации при компиляции, нужна среда выполнения для компиляции при рефлексии и подгрузке сборок.
S> Net Native не зависит от установленного Фреймворка.
Зависимость от фреймворка сама по себе ничем не плохо. AOT не означает, что нужно непременно собирать нативные бинарники и распространять их магазином. В ART сделано оптимально — финальная компиляция (из байткода в натив) сделана на девайсе, в момент установки. Т.е. установленная программа — нативный код — проблем с батареей и со стартом приложения нет. .net native предлагает распространять нативные бинарники изначально, что может серьёзно увеличить нагрузку на апп-сторы в случае большого числа вариантов девайсов или версий этого самого .net native.

Так что из того что ты написал — нет ничего нового (ну кроме COM для linux), это уже несколько лет успешно работает на java платформе, этот самый .net native просто попытка догнать, и (лично моё мнение) не самая удачная, поживём — увидим.

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

EP>>Да не обязательно CRTP — обычный std::partition_point это уже статический полиморфизм.
·>Ну method overloading это тоже статический полиморфизм.

Верно.

·>Может внутренняя имплементация не так элегантна как в Плюсах, но Arrays.binarySearch внешне выглядит точно так же.

Внешне Arrays.binarySearch выглядит как борьба с языком — ибо там ручная перегрузка на каждый тип, при видимо одинаковой реализации.

EP>>>>В каком-то смысле да. Точнее его бывает используют для случаев когда все входные данные (а бывает ещё и выходные) известны в статике. В C++ для таких случаев есть например boost::mpl/fusion/hana::map — в которых соответственно бОльшая часть ошибок ловится во время компиляции
EP>>·>А можно пример?
EP>>Простой пример (live demo)
·>Интересно. А что с этим можно делать? Чем литерал "lambda"_s лучше lambda_s?

Тем что это строка, её можно парсить, выделять подстроки, она может быть частью большей строки.
Собственно во втором примере

Автор: Evgeny.Panasyuk
Дата: 12.10.14

это видно: строится compile-time map<имя переменной, значение>, далее парсится интерполированная строка в которой на переменные ссылаются по именам, по этим именам из map достаются значения и выводятся (всё в compile-time, поэтому и ASM идентичен ручному print каждой части).
Всё тоже самое можно было сделать в runtime, через std::map — но тогда ошибки типа ссылки внутри строки на неправильную переменную отлавливались бы в runtime, не говоря уже о penalty.

EP>>>>·>Нет, не такой же. "exampleMethod1" это просто строковой литерал, а exampleMethod1 — символ языка.
EP>>>>Это лишь форма. Что это меняет с точки зрения обсуждаемой проблемы статики/динамики/отлова ошибок?
EP>>·>Что в первой форме ты явно даёшь понять, что это просто литерал, значит компилятор о нём ничего не знает и не проверяет. А во втором случае — ты неявно ожидаешь поддержку со стороны компилятора.
EP>>Это всё форма. Повторяю вопрос.
·>Так любом ЯП это форма на первом месте. Когда текст программы выглядит _ожиданно_, принцип наименьшего удивления.
·>ЯП в первую очередь нужен не для компьютера (который может отлавливать ошибки), а для человека, чтобы он читая текст программы сразу понимал что делается в данной строчке кода, плюс IDE в помощь в наборе/навигации кода. Поэтому форма чрезвычайно важна.

Именно потому что форма важна dynamic и является полезным, так даёт лаконичность и выразительность. Но, опять таки, с точки зрения обсуждаемой проблемы статики/динамики/отлова ошибок — разницы с "exampleMethod1" нет

EP>>>>Лаконичность динамического кода. Со строками у тебя точно также не будет рефакторингов и т.п. только форма менее удобная и выразительная.
EP>>>>Да и в какой definition ты собираешься переходить? dynamic'ом например может быть xml документ: xml_root.person.name = "John";
EP>>·>Ничем не хуже xml_root.set("person.name", "John");
EP>>Ещё раз. Куда должна перейти IDE по "person.name"?
·>В том то и дело что некуда. Потому что это по сути текст в выводе программы, как и "John".

И в чём тогда претензия? В обоих вариантах переходить некуда

EP>>Почему ратуем? Я лишь заявляю что статика на C++ намного доступнее и используется намного чаще чем на Java. И да — больше статики обычно означает больше проверок выполняемых компилятором.
EP>>При этом динамические фишки вполне имеют своё применение (в то числе C# dynamic) — я например сам использую в том числе Python и Lisp
·>Ок, я наверное просто к терминологии прикапываюсь. Выразительность системы типов я не отношу к статичности/динамичности. Ты, видимо, относишь (мне непонятно почему). В общепринятой терминологии так не принято.

Речь про фактический код. Если в одной программе List<Object> и постоянные динамические касты, а в другой List<Derived> и никаких кастов — то первая более динамическая чем вторая. При этом речи о том что такой язык имеет динамическую типизацию не идёт — это всё та же статическая типизация.

EP>>·>Ну пока ещё не добавили. А runtime рефлексия заменяет compile-time при наличии runtime кодогенерации.
EP>>Не заменяет. В частности ошибки у тебя будут ловится только на стадии runtime кодогенерации
·>Какие конкретно ошибки?

Те которые ловит compile-time рефлексия. Например сериализация основанная на ней может поймать ошибки вида сериализации не реализованных базовых типов на этапе компиляции. Если же ты будет делать это через runtime рефлексию, даже с какой-угодно последующей кодогерацией — то эти ошибки у тебя проявятся уже на этапе работы приложения, так как поезд compile-time уже ушёл.

·>И что, например, у тебя сможет поймать компилятор в xml_root.person.name = 3.1415926;?

Пример xml_root.person.name вообще-то из другой области.

EP>>·>m4 или Пайтон — не большая разница. Приходится тащиь ещё один инструмент, что усложняет инфраструктуру. (например, теперь помимо Плюсов нам нужен ещё и Пайтон ставить,
EP>>Обычно Python уже так или иначе используется в процессе сборки, да и поставить не проблема.
·>Т.е. что инфрасткрутура более сложная для Плюсов — ты согласен?

Инфраструктура более сложная — это как раз таки основной момент, а не то что ты там думаешь про утечки, segfault или кодогенерацию. Собрать все зависимости на всех платформах, интерфейсы для всех сторонних языков, из этого всего на каждой платформе слепить пакеты — вот трудоёмкая и муторная задача. Если же сторонних зависимостей мало, а тем более платформ — то особо никаких инфраструктргых проблем нет.
Но кодогенерация например на Python вообще проблемой не является, так как подключается элементарно (например CMake автоматом сгенерирует нужные правила что для MSVS, что для make, etc) — это ты пытаешься хоть к чему-нибудь придраться.

EP>>·>да ещё поди библиотеки какие-нибудь к нему).
EP>>Вообще не проблема — pip install dependency
·>Ага, ещё один пунктик в многостраничый документ для new joiners.

Не в документ, а в автоматический скрипт. И даже не факт что это будет новой строчкой, так как язык типа Python обычно УЖЕ есть.

EP>>·>Какой смысл от него в Яве?
EP>>Я тебе объясняю что в Java не dynamic_cast'а нет (как ты утверждаешь), а наоборот static_cast'а.
·>Ах. в этом смысле... Ты говоришь, как будто это что-то хорошее. static_cast даёт UB, и хорошо что нет.

Я не говорю что это хорошее или плохое, я говорю что именно dynamic_cast в Java есть.

EP>>>>Нет.
EP>>·>Что неверно-то?
EP>>То что невозможно генерировать код в runtime.
·>Ну так невозможно же. Вызов компилятора из командной строки это не кодогенерация.

Это компиляция, а кодогенерация может происходить на один этап ранее, тоже в runtime

EP>>>>Я не предлагаю это как возможность, я лишь показываю что это без проблем реализуется. В частности в приведённом примере реализован библиотечный runtime DSL, AST которого налету оптимизируется под конкретные данные, и компилируется для CPU или GPU.
EP>>·>Фигня какая-то. На C++ написан JVM JIT, но как мне кажется, что это не значит, что сам C++ умеет JIT.
EP>>Ещё раз — смотри Cling — это JIT для языка C++.
·>Ок, но это не часть языка.

А что по твоему часть языка? То что в ISO? И какой там ISO у Java?
И почему вообще нужно ограничиваться сферической "частью языка", когда для решения реальных проблем это не имеет значения?

EP>>·>что это не значит, что сам C++ умеет JIT.
EP>>Что значит сам умеет? C++ отранслированный в JavaScript и запущенный в V8 — он как, умеет JIT или нет?
·>Не умеет. Это не часть языка.

x64, x32, arm, pgo, constant propagation, etc, etc — тоже не часть языка, значит C++ "их не умеет"?
Ну тогда он и нативный код не умеет — шах и мат

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

V>>>>В плюсах без хаков.
EP>>·>Суть динамического приведения типов в том, что типы приводятся в рантайме. Если ты неявно подменил задачу что работать с типами можно в компайл-тайме, то зачем тебе динамическое приведение типов в такой задаче?
EP>>Речь как раз о том, что в разных языках различные по удобству средства выражения статики. В некоторых, типа Python — и вовсе сплошная динамика. В других же типа Java — есть статика, но акцент смещён в сторону динамики. В третьих сильная статика — например C++, D, Nemerle.
·>Интересная классификация. А C куда отнесёшь?

В C статика очень плохо выражается, очень часто используют штуки типа стирания типов (void* и т.п.), при этом даже без всяких динамический проверок — это скорее отдельная категория.

EP>>Ярчайший пример для иллюстрации — первые версии Java и C# — в них не было Generic'ов, и коллекции представляли из себя по сути List<Object> — так вот получались сплошные касты, хотя казалось бы задача чисто статическая, и языки статически типизированные.
·>Касты не означают динамику, каст это приведение типов. Динамика это возможность изменения типов объектов в рантайм.

Какого именно изменения? monkey patch или что?

·> Тип _объекта_ ни в одном из перечисленных языков менять нельзя (только в Питоне). Object o = new String() — тип "o" будет тип String, изменить ты это не сможешь, хоть лопни.

А что будет в Python по-твоему?

·>Разница между C++ и Java будет лишь в том, что неверное приведение типа в C++ — UB, а в Java — exception. Всё.

Это тебя опять куда-то не в ту сторону понесло. Убери из C++ все UB конструкции, статических проверок от этого не уменьшится, compile time map никуда не исчезнет

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

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

S>>Здравствуйте, ·, Вы писали:
S>>·>Правильно. Я говорю лишь о том, что подход с .net native не единственно верный. И он может быть когда-нибудь появится и не повалит сервера апп-стора, в то время как ART с твоей любимой предварительной компиляцией работает уже три года на миллионах девайсов.

S>> Я так понимаю, что это аналог NGEN которому огромное количество лет и с теми же недостатками.
·>Насколько я знаю, главный недостаток NGEN для мобильных девайсов в том, что его нет. Вот что пишут о .NET Micro Framework:
·>

The CLR is an interpreter rather than a just-in-time compiler, and uses a simpler mark-and-sweep garbage collector instead of a generational approach.

·>Т.е. вообще тупой интерпретатор с примитивным GC. Вот они и стали пилить этот самый .net native.

.Net Native сейчас идет под UWP Что такое приложение UWP?
Там не только мобильные устройства. .NET Micro Framework это другое Microsoft .NET Framework во встраиваемых приложениях.

S>> Net Native не зависит от установленного Фреймворка.
·>Зависимость от фреймворка сама по себе ничем не плохо. AOT не означает, что нужно непременно собирать нативные бинарники и распространять их магазином. В ART сделано оптимально — финальная компиляция (из байткода в натив) сделана на девайсе, в момент установки. Т.е. установленная программа — нативный код — проблем с батареей и со стартом приложения нет. .net native предлагает распространять нативные бинарники изначально, что может серьёзно увеличить нагрузку на апп-сторы в случае большого числа вариантов девайсов или версий этого самого .net native.

Ну моделей смартфонов то немного, и держать для каждой модели скомпилированные файлы. Это же не миллионы. И речь пока идет только об UWP которые только на продуктах MS, и Xamarin для IPhone. Да даже если для андроида, то это не огромное количестао аппаратов.
А вот выхлоп за счет более оптимизируещего компилятора он есть.
·>Так что из того что ты написал — нет ничего нового (ну кроме COM для linux), это уже несколько лет успешно работает на java платформе, этот самый .net native просто попытка догнать, и (лично моё мнение) не самая удачная, поживём — увидим.

Есть альтернативное решение. По сути это аналог С++ со сборкой мусора. Я уже приводил тебе ссылки на stack stackalloc
и
roslyn-linq-rewrite

Так что развитие идет, и главное увеличивается конкуренция которая стимулирует постоянное улучшение продуктов.