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


K>Это не факты а их подтасовка. Какой-то отдельно взятый проект неизвестно как написанный. Мало что ли их сдохло на всех языках программирования?
Возможно, 80% экономии памяти бы дало переписывание с Java на Java.
Если, к примеру, взять махровое легаси, написанное для Java 1.2, где банальный разбор HTTP-запроса состоит из постоянных копирований строк с перевыделениями, и переписать на современную версию с zero-allocation парсерами примитивных типов, то примерно так и получится.

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

S>MSO -- это Microsoft Office?
S>Если так, то хотелось бы пруфов, поскольку в сети валялся доклад разработчиков из MS о том, что там кодовая база на С++ с мохнатых годов, которая была адаптирована в том числе и под Web.
В новостях в 2020 ещё было, что оставят только веб версию для всего — и "десктоп" будет обёртка над веб.

S>Когда приносишь со съемки 1000-1500-2000 фото, то даже десктопный Lightroom слишком тормозной для первичной выбраковки. А если еще умельцы, вроде тебя, его внутрь Хрома засунут, то вааще ахтунг будет.
М.б. вопрос к криворуким разработчикам десктопного Lightroom?

S>>>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени.
Аё>>Вычисления бегают в WASM , WebGPU.

S>На кластерах из тысяч вычислительных нод?
Нейросетки компьютерного зрения бегают в WASM , WebGPU в т.ч. на смартфоне. Это что я лично прикрутил (примотал изолентой ) в веб ui.

S>И тут бы пруфов, что Си ещё лучше. Куча эбедеда уже разрабатывается на C++
Упоротыми.
S> а местами уже и на Rust.
И это печально.

S>>>В общем, в своей современной реальности я не вижу где и как TypeScript может заменить С++.
Аё>>Ты строчишь посты в веб на рсдн.

S>Через браузер написанный на C++ использующим виртуальную машину JS-а, написанную на С++, в KDE, написанном на C++, в Linux-е, ядро которого написано на GNU-диалекте Си.
Кстати о KDE Которое тормозное тупо потому, что C++.

S>Да, мне очень сложно представить все это хозяйство на TypeScript.
Жирный десктопный UI прекрасно бегает в веб. Если ты неосилил- то вопросы к тебе.

S>Так клиентов для подобных вещей и раньше не особо на C++ разрабатывали. Это как бы и не ниша для C++.
Проблема доя C++ разработчиков — это нишевый язык. Ну, ппомимо того, что из него сделали ужас.

Аё>>Я считаю, что пусть растаманы пишут новые прилаги, а не пытаются переписать старые работающие, да ещё и на хуже качество.

S>Так ты примеры приведешь что такого в sudo-rs "поломали", что мешает тебе жить?
Ты по кругу ходишь. Я указал- неосилили feature parity.

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

S>>Да, мне очень сложно представить все это хозяйство на TypeScript.
Аё>Жирный десктопный UI прекрасно бегает в веб. Если ты неосилил- то вопросы к тебе.

Тёма, вот ты, наверное, мне и нужен!

А как заставить код на C# и F# работать в браузере?

А тут Авалонию использую. Когда перевожу в браузерную версию, Web Assembly | Avalonia Docs, то фигня какая-то получается. Во-первых, медленно, что браузер спрашивает, а не прибить ли поток (у меня там рисовалка + расчеты). Во-вторых, и это самое главное, наружу торчит весь байт-код, что очень и очень нехорошо.

Вот, что ты как специалист посоветуешь, чтобы мне существующую кодовую базу, которую я написал на С# и F# за много-много лет, перенести в веб? Ломаю голову, и ничего умного придумать не могу

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

S>>MSO -- это Microsoft Office?
S>>Если так, то хотелось бы пруфов, поскольку в сети валялся доклад разработчиков из MS о том, что там кодовая база на С++ с мохнатых годов, которая была адаптирована в том числе и под Web.
Аё>В новостях в 2020 ещё было, что оставят только веб версию для всего — и "десктоп" будет обёртка над веб.

Так Web-версия базировалась на древнем коде на C++.

S>>Когда приносишь со съемки 1000-1500-2000 фото, то даже десктопный Lightroom слишком тормозной для первичной выбраковки. А если еще умельцы, вроде тебя, его внутрь Хрома засунут, то вааще ахтунг будет.
Аё>М.б. вопрос к криворуким разработчикам десктопного Lightroom?

Покажи продукт лучше. Да еще и написанный не на нативных языках.

S>>>>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени.
Аё>>>Вычисления бегают в WASM , WebGPU.

