Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Нomunculus, Вы писали:
Н>>У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Pzz>Это не потому, что в нас с детства заложена ассоциация между немцами и фашистами?
Разумеется поэтому. Я ж просто свои ощущения описал
Здравствуйте, Нomunculus, Вы писали:
Н>У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Pzz>Это не потому, что в нас с детства заложена ассоциация между немцами и фашистами?
Джером К. Джером в трое в лодке писал даже) цитата совершенно не точная — по памяти. гуглить лень.
там эпизод был на каком-то приеме. исполнял кто-то песню на немецком. их разыграли, мол вы не знаете немецкого, но на самом деле это очень смешная песня и для этикета надо ржать. что они и делали. певец негодовал. на самом деле это была какая-то грустная драматическая песня, полная скорби.
в конце он ополчился на ржущих и выдал тираду ругани в их адрес на немецком. "мне кажется немецкий язык специально предназначен для ругательств!"
Pzz>А много HTTP и много TLS — не редкость для определенного класса системных задач.
блин. хттп и тлс это все же не уровень драйверов и высокопроизводительного графического движка.
тут и шарп и ява бы справились вполне
Pzz>>А много HTTP и много TLS — не редкость для определенного класса системных задач. U>блин. хттп и тлс это все же не уровень драйверов и высокопроизводительного графического движка. U>тут и шарп и ява бы справились вполне
Тут речь не только про HTTP — про любой IO. Если тебе надо делать множество чтений или записей (откуда угодно и куда угодно) с небольшой обработкой прочитанного, то гошка будет хорошим выбором.
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>Тут речь не только про HTTP — про любой IO. Если тебе надо делать множество чтений или записей (откуда угодно и куда угодно) с небольшой обработкой прочитанного, то гошка будет хорошим выбором.
вопрос конечно холивора и закостенелости. но повод ли для этого изучать что-то, если инструмент прекрасно справляется с задачей?
п.с. всегда бесили вот названия и картинки типа dbeaver. бобер. сразу ларри вспоминаются с пасхалками. а конкретно в русификации надо было написать "подоить бобра" = "подрочить" ) короче по возможности только хардкор — mssms и pgadmin для постгря...
Ф>>Тут речь не только про HTTP — про любой IO. Если тебе надо делать множество чтений или записей (откуда угодно и куда угодно) с небольшой обработкой прочитанного, то гошка будет хорошим выбором.
U>вопрос конечно холивора и закостенелости. но повод ли для этого изучать что-то, если инструмент прекрасно справляется с задачей?
Если ты про шарп, то он с такими задачами справляется хуже: конкурентность в шарпе явная (я про async/await), а в гошке она из коробки — у тебя простой линейный стиль написания. Заметь, программист, который понимает как работают async/await — редкий зверь. Но это было бы половина беды: для IO-bound приложений тебе придётся что-то явно городить с размером стека — твои потоки сожрут всю доступную память под свои стеки и проблема встанет в полный рост.
Попытка уложить число потоков в кол-во ядер ОС на шарпе — задача в общем случае не решаемая, а значит твоя программа будет жрать System Time на переключение контекстов.
ЗЫ: гаечный ключ всё же нужен для закручивания, для забивания молоток лучше подходит
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Если ты про шарп, то он с такими задачами справляется хуже: конкурентность в шарпе явная (я про async/await), а в гошке она из коробки — у тебя простой линейный стиль написания.
Как и в хаскеле. Все стандартное IO там асинхронное из коробки, и потоки там по умолчанию зеленые (прибитые к системным тоже есть). И нативный код создается со встроенным сборщиком мусором. Вообще, голанг местами очень и очень сильно смахивает на хаскель, кроме следующего пункта, очень важного:
"Заметь, программист, который понимает как работают async/awaitписать на хаскеле — редкий зверь."
Прощу прощения за почти дословное использование твоей фразы.
Здравствуйте, undo75, Вы писали:
Pzz>>А много HTTP и много TLS — не редкость для определенного класса системных задач. U>блин. хттп и тлс это все же не уровень драйверов и высокопроизводительного графического движка. U>тут и шарп и ява бы справились вполне
Современные принтеры, сканеры разговаривают по HTTP/HTTPS.
Докеры всякие умеют грузить всякие запчасти по HTTP/HTTPS.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
DSP алгоритмы вообще пишутся на Си, особенно в области embedded
Ф>Если ты про шарп, то он с такими задачами справляется хуже: конкурентность в шарпе явная (я про async/await), а в гошке она из коробки — у тебя простой линейный стиль написания. Заметь, программист, который понимает как работают async/await — редкий зверь. Но это было бы половина беды: для IO-bound приложений тебе придётся что-то явно городить с размером стека — твои потоки сожрут всю доступную память под свои стеки и проблема встанет в полный рост. Ф>Попытка уложить число потоков в кол-во ядер ОС на шарпе — задача в общем случае не решаемая, а значит твоя программа будет жрать System Time на переключение контекстов.
а можно пример задач таких? фантазии что-то не хватает
M>>Они замечательно пишутся и на плюсах, и получается гораздо лучше. Ну, если, конечно, под железку есть плюсовый компилятор
U>всегда думал что под ембеддед на асме пишут. нафиг на высокоуровневом языке. даже с?
Как сейчас помню, 98-й год, Visual Studio 5.0. Нам понадобилось реализовать вычисление квадратного корня для чисел с фиксированной точкой. Табличное решение с интерполяцией. Я сразу же взялся за ассемблер, а вариант писать на C я даже не рассматривал. После того как реализовал и всё это успешно взетело, мне мой тогдашний руководитель предложил реализовать то же самое на Сях, благо это было не сложно. Когда же я сделал это и посмотрел в сгенерированный код, я прозрел. И навсегда потерял желание состязаться с компилером в оптимизациях. Компилер меня уделал и по памяти, и по производительности.
--
Справедливость выше закона. А человечность выше справедливости.
R>Как сейчас помню, 98-й год, Visual Studio 5.0. Нам понадобилось реализовать вычисление квадратного корня для чисел с фиксированной точкой. Табличное решение с интерполяцией. Я сразу же взялся за ассемблер, а вариант писать на C я даже не рассматривал. После того как реализовал и всё это успешно взетело, мне мой тогдашний руководитель предложил реализовать то же самое на Сях, благо это было не сложно. Когда же я сделал это и посмотрел в сгенерированный код, я прозрел. И навсегда потерял желание состязаться с компилером в оптимизациях. Компилер меня уделал и по памяти, и по производительности.
понятно, что сейчас на асме писать смысла нет. в каноны уже даже вошло "писать функцию извлечения квадратного корня" синоним "изобретать велосипед". а например алгоритм поиска кратчайшего пути — уже под вопросом что лучше будет в итоге
Здравствуйте, undo75, Вы писали:
U>а например алгоритм поиска кратчайшего пути — уже под вопросом что лучше будет в итоге
Ну, для меня это вообще не вопрос. В определенный период я написал такое количество версий поиска пути, что даже не смогу припомнить все варианты. Взвешенные, невзвешенные, с квадратной волной, с круглой волной, с одним источником, с двумя и с множеством, с различным числом и схемами распространения волны, с Бразенхамом, без него, с собственными примочками сглаживания... И всё это ещё и в различных комбинациях. При этом я постоянно мониторил сгенерированный код. В те поры я вообще был зациклен на производительности. Времена были такие. Визуализация FPS в реалтайме была неотъемлемым атрибутом разработки. Могу сказать с полной уверенностью, что, если бы я писал это на асме, то просто угробил бы кучу времени, но результат лучше не был бы. А вот хуже — легко.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, undo75, Вы писали:
M>>Они замечательно пишутся и на плюсах, и получается гораздо лучше. Ну, если, конечно, под железку есть плюсовый компилятор
U>всегда думал что под ембеддед на асме пишут. нафиг на высокоуровневом языке. даже с?
Нафиг писать годами на асме то, что можно написать за недели на плюсах, и ещё и спортировать или даже просто взять код с больших систем?
U>а можно пример задач таких? фантазии что-то не хватает
Например бэкап — оч. характерный пример IO-bound задачи с высокой степенью параллелилизма. Когда-то я таким занимался.
Ещё примеры:
Поиск по дискам — просто множество IO-операций.
Инсталляция, апдейт, например — пакетные менеджеры очень много контрольных сумм считают, вычисления минимальны.
Системы мониторинга, например — сбор метрик с множества источников, агрегация данных телеметрии, парсинг и индексация логов, поиск по логам
Работа с периферийными устройствами, например — обработка данных с датчиков
Облака, например — синхронизация данных между локальным диском и облачным хранилищем
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rg45, Вы писали:
R>Как сейчас помню, 98-й год, Visual Studio 5.0. Нам понадобилось реализовать вычисление квадратного корня для чисел с фиксированной точкой.
Фиксированную точку вроде через BCD реализуют (реализовывали). Это вроде бы наиболее корректный и производительный путь.
ЕМНИП, Си не умеет в BCD и никогда не умела. Даже некоторые битовые операции — только асм.
Я вообще не знаю ни одного языка общего назначения, который бы BCD знал и юзал. Неофиты даже не знают, что такое существует.
Поправь, если ошибаюсь.
Всё сказанное выше — личное мнение, если не указано обратное.
