Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>В оперденях геометрия не применяется. А в наукоёмких разработках и геймдеве — сплошь и рядом и найти разработчика не проблема.
SVZ>Даже зная вычислительную геометрию человек потратит несколько недель на решение задачи.
Так найти разработчика это проблема или нет? Мы все еще про плюсы?
А может быть, засилие сектантов-бдсмщиков в C++ как раз причина "потратит несколько недель на решение задачи"? Ибо потратит не на решение задачи вычислительной геометрии, а на борьбу с языком C++.
SVZ>нанять студентов, натаскивать их и платить небольшую копеечку.
Т.е. ничего сложного нет. Есть секта C++ с адептами.
Здравствуйте, Тёмчик, Вы писали:
SVZ>>В оперденях геометрия не применяется. А в наукоёмких разработках и геймдеве — сплошь и рядом и найти разработчика не проблема.
SVZ>>Даже зная вычислительную геометрию человек потратит несколько недель на решение задачи. Тё>Так найти разработчика это проблема или нет? Мы все еще про плюсы? Тё>А может быть, засилие сектантов-бдсмщиков в C++ как раз причина "потратит несколько недель на решение задачи"? Ибо потратит не на решение задачи вычислительной геометрии, а на борьбу с языком C++.
Твой ответ запоздал на три года, но тема, похоже, до сих пор актуальная.
Тёма, ты не понял главного. Тут проблема не в языке, а в предметной области. На шарпе ты так же будешь ходить по тем же самым граблям, только твоя программа будет жрать ресурсов на порядок больше.
И это не преувеличение. Одна бывшая Австралийская компания, которая разрабатывала один популярный САПР для электроники на Дельфях, теперь продолжает развивать его на Шарпе. Но вычислительную часть пришлось делать на плюсах. Шарп не тянет и библиотек нет. Это вам не интернет-магазин
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Тёма, ты не понял главного. Тут проблема не в языке, а в предметной области. На шарпе ты так же будешь ходить по тем же самым граблям, только твоя программа будет жрать ресурсов на порядок больше. SVZ>И это не преувеличение. Одна бывшая Австралийская компания, которая разрабатывала один популярный САПР для электроники на Дельфях, теперь продолжает развивать его на Шарпе. Но вычислительную часть пришлось делать на плюсах. Шарп не тянет и библиотек нет. Это вам не интернет-магазин
При словах "дельфи", "шарп" уже все понятно и дальше не стоит притягивать сиплюсы.
Вопрос на засыпку: что мешает отправить вычисления на кластер или в GPU? И чем тут C++ может блеснуть лучше, чем жава или go?
Здравствуйте, Тёмчик, Вы писали: Тё>При словах "дельфи", "шарп" уже все понятно и дальше не стоит притягивать сиплюсы.
Это естественная эволюция большого проекта.
Объем кода такой, что даже пары лет не хватит, чтобы переписать с нуля по фэншую. Тё>Вопрос на засыпку: что мешает отправить вычисления на кластер или в GPU?
Не забывай, это не серверный софт, это софт для рабочего места. Т.е. всё должно происходить на машине пользователя и отображаться налету.
Отдельные долгоиграющие задачи, типа моделирования, давно считаются и распределенно, и на кластерах.
Но большинство задач, которые возникают в процессе редактирования, не предназначены для распараллеливания.
Нету подходящих распределенных алгоритмов. Максимум — используется декомпозиция, чтобы посчитать в нескольких потоках, а потом сборка обратно. Тё>И чем тут C++ может блеснуть лучше, чем жава или go?
Как там у go с гуем? Есть подходящие библиотеки? Или придется городить интероп с Шарпом/Дельфями/Плюсами?
Какие накладные расходы у явы и го при работе с маленькими объектами? Скажем 100млн объектов по 8 байт?
Мне забавляет твоя одержимость языками. Язык же выбирается под задачу, а не потому, что модно/молодёжно/от Гугла.
Потянет твоя Ява пересчитывать такое на лаптопе в реальном времени?
Под "пересчитывать" я подразумеваю не только рисование, но и обработку данных (передвинули компонент — трассы переложить, полигоны перезалить, нарушения найти/посчитать и т.д.).
Картинко
3D
2D
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
Тё>>При словах "дельфи", "шарп" уже все понятно и дальше не стоит притягивать сиплюсы. SVZ>Это естественная эволюция большого проекта.
Начнем с того, что дельфи противоестественно для графического продукта, как оно там вообще оказалось? SVZ>Объем кода такой, что даже пары лет не хватит, чтобы переписать с нуля по фэншую.
Нужно сразу писать хорошо. Тё>>Вопрос на засыпку: что мешает отправить вычисления на кластер или в GPU? SVZ>Не забывай, это не серверный софт, это софт для рабочего места. Т.е. всё должно происходить на машине пользователя и отображаться налету.
Рендеринг научились на кластере делать- чтобы обсчитывалось на лету. SVZ>Отдельные долгоиграющие задачи, типа моделирования, давно считаются и распределенно, и на кластерах. SVZ>Но большинство задач, которые возникают в процессе редактирования, не предназначены для распараллеливания. SVZ>Нету подходящих распределенных алгоритмов. Максимум — используется декомпозиция, чтобы посчитать в нескольких потоках, а потом сборка обратно.
Ога. map-reduce. Вот и вопрос- gpu rendering pipeline с появления массивно-параллелится. Тё>>И чем тут C++ может блеснуть лучше, чем жава или go? SVZ>Как там у go с гуем? Есть подходящие библиотеки? Или придется городить интероп с Шарпом/Дельфями/Плюсами?
Electron. SVZ>Какие накладные расходы у явы и го при работе с маленькими объектами? Скажем 100млн объектов по 8 байт?
Lightweight паттерн, mmap. SVZ>Мне забавляет твоя одержимость языками. Язык же выбирается под задачу, а не потому, что модно/молодёжно/от Гугла.
У сектантов язык не выбирается. SVZ>Потянет твоя Ява пересчитывать такое на лаптопе в реальном времени? SVZ>Под "пересчитывать" я подразумеваю не только рисование, но и обработку данных (передвинули компонент — трассы переложить, полигоны перезалить, нарушения найти/посчитать и т.д.).
Еще раз. GPU порвет жалкие потуги хоть на жаве считать, Хоть на плюсах. SVZ>
Здравствуйте, Тёмчик, Вы писали:
Тё>>>При словах "дельфи", "шарп" уже все понятно и дальше не стоит притягивать сиплюсы.
SVZ>>Это естественная эволюция большого проекта. Тё>Начнем с того, что дельфи противоестественно для графического продукта, как оно там вообще оказалось?
Оно там точно было в 99 году, а когда изначально появилось — вообще без понятия.
Когда всё затевалось Дельфя выдавала нативный код ничуть не хуже MSVS5. А уж работа с многочисленными формочками и панельками у неё была на порядок круче.
SVZ>>Объем кода такой, что даже пары лет не хватит, чтобы переписать с нуля по фэншую. Тё>Нужно сразу писать хорошо.
Ага, "мыши, станьте ёжиками!"
Тё>>>Вопрос на засыпку: что мешает отправить вычисления на кластер или в GPU?
SVZ>>Не забывай, это не серверный софт, это софт для рабочего места. Т.е. всё должно происходить на машине пользователя и отображаться налету. Тё>Рендеринг научились на кластере делать- чтобы обсчитывалось на лету.
Рендеринг это копейки на фоне остальных задач.
SVZ>>Как там у go с гуем? Есть подходящие библиотеки? Или придется городить интероп с Шарпом/Дельфями/Плюсами? Тё>Electron.
А чтобы не тормозило написать на wasm'е? Ну такой вариант имеет право на существование, но тогда чем он лучше связки дельфи+шарп+плюсы?
SVZ>>Какие накладные расходы у явы и го при работе с маленькими объектами? Скажем 100млн объектов по 8 байт? Тё>Lightweight паттерн,
Ты имеешь в виду Flyweight?
Такое практикуется в С++ специально для уменьшения накладных расходов.
Тё>mmap.
Улыбнул!
Т.е. ты пытаешься из managed языков состряпать что-то похожее на Си?
Здесь стоит упомянуть буханку хлеба и троллейбус.
SVZ>>Потянет твоя Ява пересчитывать такое на лаптопе в реальном времени? SVZ>>Под "пересчитывать" я подразумеваю не только рисование, но и обработку данных (передвинули компонент — трассы переложить, полигоны перезалить, нарушения найти/посчитать и т.д.).
Тё>Еще раз. GPU порвет жалкие потуги хоть на жаве считать, Хоть на плюсах.
GPU было сильно там, где надо выполнить миллионы однотипных инструкций. Тут параллелизация использовалась в полный рост.
Использование double, ветвлений и разлапистого кода просаживала производительность и сводила на нет все плюсы GPU.
Сейчас что-то изменилось? Если да, то это повод еще раз посмотреть на gpu.
Там правда есть еще дофига проблем с загрузкой/выгрузкой данных, которые не бесплатны, с малым объемом памяти, несовместимостью железа, ценой железа, отсутствием графических карт на облачных и серверных компах. В общем, стоит только копнуть и желание связываться с gpu резко пропадает.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, Тёмчик, Вы писали:
SVZ>>>В оперденях геометрия не применяется. А в наукоёмких разработках и геймдеве — сплошь и рядом и найти разработчика не проблема.
SVZ>>>Даже зная вычислительную геометрию человек потратит несколько недель на решение задачи. Тё>>Так найти разработчика это проблема или нет? Мы все еще про плюсы? Тё>>А может быть, засилие сектантов-бдсмщиков в C++ как раз причина "потратит несколько недель на решение задачи"? Ибо потратит не на решение задачи вычислительной геометрии, а на борьбу с языком C++.
SVZ>Твой ответ запоздал на три года, но тема, похоже, до сих пор актуальная.
На шарпе (если писать будут студенты или плюсовики потратившие минут 5 на изучение с#) ты так же будешь ходить по тем же самым граблям
только твоя программа на Java будет жрать ресурсов на порядок больше.
Тё>Еще раз. GPU порвет жалкие потуги хоть на жаве считать, Хоть на плюсах.
Несомненно, GPU всех порвет. Но только на том классе задач, для которых GPU создавалось. Проблема лишь в том, что таких задач не так уж и много (особенно за пределами компьютерной графики).
Здравствуйте, Denis Ivlev, Вы писали:
DI>Каким образом?
СВЕЖИЕ КОЙНЫ!!! СОЧНЫЕ, МЯГКИЕ, АРОМАТНЫЕ! БАБУШКА ТОЛЬКО ЧТО НАМАЙНИЛА! НАЛЕТАЙ! КТО УГАДАЕТ, ПОД КАКИМ НАПЕРСТКОМ NFT — ТОМУ СМАРТ-КОНТРАКТ НА 100500% ГОДОВЫХ!!!!11!1
Здравствуйте, xma, Вы писали:
NB>>а GPU на чем пишут? xma>универсально opencl (С), или "Vulkan compute shaders", или CUDA (NVidia Only, C/C++), или "DirectX — DirectCompute" ..
Здравствуйте, xma, Вы писали:
NB>>и на какой язык эти opencl, CUDA и прочие похожи? xma>я же в скобочках указал — что opencl проги пишутся на C (без C++), а CUDA — на C/C++ (там даже шаблоны вроде поддерживаются, и рекурсия)
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Когда всё затевалось Дельфя выдавала нативный код ничуть не хуже MSVS5. А уж работа с многочисленными формочками и панельками у неё была на порядок круче.
Но редактор разводки печптнвх плат- это же про формочки, про опердень, правда?
SVZ>>>Объем кода такой, что даже пары лет не хватит, чтобы переписать с нуля по фэншую. Тё>>Нужно сразу писать хорошо.
SVZ>Ага, "мыши, станьте ёжиками!"
Сразу писать нужно было на C++ или C- что было тогда актуально. Сейчас C++ не актуально, т.к. дорого в поддержке, и другие инструменты появились.
SVZ>Рендеринг это копейки на фоне остальных задач.
Ок. Но тв не ответил, чем эти остпльнве задачи пиинципиально требуют C++ — ибо что я вижу, это "ниасилили" другие языки.
Тё>>Electron.
SVZ> SVZ>А чтобы не тормозило написать на wasm'е?
Хром может в opengl.
SVZ> Ну такой вариант имеет право на существование, но тогда чем он лучше связки дельфи+шарп+плюсы?
Тем, что кросс платформа и кнопочки можно красивее нарисовать с SVG и CSS. Убожество windows only должно умереть.
SVZ>>>Какие накладные расходы у явы и го при работе с маленькими объектами? Скажем 100млн объектов по 8 байт? Тё>>Lightweight паттерн,
SVZ>Ты имеешь в виду Flyweight? SVZ>Такое практикуется в С++ специально для уменьшения накладных расходов.
Тё>>mmap.
SVZ>Улыбнул! SVZ>Т.е. ты пытаешься из managed языков состряпать что-то похожее на Си?
Еще раз, есть секта плюсников, которые считают этот язык откровением. А между тем, нет откровения. Есть алгоритмы и паттернв проектирования, доступные из более современных и удобных языков.
SVZ>Использование double, ветвлений и разлапистого кода просаживала производительность и сводила на нет все плюсы GPU.
Использование double, ветвлений и разлапистого кода просаживала производительность и сводила на нет все плюсы C++.
SVZ> стоит только копнуть и желание связываться с gpu резко пропадает.
Т.е. ниасилили.
Здравствуйте, xma, Вы писали:
xma>в чём ? (тут 16 страниц так то, не перечитывать же всё)
Сразу забей по причине полной бесперспективности сего бисерноразбрасывательного занятия
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, Sharov, Вы писали:
SVZ>>>Да-да, по-быстрому разобраться в предметной области, которую 5 лет в институте изучают.
S>>Вот да, проще геодезистам выучить какой-нибудь ЯП.
SVZ>Вот именно так и происходит. SVZ>В нашей отрасли есть ооочень большая компания, дык её московский отдел, который отвечает за разработку автотрассировщика, Signal/Power Integrity, практически полностью состоит из физиков, которые худо-бедно освоили "Си с классами".
SVZ>Код — без слёз не взглянешь, зато у компании миллиардные годовые обороты.
Насколько качество кода влияет на результат тут? Возникают ли от этого, например, трудноуловимые баги?
Является ли нормальной политикой, что их код регулярно шлифует спец по языку? (хотя бы до уровня нормального 11-го?)
Здравствуйте, kaa.python, Вы писали:
KP>Вакансий на Go прибавляется довольно быстро, и это правильно, на нем и мартышку можно научить нормально писать, что хорошо. Так что достичь уровня Гуру не сложно, что огромный плюс. Но тут есть и минусы – так как войти просто, ты будешь конкурировать с мартышками, не сказаться негативно на ЗП это не может.
Какие знания позволят "не конкурировать с мартышками" (оставаясь в го)? Например знания фуллстака (кубер, постгрес, тайпскрипт, реакт)?
(тут 16 страниц так то, не перечитывать же всё)
