Здравствуйте, Nuzhny, Вы писали:
Pzz>>А system-config-printer?
N>Не знаю, что это такое, но по названию явно оно. Там тоже много математики, которую можно и нужно переносить на GPU?
Это — стандартная прогдамма настройки принтеров для Linux.
Pzz>>А много ли написано ядер операционных систем, которыми люди пользуются?
N>Явно не много. И они написаны не только на С. Значит ли это, что С не нужен?
Тезис, который я оспариваю, заключается в незаменимости C++ для системного программирования.
system-config-printer так ваще на питоне написан.
Но конечно, если что-то уже написано на C++, то оно так и будет по наследству тянуться до бесконечности.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
С какой-то точки зрения все языки "заменяют С++".
Ну, просто потому, что на C++ можно написать вообще всё.
Значит, всякий раз, когда кто-то выбирает для проекта X язык Y, он (осознанно или неосознанно) делает выбор между Y и С++. Не в пользу С++.
И либо этот выбор оказывается ошибкой (ой, мы так и не смогли написать прошивку для bluetooh-метки автосигнализации на питоне), либо приводит к успеху проекта.
Если проекты в какой-то нише при реализации на Y оказываются успешными достаточно часто, значит можно говорить о том, что Y заменяет C++ в этой нише.
Вот в нише "RESTful web-services" С++ заменяется на примерно любой язык, от Перла и Лиспа до JavaScript.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Тезис, который я оспариваю, заключается в незаменимости C++ для системного программирования.
Я этот тезис и не выдвигал, кстати. Исходный посыл:
Из очевидного — браузеры?
ТАкже библиотеки со всякой математикой, параллельные вычисления, СУБД, сетевые приложения с видеокодеками и всякой обработкой. Короче, там где надо писать производительный код одновременно на разных уровнях абстракции: и ближе к железу, и оптимизации, и логику.
Если какое-то ПО является системным, но его пофиг на каком языке и писать, то пусть и пишут.
Переход на системное ПО был в свете: Pzz>Видеокодеки, опять же, их мало кто пишет, остальные в основном используют
Мы же не говорим о том, что много пишут, а что мало. Понятно, что чем дороже разработка, тем меньше народа такое пишет. И что ниша С++ сжимается. Но тут также как с браузерами — пока никто и не пытается, хотя и возможности, и шанс у той же Майкрософт были. Ну и что, что кодеков пишут мало? Их же пишут. Вот, нейросети 99% пишут на Питоне на PyTorch, но ядро его libTorch написано на С++. Ну и что, что на С++ мало — пишут же, тут Питон его заменить не может, Go тоже, Rust не пытается. И таких системных библиотек, новых и свежих, довольно много. Могу ссылок накидать, если хочешь.
Здравствуйте, Nuzhny, Вы писали:
N>Мы же не говорим о том, что много пишут, а что мало. Понятно, что чем дороже разработка, тем меньше народа такое пишет. И что ниша С++ сжимается. Но тут также как с браузерами — пока никто и не пытается, хотя и возможности, и шанс у той же Майкрософт были. Ну и что, что кодеков пишут мало? Их же пишут. Вот, нейросети 99% пишут на Питоне на PyTorch, но ядро его libTorch написано на С++. Ну и что, что на С++ мало — пишут же, тут Питон его заменить не может, Go тоже, Rust не пытается. И таких системных библиотек, новых и свежих, довольно много. Могу ссылок накидать, если хочешь.
Я тут выяснил случайно, что задача:
1. Прочитать PNG-файл размером 5100x7016, цветной, 8-битный
2. Смасштабировать в два раза в любую сторону методом билинейной интерполяции
2. Записать в виде PNG-файла
требует примерно одинакового времени CPU, как в реализации на чистом Go, так и в реализации с помощью ImageMagic (на чём он там написан? C или C++, не помню точно).
Так что я не вижу таких уж особых проблем в написании кодеков на Go.
Здравствуйте, Pzz, Вы писали:
Pzz>требует примерно одинакового времени CPU, как в реализации на чистом Go, так и в реализации с помощью ImageMagic (на чём он там написан? C или C++, не помню точно).
О, на Go уже свои libpng есть? Круто
Pzz>Так что я не вижу таких уж особых проблем в написании кодеков на Go. Не скинешь ссылку? Интересно
Здравствуйте, Nuzhny, Вы писали:
Pzz>>требует примерно одинакового времени CPU, как в реализации на чистом Go, так и в реализации с помощью ImageMagic (на чём он там написан? C или C++, не помню точно).
N>О, на Go уже свои libpng есть? Круто
Здравствуйте, Pzz, Вы писали:
N>>О, на Go уже свои libpng есть? Круто Pzz>Даже прям в стандартной библиотеке.
Пишут, что в быстродействии очень много зависит от zlib. Видимо, много библиотек уже используют многопоточные версии всех стандартных библиотек, в отличие от классических на С, поэтому так хорошо и выступают. Но круто, да.
Видеокодеки для видео сильно сложнее, их разрабатывают отдельные команды конкретно под устройство обычно (наряду с ванильными версиями, да). Не уверен, что у Го получится так просто ворваться.
Здравствуйте, Nuzhny, Вы писали:
N>>>О, на Go уже свои libpng есть? Круто Pzz>>Даже прям в стандартной библиотеке.
N>Пишут, что в быстродействии очень много зависит от zlib. Видимо, много библиотек уже используют многопоточные версии всех стандартных библиотек, в отличие от классических на С, поэтому так хорошо и выступают. Но круто, да.
Не, он однопоточный, насколько я понимаю.
N>Видеокодеки для видео сильно сложнее, их разрабатывают отдельные команды конкретно под устройство обычно (наряду с ванильными версиями, да). Не уверен, что у Го получится так просто ворваться.
Здравствуйте, Pzz, Вы писали:
Pzz>Я тут выяснил случайно, что задача... Pzz>Так что я не вижу таких уж особых проблем в написании кодеков на Go.
Гошка плохо подходит для задач нагруженных вычислениями — её для другого делали: гошка — превосходный инструмент для задач, сильно нагруженных I/O операциями.
В гошке управление планировщиком скрыто от программиста — нет возможности "привязать" горутину к конкретному ядру. Это мешает оптимизации кэширования: непредсказуемость попадания горутин на потоки OS приводит к "cache coherence overhead". Тащемта это одна из основных причин, по которым в игровых двужках прибивают отдельные потоки к ядрам с помощью CPU affinity mask.
Вторая причина — в гошке нет штатных способов контроля за расположением полей в памяти — это чрезвычайно важно, например для того, чтобы избежать false-sharing. Из-за этого там используют вот такие уродские решения:
type PaddedShared struct {
A int64
_ [56]byte // Заполнение до размера кэш-линии (64 байта)
B int64
}
Третья — поддержка SIMD ограничена: пакет simd появился и существует именно потому, что мы до сих пор не можем положиться на автовекторизацию — вынуждены распространённые операции над массивами векторизовать руками. По крайней мере в марте в документации об этом было написано прямо.
Не надо писать на гошке вычислительные задачи!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Pzz>>Я тут выяснил случайно, что задача... Pzz>>Так что я не вижу таких уж особых проблем в написании кодеков на Go.
Ф>Гошка плохо подходит для задач нагруженных вычислениями — её для другого делали: гошка — превосходный инструмент для задач, сильно нагруженных I/O операциями.
В принципе, да. В корпусе — не такая уж она и медленная, как выясняется.
Ф>В гошке управление планировщиком скрыто от программиста — нет возможности "привязать" горутину к конкретному ядру. Это мешает оптимизации кэширования: непредсказуемость попадания горутин на потоки OS приводит к "cache coherence overhead". Тащемта это одна из основных причин, по которым в игровых двужках прибивают отдельные потоки к ядрам с помощью CPU affinity mask.
runtime.LockOSThread — привязывает гороутинку к нити операционной системы.
Ну а дальше можно системно-зависимыми способоами приделять нить к ядру.
Ф>Вторая причина — в гошке нет штатных способов контроля за расположением полей в памяти — это чрезвычайно важно, например для того, чтобы избежать false-sharing. Из-за этого там используют вот такие уродские решения:
Ну, примерно как и в Си
Недавно появились маркеры раскладки структур. Пока только struct.HostLayout
Ф> Третья — поддержка SIMD ограничена: пакет simd появился и существует именно потому, что мы до сих пор не можем положиться на автовекторизацию — вынуждены распространённые операции над массивами векторизовать руками. По крайней мере в марте в документации об этом было написано прямо.
Здравствуйте, Pzz, Вы писали:
Pzz>runtime.LockOSThread — привязывает гороутинку к нити операционной системы. Pzz>Ну а дальше можно системно-зависимыми способоами приделять нить к ядру.
не знал! Спасибо.
Погуглил про этот вызов — похоже на поход по минному полю: https://github.com/golang/go/issues/21827
Сейчас на скорую руку попробовал оригинальный код из гугловой группы — использование этого вызова похоже на хождение по минному полю, оно и понятно: он в общем-то не для этого делался.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф> Третья — поддержка SIMD ограничена: пакет simd появился и существует именно потому, что мы до сих пор не можем положиться на автовекторизацию — вынуждены распространённые операции над массивами векторизовать руками. По крайней мере в марте в документации об этом было написано прямо.
А в каком ЯП (ну кроме ассемблера) можно _полагаться_ на автовекторизацию?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А в каком ЯП (ну кроме ассемблера) можно _полагаться_ на автовекторизацию?
А что не так с C/C++? Говорят, -O3 чудеса творит, особенно с укзанием целевой архитектуры. Говорят, что GCC может автоматически векторизировать циклы
Говорят, что LLVM — один из самых продвинутых компиляторов с т.з. оптимизаций и векторизации.
Я не плюсовик, если что.
Насчёт ассемблера ты круто пошутил конечно Где автоXXXX и где ассемблер...
Мои эксперименты с плюсами регулярно упирались в то, чтобы как-нибудь сделать так, чтобы компилятор не выкинул мой код и время выполнения не было равно нулю. Сломать это поведение было не так то и просто.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Pzz>>runtime.LockOSThread — привязывает гороутинку к нити операционной системы. Pzz>>Ну а дальше можно системно-зависимыми способоами приделять нить к ядру.
Ф>не знал! Спасибо. Ф>Погуглил про этот вызов — похоже на поход по минному полю: https://github.com/golang/go/issues/21827
Не очень понятно с первого прочтения, чего у них там происходит. Может и правда хождение по минному полю, а может у граждан руки-крюки.
Я использовал этот вызов, когда надо было кое-какой гошный код на венду перенести. У венды встречается API, в котором надо сделать серию вызовов, и все должны быть на контексте одного и того же потока операционной системы. Иначе венде плохеет.
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
языки лишь инструменты. не знаю го, но уверен, что какой-нить квейк написать на с++ куда проще чем на бейсике через поук.
сильно сомневаюсь, что на го системные задачи проще решать, чем на с++.
а так — немецкий значительно лучше для ругани, например подходит, чем французский. и т.д. и т.п.
Здравствуйте, undo75, Вы писали:
U>языки лишь инструменты. не знаю го, но уверен...
Сильно советую с ним познакомиться — ты его ещё не раз увидишь, это годный инструмент. Ну а так — да, молотком гвозди забивать удобнее чем гаечным ключом.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, undo75, Вы писали:
U>а так — немецкий значительно лучше для ругани, например подходит, чем французский. и т.д. и т.п.
У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Здравствуйте, undo75, Вы писали:
U>сильно сомневаюсь, что на го системные задачи проще решать, чем на с++.
Смотря какие задачи.
Например, если задача включает в себя много HTTP и много работы с TLS-сертификатами, то ее значительно проще делать на Go. Благодаря первоклассной поддержке того и другого в стандартной библиотеке.
А много HTTP и много TLS — не редкость для определенного класса системных задач.
Здравствуйте, Нomunculus, Вы писали:
Н>У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Это не потому, что в нас с детства заложена ассоциация между немцами и фашистами?