S>>На кластерах из тысяч вычислительных нод?
Аё>Нейросетки компьютерного зрения бегают в WASM , WebGPU в т.ч. на смартфоне. Это что я лично прикрутил (примотал изолентой ) в веб ui.

И где здесь кластера из тысяч вычислительных нод? А да, ты же тупой Тёмчик, который не может даже прочитать вопрос. Сорри, запамятовал.

S>>Да, мне очень сложно представить все это хозяйство на TypeScript.
Аё>Жирный десктопный UI прекрасно бегает в веб. Если ты неосилил- то вопросы к тебе.

Судя потому, что нет браузера на TypeScript, нет KDE на TypeScript, нет производительных VM для JS на TypeScript, ниасилил не только лишь я.

S>>Так клиентов для подобных вещей и раньше не особо на C++ разрабатывали. Это как бы и не ниша для C++.
Аё>Проблема доя C++ разработчиков — это нишевый язык.

Это не проблема.

S>>Так ты примеры приведешь что такого в sudo-rs "поломали", что мешает тебе жить?
Аё>Ты по кругу ходишь. Я указал- неосилили feature parity.

Это потому, что ты туп настолько, что не можешь ответить на простой вопрос.
Так что еще одна попытка, чтобы еще раз продемонстрировать общественности твою тупизну: какие такие фичи в sudo-rs "поломали", что тебе это мешает?

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

K>>Это не факты а их подтасовка. Какой-то отдельно взятый проект неизвестно как написанный. Мало что ли их сдохло на всех языках программирования?
S>Возможно, 80% экономии памяти бы дало переписывание с Java на Java.

Возможно, нужно было бы пойти по ссылками и прочитать хотя бы поверхносные описания?

S>Если, к примеру, взять махровое легаси, написанное для Java 1.2, где банальный разбор HTTP-запроса состоит из постоянных копирований строк с перевыделениями, и переписать на современную версию с zero-allocation парсерами примитивных типов, то примерно так и получится.

Ну просто шикарное подтверждение тезиса о скорости и других преимуществах GC. Браво!
Оказывается, чтобы было быстро и не ресурсоемко, требуется zero-allocation парсеры. Вот прям раскрытие GC во всей красе.

Такими темпами места для языков с ручным управлением памятью точно не останется.

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

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

K>>В паскале модули появились в 1987 году.

S>Всего-то через 17 лет после появления самого Паскаля. И кого это сейчас волнует?

Сами модули впервые появились в 1975 в модуле, а паскалевские заимствованы из модула-2 1978 т.е. 9 лет на внедрение. Сумасшедшие темпы по меркам С++ с учетом того что в С++ каких-то своих оригинальный идей вобщем-то и нет. Легендарные шаблоны это тоже не страуструповское ноу-хау. Впервые параметрические типы появились в ML (1973 год) за 15 лет добрались до С++. Да что там говорить даже элементарные баги исправляются раз в 20 лет. Тот же iostream который в исходном виде полностью бесполезен, стал хоть как-то полезен с появлением quoted спустя всего каких-то 18 лет.

S>В Java дженерики появились через восемь или девять лет после выхода Java 1.0. И кого это сейчас волнует?

Сумасшедшая скорость по плюсовым меркам.

K>>Всего 33 года Страуструпу потребовалось чтобы умишком пораскинуть.

S>"То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско." (с) г.Kluev

Я не оскорбляю, а констатирую. Страуструп внедряет с такой скоростью, что как будто он собрался жить вечно. И программистов похоже тоже считает бессмертными.

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

K>>>В паскале модули появились в 1987 году.

S>>Всего-то через 17 лет после появления самого Паскаля. И кого это сейчас волнует?

K>Сами модули впервые появились в 1975 в модуле, а паскалевские заимствованы из модула-2 1978

Тем не менее, от появления витовского Паскаля и внедрения модулей в очередной версии Turbo Pascal прошло полтора десятка лет.
Волнует ли это сейчас кого-то?

Нет.

K>Впервые параметрические типы появились в ML (1973 год) за 15 лет добрались до С++.

С учетом того, что С++ появился в 1985-ом, а шаблоны в нем -- в районе 1991-го, то озвученные вами 15 лет -- это вообще как?

S>>В Java дженерики появились через восемь или девять лет после выхода Java 1.0. И кого это сейчас волнует?

K>Сумасшедшая скорость по плюсовым меркам.

Для персонажей с реверсивным умственным развитием: "впервые параметрические типы появились в ML (1973 год)" + в С++, с косплея которого Java начиналась, шаблоны были к 1995-ому году уже 5 лет минимум. Но в Java из завезли в 2003 или 2004.

И кого это сейчас волнует? Да никого от слова совсем.

K>Страуструп внедряет

