Здравствуйте, Ikemefula, Вы писали:
PM>>>>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR I>>>Зато C/С++ есть для JVM EP>>Покажи нормальный компилятор C++ для JVM. I>Не следил за вопросом.
А знание про "С++ есть для JVM" тебе внутреизвилинно прямо с Альфа Центавры пришло?
I>Качество генерации байткода у джавы и шарпа вполне нормальное. Основные проблемы с производительностью даёт сам джыт. Какой бы ты наипрекрасный байткод не подсунул, джыт всё равно его опаскудит.
Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
Согласен?
Здравствуйте, Serginio1, Вы писали:
_>>1. Раз всё делается на JS, то тогда причём тут собственно .net? S> Ну например есть TypeScript. Да и серверную часть тоже нужно писать на Asp.Net mvs писать запросы к базе итд. Клиентская часть далеко не все.
А причём тут TypeScript и .Net? )
_>>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно). S> А где же высокоскоростной C++?
Он там везде — на нём написаны: сервер (nginx), интерпретатор скриптов (Python), база данных (PostgreSQL/MySQL/SQlite).
_>>Распараллеливание может быть актуально (собственно только в этом направление и есть прогресс в последнее время) для серверных решений. А для всего остального, из выше перечисленного, это абсолютно не актуально. S> Ну почему. Сейчас все пишется через await, Ajax ы. Это конечно не System.Threading.Tasks.Parallel но ассинхронные вычисления. S>Но мы то говаорим о вытеснении C++ более медленных платформ.
Причём тут программная часть? ) Я говорю про проблемы быстродействия железа. Они решаемы распараллеливанием только в серверах (и то там не всё так просто). В мобильных устройствах производительность ограничена не процессором, а аккумулятором. А в embedded (частью чего и является новомодный интернет вещей) у нас вообще оперативная память в 64 КБ, в которые jvm/clr даже теоретически не лезут.
_>>Что же касается http-серверов, то это достаточно тривиальная вещь, которую частенько реализуют заново в разных проектах. Более того, есть множество гораздо более сложных вещей, которыми заняты "среднестатистические программисты". К примеру любая современная онлайновая игрушка на порядок сложнее. S>Ты путаешь сервисы с серверами. Мы говорим об IIS, апаче https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2
Я не путаю))) И нормальный сервер это как раз не апач или IIS, а скажем Nginx. В качестве законченного решения. А подобные же вещи в качестве библиотеки встречаются в разных проектах на каждом шагу. )))
_>>Да, кстати, а авторы того же 1C — они значит с Марса всё же? ))) S> Они отличаются от среднестатистических программистов. Еще раз повторю, что есть рынок на котором требуются решения задач. S>Есть рынок средств и программистов с разной квалификацией итд. И побеждает тот кто предлагает лучшее по критерию цена качество время
Во многих местах нет возможности выбрать технологию, как раз потому что аналоги слишком жирные/медленные. )))
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>
EP>Причем самыми востребованными программистами остаются специалисты, пишущие на «1С» и PHP.
EP>И что? Вывод дальше какой? Эникейщики ещё более востребованы
Где. И ктот такие эникейщики? На каком языке программируют?
S>> Ты меня не читаешь.
EP>Читаю.
S>>Я говорю, что ускоряю скорость отчетов в 100 раз. Все довольны, но иногда прихожу к буху и спрашиваю каким отчетом пользутесь, а они говоря, что по привычке старым. При этом это не доли секунд, а пол часа.
EP>А ещё раз говорю, это один из вариантов. И я не оспариваю то что этот вариант реальный.
S>>>> поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много. EP>>>Много, и тормоза отнюдь не двукратные. S>> Правильно, значительно меньше при правильном написании алгоритма. Все твои примеры это выбор самого плохого подбора алгоритма.
EP>Это уже пошло отрицание реальности. Все мои примеры вообще алгоритм не меняют. Меняют уровень абстракции. EP>Если добавили замыкание и ФВП, и в результате чего получили многократные тормоза и отжоры памяти — это не замена алгоритма, это использование более высокоуровневых средств.
Где? У тебя только два примера это векторизация и тормоза лямбд в неизвестно в каком алгоритме. Все остальное сортировки максимум в 2 раза на интах. На больших структурах будет значительно меньше, так как сравнение и будет по времени больше чем вызов незаинлайненного метода.
EP>Если мы обвернули примитивную операцию в класс, для удобства, не меняя сути всего алгоритма — это использование более высокоуровневых средств. EP>Если вместо ручной склейки умножения массивов и операции умножения элементов мы реализуем их по отдельности, а склейку делает сам компилятор — это не замена алгоритма. EP>И т.д. и т.п.
Опять же это сейчас для компилятора главное не скорость, а безопасность. В свое время VladD2 еще на видби показывал пример где в качестве компаратора выступала структура и методы инлайнились.
S>>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало. S>>Не все так однозначно.
EP>А обход графа это бесплатно что-ли? EP>Ты видимо слышал про сдвиг указателя, но приплёл его абсолютно не к месту. Тот самый сдвиг указателя, о котором часто вспоминают, происходит при выделении памяти из первого поколения, а не при сборки мусора. При сборки происходит обход графа живых объектов, с их копированием (зависит от реализации).
Есть разные стратегии. И если граф достижимых объектов очень мал, то это значительно эффективнее Delete. По сути это как структуры на стеке.
Проблемы возникают когда граф большой и есть изменения в старших поколениях. Но в большинстве случаев мало отличается от размещения структур на стеке.
S>>Если таких специалистов оочень мало, то будут побеждать те языки где сложность входа значительно меньше.
EP>Побеждать в чём? В задачах неприхотливых ни к скорости, ни к потреблению энергии, ни к потреблению памяти? Да, конечно будут.
Побеждать в тендере на разработку.
S>>Как ты думаешь, что проще для изучения 1С++ или 1С?
EP>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще.
А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++
S>>>> В итоге все зависит от компилятора. Например TS тоже транслируется в JS и ничто не мешает транслировать в более оптимальный. Здесь проблема не языков а компиляторов которые совершенствуются. EP>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты. S>> В C# еще больше.
EP>Ещё больше чего? Бесплатных высокоуровневых абстракций?
S>>Посмотри на тот же Code First и Linq.
EP>Это C# Linq бесплатный?
Значительно меньше, чем ожидание запроса к БД. И оочень удобный в применении. EP>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.
Ну дык в C# то он уже лет 7. Отстаете.
S>>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.
EP>Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке.
Автоматом их не сделать это же Idispath без typeInfo. Но можно вручную написать диспинтерфейсы.
S>>>> Вывод в том, что существование тех или иных языков или платформ вызвано не только скоростью выполнения EP>>>В целом да, а в частности нет. Например сделали язык заточенный под скорость, потому что нужна скорость — вопрос, чем вызвано его существование? S>> Тем, что у него есть своя ниша. А вот какова емкость этой ниши?
EP>Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да. EP>Дальше что? Ты можешь сразу сказать к чему ты подводить?
И спросила Нина тихо:
— Разве плохо быть портнихой?
Кто трусы ребятам шьёт?
Ну конечно, не пилот.
Лётчик водит самолёты —
Это очень хорошо.
Повар делает компоты —
Это тоже хорошо.
Доктор лечит нас от кори,
Есть учительница в школе.
Мамы разные нужны.
Мамы всякие важны.
Дело было вечером,
Спорить было нечего.
S>>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит EP>>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках? S>> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С
EP>И??? Вывод какой?!
Смотри выше. Если скорость будет во главе угла то будут 2 сценария
1. Оптимизация JIT компилятора. Что и сейчас происходит RyuJIT
2. Платят больше, есть вакансии, значит будут переходить на C++
и солнце б утром не вставало, когда бы не было меня
EP>>Причем самыми востребованными программистами остаются специалисты, пишущие на «1С» и PHP.
EP>>И что? Вывод дальше какой? Эникейщики ещё более востребованы S> Где. И ктот такие эникейщики? На каком языке программируют?
https://en.wikipedia.org/wiki/Any_key https://ru.wiktionary.org/wiki/%D1%8D%D0%BD%D0%B8%D0%BA%D0%B5%D0%B9%D1%89%D0%B8%D0%BA
S>>> Правильно, значительно меньше при правильном написании алгоритма. Все твои примеры это выбор самого плохого подбора алгоритма. EP>>Это уже пошло отрицание реальности. Все мои примеры вообще алгоритм не меняют. Меняют уровень абстракции. EP>>Если добавили замыкание и ФВП, и в результате чего получили многократные тормоза и отжоры памяти — это не замена алгоритма, это использование более высокоуровневых средств. S> Где? У тебя только два примера это векторизация и тормоза лямбд в неизвестно в каком алгоритме.
Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса.
А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
.
EP>>Если мы обвернули примитивную операцию в класс, для удобства, не меняя сути всего алгоритма — это использование более высокоуровневых средств. EP>>Если вместо ручной склейки умножения массивов и операции умножения элементов мы реализуем их по отдельности, а склейку делает сам компилятор — это не замена алгоритма. EP>>И т.д. и т.п. S> Опять же это сейчас для компилятора главное не скорость, а безопасность.
Как это относится к контексту? Ты говоришь что я меняю алгоритм, я тебе разъясняю что нет. Ты в ответ отвечаешь "сейчас для компилятора главное не скорость, а безопасность" — где логика
S>>>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало. S>>>Не все так однозначно. EP>>А обход графа это бесплатно что-ли? EP>>Ты видимо слышал про сдвиг указателя, но приплёл его абсолютно не к месту. Тот самый сдвиг указателя, о котором часто вспоминают, происходит при выделении памяти из первого поколения, а не при сборки мусора. При сборки происходит обход графа живых объектов, с их копированием (зависит от реализации). S> Есть разные стратегии.
В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?
Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.
S>И если граф достижимых объектов очень мал, то это значительно эффективнее Delete.
Какого конкретно Delete?
S>>>Как ты думаешь, что проще для изучения 1С++ или 1С? EP>>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще. S> А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++
Водители для себя решают ту же задачу что и программисты — зарабатывание денег, именно на эту задачу ты здесь постоянно переключаешься.
EP>>>>Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты. S>>> В C# еще больше. EP>>Ещё больше чего? Бесплатных высокоуровневых абстракций? S>>>Посмотри на тот же Code First и Linq. EP>>Это C# Linq бесплатный? S> Значительно меньше, чем ожидание запроса к БД. И оочень удобный в применении.
Тут где-то рассказывали что упирались во вполне реальные тормоза Linq, так что причислять его к "бесплатным высокоуровневым абстракциям" — в корне не верно
EP>>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку. S> Ну дык в C# то он уже лет 7. Отстаете.
Ты путаешь "можно реализовать" и "он нужен многим, все его с нетерпением ждут".
S>>>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch. EP>>Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке. S> Автоматом их не сделать это же Idispath без typeInfo.
И что? Схема же есть где-то?
Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
S>>> Тем, что у него есть своя ниша. А вот какова емкость этой ниши? EP>>Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да. EP>>Дальше что? Ты можешь сразу сказать к чему ты подводить? S>
S> И спросила Нина тихо:
S> — Разве плохо быть портнихой?
S> Кто трусы ребятам шьёт?
Ваганович?
S>>>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит EP>>>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках? S>>> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С EP>>И??? Вывод какой?! S>Смотри выше.
Где? В одном сообщении было "смотри ниже", но вывода не было, сейчас "смотри выше"
S>Если скорость будет во главе угла то будут 2 сценария S>1. Оптимизация JIT компилятора. Что и сейчас происходит RyuJIT
Ещё раз, дело не только в оптимизаторах, а ещё во многом и в языках. Когда происходит вызов лямбды на C++ — компилятор уже видит без всяких оптимизаций какой конкретно код вызывается — чисто по построению кода, и может его заинлайнить
Прямая аналогия: код на языках с динамической типизацией намного труднее оптимизировать до одного уровня кода со статической типизацией.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, Serginio1, Вы писали:
EP>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты. S>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.
PM>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.
С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
PM>>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR
I>Зато C/С++ есть для JVM и .Net и шота не видно никаких чудес. Джава и шарп рвут всё на своих платформах. Как то так.
2006-12-16: Now using GCC 3.3.6 to compile out of the box on Ubuntu 6.10
Download
Note that NestedVM uses GCC 3.3.6, which will not compile under GCC 4.1 or later.
Ещё одна картинка <троллейбус из буханки хлеба.jpeg>
Только тролль или эльф может утверждать, что программы в управляемых средах будут выигрывать у native. Сказкам про победную поступь JIT исполнилось уже 20 лет
Ну а кто там в песочнице быстрее между собой Java или Scala, C# или Nemerle это как то выходит за пределы темы.
PM>>Почитайте на досуге как авторы LMAX героически боролись
I>Неинтересно, это разница в платформах.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>1. Раз всё делается на JS, то тогда причём тут собственно .net? S>> Ну например есть TypeScript. Да и серверную часть тоже нужно писать на Asp.Net mvs писать запросы к базе итд. Клиентская часть далеко не все.
_>А причём тут TypeScript и .Net? )
_>>>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно). S>> А где же высокоскоростной C++?
_>Он там везде — на нём написаны: сервер (nginx), интерпретатор скриптов (Python), база данных (PostgreSQL/MySQL/SQlite).
То есть в итоге то ты пишешь на питоне, а не на С++. Мы уже про это говорили, что ниша С++ там где нужна скорость. А там где скорость разработки ты же сам используешь питон.
_>Причём тут программная часть? ) Я говорю про проблемы быстродействия железа. Они решаемы распараллеливанием только в серверах (и то там не всё так просто). В мобильных устройствах производительность ограничена не процессором, а аккумулятором. А в embedded (частью чего и является новомодный интернет вещей) у нас вообще оперативная память в 64 КБ, в которые jvm/clr даже теоретически не лезут.
Вот еще одна ниша для С++
_>>>Что же касается http-серверов, то это достаточно тривиальная вещь, которую частенько реализуют заново в разных проектах. Более того, есть множество гораздо более сложных вещей, которыми заняты "среднестатистические программисты". К примеру любая современная онлайновая игрушка на порядок сложнее. S>>Ты путаешь сервисы с серверами. Мы говорим об IIS, апаче https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2
_>Я не путаю))) И нормальный сервер это как раз не апач или IIS, а скажем Nginx. В качестве законченного решения. А подобные же вещи в качестве библиотеки встречаются в разных проектах на каждом шагу. )))
_>>>Да, кстати, а авторы того же 1C — они значит с Марса всё же? ))) S>> Они отличаются от среднестатистических программистов. Еще раз повторю, что есть рынок на котором требуются решения задач. S>>Есть рынок средств и программистов с разной квалификацией итд. И побеждает тот кто предлагает лучшее по критерию цена качество время
_>Во многих местах нет возможности выбрать технологию, как раз потому что аналоги слишком жирные/медленные. )))
Ну и какова емкость этой ниши?
Я не против С++. Я про то, что он не универсален, как тут пытаются заявить. И что скорость в большинстве случаев не является главным критерием, даже во времена когда память в 64 КБ была естественным делом. Помню писал на паскале на ДВК 2 и время компиляции было полчаса. В то же время на Бейсике пусть и с огромными тормозами, но не было задержек с компиляцией. И большинство использовало бейсик
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты. S>>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.
PM>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release. S> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.
Опиши конкретный use-case.
Если нужно вызвать метод с произвольным именем (method) и произвольным количеством аргументов (a1, a2, ...), без всякого предварительного описания — то можно например вот так:
Dynamic x = ...;
x.call("method", a1, a2, ...);
// or
x("method", a1, a2, ...);
// or
x > "method"_(a1, a2, ...);
А если заранее описать список возможных имён методов, то можно и так:
PM>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release. S> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.
S>> Где? У тебя только два примера это векторизация и тормоза лямбд в неизвестно в каком алгоритме.
EP>Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса. EP>А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.
EP>>>Если мы обвернули примитивную операцию в класс, для удобства, не меняя сути всего алгоритма — это использование более высокоуровневых средств. EP>>>Если вместо ручной склейки умножения массивов и операции умножения элементов мы реализуем их по отдельности, а склейку делает сам компилятор — это не замена алгоритма. EP>>>И т.д. и т.п. S>> Опять же это сейчас для компилятора главное не скорость, а безопасность.
EP>Как это относится к контексту? Ты говоришь что я меняю алгоритм, я тебе разъясняю что нет. Ты в ответ отвечаешь "сейчас для компилятора главное не скорость, а безопасность" — где логика
S>>>>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало. S>>>>Не все так однозначно. EP>>>А обход графа это бесплатно что-ли? EP>>>Ты видимо слышал про сдвиг указателя, но приплёл его абсолютно не к месту. Тот самый сдвиг указателя, о котором часто вспоминают, происходит при выделении памяти из первого поколения, а не при сборки мусора. При сборки происходит обход графа живых объектов, с их копированием (зависит от реализации). S>> Есть разные стратегии.
EP>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"? EP>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.
Старшие поколения не используются для анализа. Используются только изменения если изменений не было, значит нет достижимых объектов, значит можно передвинуть указатель кучи на начало.
S>>И если граф достижимых объектов очень мал, то это значительно эффективнее Delete.
EP>Какого конкретно Delete?
Это зависит от менеджера памяти. У вас же там зоопарк.
S>>>>Как ты думаешь, что проще для изучения 1С++ или 1С? EP>>>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще. S>> А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++
EP>Водители для себя решают ту же задачу что и программисты — зарабатывание денег, именно на эту задачу ты здесь постоянно переключаешься.
То есть водители конкурируют с программистами ? Странное у тебя видение.
EP>>>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку. S>> Ну дык в C# то он уже лет 7. Отстаете.
EP>Ты путаешь "можно реализовать" и "он нужен многим, все его с нетерпением ждут".
В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю
S>>>>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch. EP>>>Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке. S>> Автоматом их не сделать это же Idispath без typeInfo.
EP>И что? Схема же есть где-то? EP>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики. Я в свое время для Delphi реализовывал Idispath для ускорения и типизации. Был таким же как и ты, пока не понял, что большинству на скорость наплевать.
S>>>> Тем, что у него есть своя ниша. А вот какова емкость этой ниши? EP>>>Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да. EP>>>Дальше что? Ты можешь сразу сказать к чему ты подводить? S>>
S>> И спросила Нина тихо:
S>> — Разве плохо быть портнихой?
S>> Кто трусы ребятам шьёт?
EP>Ваганович?
S>>>>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит EP>>>>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках? S>>>> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С EP>>>И??? Вывод какой?! S>>Смотри выше.
EP>Где? В одном сообщении было "смотри ниже", но вывода не было, сейчас "смотри выше"
Кто трусы ребятам шьёт?
S>>Если скорость будет во главе угла то будут 2 сценария S>>1. Оптимизация JIT компилятора. Что и сейчас происходит RyuJIT
EP>Ещё раз, дело не только в оптимизаторах, а ещё во многом и в языках. Когда происходит вызов лямбды на C++ — компилятор уже видит без всяких оптимизаций какой конкретно код вызывается — чисто по построению кода, и может его заинлайнить EP>Прямая аналогия: код на языках с динамической типизацией намного труднее оптимизировать до одного уровня кода со статической типизацией.
Это же может видеть как компилятор в MSIL так и в машинный код. Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные http://infostart.ru/public/402433/
Просто пока это не нужно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса. EP>>А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
— там разница больше чем 10x.
* Приводил несколько примеров показывающих что даёт замена на ссылочную структуру (которые дефолтные в управляемых средах) — там было 80x и 200x.
S>Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Здесь в C++ варианте лямбда, ФВП и итераторы, а в C# варианте обычный рукопашный цикл
S>Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.
Хочешь отрицать реальность, не хочешь видеть примеры? Твоё право, но мне уже надоедает по несколько раз приводить одни и те же примеры.
EP>>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"? EP>>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы. S> Старшие поколения не используются для анализа. Используются только изменения если изменений не было, значит нет достижимых объектов, значит можно передвинуть указатель кучи на начало.
Указатель какой именно кучи на начало? Какого поколения?
S>>>И если граф достижимых объектов очень мал, то это значительно эффективнее Delete. EP>>Какого конкретно Delete? S>Это зависит от менеджера памяти. У вас же там зоопарк.
Разных GC и их настроек тоже зоопарк, а также целый зоопарк всяких off heap решений, возникших не от праздного интереса.
S>>>>>Как ты думаешь, что проще для изучения 1С++ или 1С? EP>>>>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще. S>>> А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++ EP>>Водители для себя решают ту же задачу что и программисты — зарабатывание денег, именно на эту задачу ты здесь постоянно переключаешься. S> То есть водители конкурируют с программистами ? Странное у тебя видение.
Причём тут конкуренция? Глобально задача у каждого программиста заработать денег (не считая for fun и т.п.), себе лично, а не конкурировать с кем-то. Ты же в это русло переводишь
EP>>>>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку. S>>> Ну дык в C# то он уже лет 7. Отстаете. EP>>Ты путаешь "можно реализовать" и "он нужен многим, все его с нетерпением ждут". S> В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю
Конкретно где везде? Для каких задач?
EP>>И что? Схема же есть где-то? EP>>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу? S> Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики.
Не реализуй, используй так — получишь меньше гарантий в compile-time. При этом не обязательно плодить гору boiler-plate, пример в соседнем сообщении.
S> Я в свое время для Delphi реализовывал Idispath для ускорения и типизации. Был таким же как и ты, пока не понял, что большинству на скорость наплевать.
Каким таким? Ты делаешь какие-то неверные предположения.
S>Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++. EP>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений. EP>Согласен?
Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким
Здравствуйте, Ikemefula, Вы писали:
I>>>Качество генерации байткода у джавы и шарпа вполне нормальное. Основные проблемы с производительностью даёт сам джыт. Какой бы ты наипрекрасный байткод не подсунул, джыт всё равно его опаскудит. EP>>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++. EP>>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений. EP>>Согласен? I>Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким
А какой из них какой?
Ты же выше говоришь что основные проблемы от JIT'а, а байткод нормальный? Вот и сравним
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>1 Вроде как очевидно, что здесь разные платформы. Попробуй тот же мега-с++ код скомпилировать в дотнет и открой для себя страшное — скорость сильно вряд ли будет отличаться от C#.
EP>Не верно. Низкоуровневый C# быстрее в разы высокоуровневого C# в пределах .NET, потому что язык такой — абстракции дорогие.
Ну вот возьми С++ под дотнет да покажи эти "в разы"
EP>Высокоуровневый код C++ и ручной низкоуровневый аналог даёт зачастую идентичный машинный код, в этом и есть фишка.
"Зачастую" это слишком мутный термин, что бы рассматривать его как аргумент.
EP>В C# скомпилированном в JavaScript точно также как и на .NET не будет заинлайненной лямбды, и от этого точно также будут тормоза.
C# это язык ровно одной платформы. Хочешь сравнить __языки__ — компилируй С++ под дотнет. В противном случае получается или сравнение плохого с хорошим, или сравнение платформ.
Например, инлайн функции в дотнете принято перекладывать на джыт. Отсюда и подсказки джыту — [MethodImpl(MethodImplOptions.AggressiveInlining)]
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким
EP>А какой из них какой? EP>Ты же выше говоришь что основные проблемы от JIT'а, а байткод нормальный? Вот и сравним
Сравнивать нужно с С++ под JVM, что бы все были в равных условиях.
Здравствуйте, Ikemefula, Вы писали:
EP>>Высокоуровневый код C++ и ручной низкоуровневый аналог даёт зачастую идентичный машинный код, в этом и есть фишка. I>"Зачастую" это слишком мутный термин, что бы рассматривать его как аргумент.
Я неоднократно сравнивал ручные аналоги коду с абстракциями, например: 1
— ассемблерный код получался идентичным. Да и вообще часто смотрю во что там скомпилировался код.
I>Например, инлайн функции в дотнете принято перекладывать на джыт. Отсюда и подсказки джыту — [MethodImpl(MethodImplOptions.AggressiveInlining)]
Неважно кто делает инлайн. На C++ его сделать проще из-за свойств самого языка.
Здравствуйте, Ikemefula, Вы писали:
I>>>Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким EP>>А какой из них какой? EP>>Ты же выше говоришь что основные проблемы от JIT'а, а байткод нормальный? Вот и сравним I>Сравнивать нужно с С++ под JVM, что бы все были в равных условиях.
А я что предлагаю? Не, ну действительно "буквы не читай, сообщения пиши"
EP>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
EP>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
EP>Согласен?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты. S>>>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.
PM>>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release. S>> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.
EP>Опиши конкретный use-case. http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=614821&threadtype=0&print=1&partt614821=1 EP>Если нужно вызвать метод с произвольным именем (method) и произвольным количеством аргументов (a1, a2, ...), без всякого предварительного описания — то можно например вот так: EP>
EP>Dynamic x = ...;
EP>x.call("method", a1, a2, ...);
EP>// or
EP>x("method", a1, a2, ...);
EP>// or
EP>x > "method"_(a1, a2, ...);
EP>
А если заранее описать список возможных имён методов, то можно и так: EP>
EP>x.method(a1, a2, ...)
EP>
Но согласись все равно убожество. Читать такой код неудобно.
На C# Сделать прокси легко. Вот например как обернуть в Idispatch любой объект .Net http://infostart.ru/public/238584/
Есть DynamicObject, expandoobject все очень красиво
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, Serginio1, Вы писали:
PM>>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release. S>> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.
PM>Ну dynamic ведь тоже не по волшебству работает. Какие сложности получать у IDispatch нужную информацию и вызывать Invoke? В 2007 это не было проблемой: http://www.codeproject.com/Articles/19962/Driving-Microsoft-Word-using-VOLE
Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.