Вот интересно: это реверсивное умственное развитие, или же альтернативное восприятие реальности заставляет вас говорить, что Страуструп что-то внедряет?
Ставлю и на одно, и на другое сразу.

Для г.Kluev-а и ему подобных: С++ с начала 1990-х развивается комитетом. Перекладывать на Страуструпа то, что происходит с языком после начала работы комитета -- это, по меньшей мере, расписываться в незнании простых вещей.

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

D>Вот, что ты как специалист посоветуешь, чтобы мне существующую кодовую базу, которую я написал на С# и F# за много-много лет, перенести в веб? Ломаю голову, и ничего умного придумать не могу

Я не специалист в wasm ни разу .

Хз. Возможно, придётся вручную отделить код многопоточки в отдельные скрипты (или отдельные wasm). Для браузера WebWorker- это как отдельное приложение без доступа к DOM, близкая аналогия- как если приложение крутит другое, консольное, в фоне и обменивается собщениями через cin-cout.
У WebWorker вначале подписываешься на сообщения от хоста. Хост подписывается на сообщения от web worker. Я делал обёртку на хосте, которая регистрировала что на что отвечает. Естественно, что любой обсчёт на хосте должен успеть между 2 кадрамм- поэтому ни в коем случае ничего с циклами не считать. Просто заворачиваешь посылку отправляешь в web worker- как если бы отправлял на бек.

Собирать wasm мне не довелось Там, где opencv забыла пометить метод в экспорт в wasm- скопипастил код из исходника C++ в код Typescript, благо метод небольшой, на производительности не сказалось.

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

S>Возможно, нужно было бы пойти по ссылками и прочитать хотя бы поверхносные описания?
Возможно. Но я читаю форум в прямом порядке, а не задом наперёд.

S>Ну просто шикарное подтверждение тезиса о скорости и других преимуществах GC. Браво!
Нет. К скорости это имеет косвенное отношение. Мы обсуждаем расход памяти, за который критикуют GC.
И тут начинается интересное:
1. Если мы говорим об одинаковых алгоритмах, то детерминистическая финализация начинает сливать GC в "общем" случае. Потому что общий случай — это дорогой thread-safe аллокатор с поиском свободного места и небесплатный деаллокатор. Да, я в курсе, что высококвалифицированный разработчик, идентифицировав такую проблему, может её нивелировать при помощи custom arena-based allocator, но это как раз и есть "вручную следить за временем жизни каждой ссылки".
2. Если мы говорим о том, что где-то можно заменить алгоритмы с динамическим выделением памяти на стековое выделение, то в современном управляемом мире у нас опять же два подхода — escape analysis (Java) и Value-типы (.Net). Можно пытаться критиковать первый за ненадёжность, а второй — за "рукопашность", но с точки зрения прикладного разработчика примерно оба хороши. В том смысле, что о вопросах вроде "делать ли мне вот этот тип struct или class" задумывается разработчик платформы. А прикладник просто берёт, что дают, и едет. Не принимая решения в каждой точке, то ли делать auto pF = new F(42) try {} finally {free pF}, то ли просто auto f = F(42);. Потому что "и так и так правильно".
S>Оказывается, чтобы было быстро и не ресурсоемко, требуется zero-allocation парсеры. Вот прям раскрытие GC во всей красе.
3. Zero allocation не имеет никакого отношения к GC. Это вопрос алгоритмики. Просто исторически так сложилось, что C/C++ программисты мыслят о строках в категориях "указатель на массив символов". Поэтому примерно любая, даже высокоуровневая библиотека ездит на тех же примитивах. Ну, вот например: https://learn.microsoft.com/en-us/cpp/atl-mfc-shared/reference/coledatetime-class?view=msvc-170#parsedatetime

bool ParseDateTime(
    LPCTSTR lpszDate,
    DWORD dwFlags = 0,
    LCID lcid = LANG_USER_DEFAULT) throw();

(это, кстати, к вопросу "откуда в программе на C++ возьмутся сырые указатели")
Так вот — если я буду парсить заголовки HTTP при помощи даже такой библиотеки, мне придётся обеспечить наличие \0 в нужном месте. Прямолинейный идиоматический способ тут — использовать что-то вроде CString::Mid, который — ай!ой! — вызывает точно такую же аллокацию, как и банальная Java (только медленную, см. выше).
Для того, чтобы это починить, я буду либо писать хитрый код, который на ходу вставляет \0 вместо \r (и нести ответственность за разрушение исходной строки), либо возьму напишу версию ParseDateTime, которая умеет вместо поисков \0 принимать nCount (или, ещё лучше, какой-то вариант span<char>).
Внезапно, это именно то, что делают Java и .Net. То есть получается, что нет никакой разницы между ручной и автоматической сборкой мусора — в обоих подходах можно написать одинаково неудачный код (и одинаково удачный).

Ну, а дальше начинает стрелять то, что код с аллокацией, несмотря на дешёвую аллокацию, получает штраф к производительности второго порядка малости из-за увеличения частоты GC.

S>Такими темпами места для языков с ручным управлением памятью точно не останется.
Ну, примерно так оно и есть. Если в "старых" подходах идиоматические решения на дотнет/джава потребляли память и тормозили, что стимулировало разработчиков вздыхать и переходить в неуютный мир Manual Memory Management, то сейчас ситуация плавно улучшается. Часть выигрыша достаётся бесплатно — благодаря улучшению существующих библиотечных функций. Часть требуют переработки исходного кода (например, переход от string.Substring к ReadOnlySpan<byte>.Slice). Но в любом случае ниша для "давайте потратим x100 ресурсов на выпиливание на С++ чтобы получить +6% перформанса и -15% памяти" постепенно сокращается.

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

S>>Возможно, нужно было бы пойти по ссылками и прочитать хотя бы поверхносные описания?
S>Возможно. Но я читаю форум в прямом порядке, а не задом наперёд.

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

S>>Ну просто шикарное подтверждение тезиса о скорости и других преимуществах GC. Браво!
S>Нет. К скорости это имеет косвенное отношение. Мы обсуждаем расход памяти, за который критикуют GC.

Вы -- может быть.

Конкретно же было сказано следующее: "Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью"
Т.е. для достижения высокой скорости GC нужно больше памяти. Одно с другим тесно увязано.

S>И тут начинается интересное:

Простите, не интересно. Ваше мнение, как одного из евангелистов .NET-а в прошлом, не интересно особенно.

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

Аё>Я не специалист в wasm ни разу .

Аё>Хз. Возможно, придётся вручную отделить код многопоточки в отдельные скрипты (или отдельные wasm). Для браузера WebWorker- это как отдельное приложение без доступа к DOM, близкая аналогия- как если приложение крутит другое, консольное, в фоне и обменивается собщениями через cin-cout.
Аё>У WebWorker вначале подписываешься на сообщения от хоста. Хост подписывается на сообщения от web worker. Я делал обёртку на хосте, которая регистрировала что на что отвечает. Естественно, что любой обсчёт на хосте должен успеть между 2 кадрамм- поэтому ни в коем случае ничего с циклами не считать. Просто заворачиваешь посылку отправляешь в web worker- как если бы отправлял на бек.

Аё>Собирать wasm мне не довелось Там, где opencv забыла пометить метод в экспорт в wasm- скопипастил код из исходника C++ в код Typescript, благо метод небольшой, на производительности не сказалось.

Что многопоточный wasm сам по себе, а однопоточный dom тоже сам по себе — это я в курсе. Значит, с .NET в контексте blazor ты не сталкивался.

Сейчас у меня две печали по этому вопросу. Может быть, кто-то сталкивался.

Во-первых, после обфускатора Obfuscar в веб-браузере не грузится клиентский код. Возможно, что дело в самом обфускаторе. Вчера попадались ссылки, где для этого используют другие обфускаторы. И вроде как может заработать.

Во-вторых, даже без AOT мое веб-клиентское приложение раздувается до мегабайт 70. С AOT — где-то до 100 мегабайт. Да я так замучаюсь платить хостеру за трафик! Причем, в чистом виде инсталятор десктопной версии с WPF у меня весит всего-то мегабайт 11, а это у меня самая навороченная и производительная версия.

Круто, конечно, когда программу не нужно устанавливать, что она может сразу загрузиться и запуститься. Однако возникает большой вопрос в целесообразности идти этим путем

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

D>Значит, с .NET в контексте blazor ты не сталкивался.
Нет. Я религиозно противник пончика , я за кросс платформу

D>Во-вторых, даже без AOT мое веб-клиентское приложение раздувается до мегабайт 70. С AOT — где-то до 100 мегабайт.
Вот вот

D> инсталятор десктопной версии с WPF у меня весит всего-то мегабайт 11, а это у меня самая навороченная и производительная версия.
Наш продукт примерно до 6.5 мег раздулся с годами (фронт на ангуларе). И ещё 12мег — 2 нейросетки, но они подкружаются только когда фича активна. Естественно, бек- другая история там может под терабайт статических данных.

D>Круто, конечно, когда программу не нужно устанавливать, что она может сразу загрузиться и запуститься. Однако возникает большой вопрос в целесообразности идти этим путем
Меньше мозгоправства с релизами. Обратная сторона- нет доступа к API устройства.