The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз языка программирования Go 1.17, opennews (??), 17-Авг-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


175. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 03:57 
> Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз

А я попробовал попарсить гигабайтный xml файлик с помощью Го и как-то подразочаровался. Свой парсер у него говённый, но даде с биндингами к либхмл он нещадно тормозит из за постоянного перераспределения памяти под строки.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

184. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 10:10 
>> Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз
> А я попробовал попарсить гигабайтный xml файлик с помощью Го и как-то
> подразочаровался. Свой парсер у него говённый, но даде с биндингами к
> либхмл он нещадно тормозит из за постоянного перераспределения памяти под строки.

Наверное, потому что ты как-то не так готовил кошек? Прямо сразу из твоего сообщения я вижу, что как минимум, вместо того, чтобы использовать strings.Builder() ты использовал строки (которые в го -- неизменяемые сущности, поэтому таки да -- использовать строки налево и направо - -в го весьма дорого). Типичное решение в го в таких случаях -- использовать срез рун. А уж как ты там парсил и почему ты не посмотрел решения на github.com с кодогенерацией, которая даёт ускорение под конкретный XML в 5-10 раз -- вот тут мне понятно, что навыки программирования у тебя на уровне джуниора.


Ты использовал биндинги? А ты хоть немного интересовался, какие ограничения накладываются на использование сишных биндингов в Го? По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию. Использовать колёса разных размеров и иногда немного квадратные в одном автомобиле -- это не айс. Подучил бы ты сначала го-вей, а потом садился писать высоконагруженные штуки.

Ответить | Правка | Наверх | Cообщить модератору

187. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 10:43 
Я на чтение пробовал, а не на запись. Мне нужен был SAX парсер - гигабайтный файл был маленьким семплом.  Нахера там стрингбилдер? Строки, полученные из ХМЛ - зачем их менять? Просто Го делает обычные энтерпрайзные вещи крайне медленно. Не так медленно как перл или, наверное, петон, но медленнее опасных языков в разы.
Ответить | Правка | Наверх | Cообщить модератору

188. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 10:50 
> Я на чтение пробовал, а не на запись. Мне нужен был SAX
> парсер - гигабайтный файл был маленьким семплом.  Нахера там стрингбилдер?
> Строки, полученные из ХМЛ - зачем их менять? Просто Го делает
> обычные энтерпрайзные вещи крайне медленно. Не так медленно как перл или,
> наверное, петон, но медленнее опасных языков в разы.

Даже если ты просто читаешь -- ты выделяешь память. Если ты просто заполняешь поля структур строками -- ты выделяешь память. Так вот, если бы ты использовал срезы рун -- ты бы память выделял -- ровно один раз. А strings.Builder() -- довольно не дурно сам понимает -- сколько ему памяти удерживать, а сколько отдать назад сборщику мусора (т.е. нет лишнего выделения памяти). Кроме того, эта штука умеет очень быстро почти без накладных расходов преобразовывать свой буфер в байты/руны/строки. Так что, инструмент надо не только уметь держать, но ещё и пользоваться им. Так что ты бы попробовал кодогенерацию. Безопасно, достаточно быстро для безопасного парсинга, ещё и код писать не надо руками -- только описать структуры в шаблоне.

Ответить | Правка | Наверх | Cообщить модератору

191. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 11:13 
Ты не понимаешь как работает SAX - библиотека дергает твои колбеки и передаёт им полученные значения. Всё. Сам ты там ничего не выделяешь. И к библиотекам нет вопросов, я попробовал их все, что были на тот момент за исключением родной гошной укуренной. На Го быстрее просто невозможно - копируешь строку как минимум один раз, что из го-кода, что при передаче из опасной libxml. Там и тормозить-то больше нечему.
Ответить | Правка | Наверх | Cообщить модератору

192. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 12:00 
> Ты не понимаешь как работает SAX - библиотека дергает твои колбеки и
> передаёт им полученные значения. Всё. Сам ты там ничего не выделяешь.

Я прекрасно понимаю, как работает эта либа. Она дёргает колбеки. А это значит, что вся конкурентность го идёт псу под хвост. Если у тебя даже 128 ядер будет -- фактически работать у тебя за счёт сишной либы всегда будет только одно ядро.

> И к библиотекам нет вопросов, я попробовал их все, что были
> на тот момент за исключением родной гошной укуренной. На Го быстрее
> просто невозможно - копируешь строку как минимум один раз, что из
> го-кода, что при передаче из опасной libxml.

Таким образом ты ещё и убиваешь инварианты памяти. Кодогенерация, ещё раз -- волшебное слово.
На го можно достаточно быстро, чтобы сравнивать с чистым си (не на порядок будет отставание, а в типовом случае в 2х..4х раза -- это плата за безопасность, но стоит она дороже, чем 2х...4х).
Родная гошная библиотека просто даёт возможность что-то сделать. Фактически, существует по 3-5 реализаций каждой гошной библиотеки с оптимизациями 5х..20х раз. Что JSON, что XML, что HTTP.

> Там и тормозить-то больше
> нечему.

А так-то да. Всё что мог затормозить -- ты успешно затормозил))


Ответить | Правка | Наверх | Cообщить модератору

195. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 15:04 
> Я прекрасно понимаю, как работает эта либа. Она дёргает колбеки. А это
> значит, что вся конкурентность го идёт псу под хвост. Если у
> тебя даже 128 ядер будет -- фактически работать у тебя за
> счёт сишной либы всегда будет только одно ядро.

Зачем там 128 ядер!? Эта задача вообще в IO должна упираться, а не в ЦПУ :-D


> Таким образом ты ещё и убиваешь инварианты памяти. Кодогенерация, ещё раз --
> волшебное слово.

Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не сможет.

> А так-то да. Всё что мог затормозить -- ты успешно затормозил))

Ну разве что тебя, да и то не хотел, прости ;-D

Ответить | Правка | Наверх | Cообщить модератору

213. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 23:34 
> Зачем там 128 ядер!? Эта задача вообще в IO должна упираться, а
> не в ЦПУ :-D

Задачу парсинга XML вполне можно параллелить.

> Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не
> сможет.

Зато параллельно парсить сможет.

Ответить | Правка | Наверх | Cообщить модератору

215. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 01:42 
> Задачу парсинга XML вполне можно параллелить.

Задачу парсинга параллелить не нужно. IO тормознее всех остальных операций.Параллелить лучше то, что происходит уже после парсинга. Собственно с этой целью я на Го и смотрел. Но горутины когда начинешь их обмазывать каналами и прочей мутотой начинают захламлять код не хуже многопоточных реализаций на каких-нибудь опасных языках. И ещё куча всяких мелочей делающих бессмыссленным переход на Го. Но тормоза при работе с данными - это первая причина. БОльшая часть того, с чем работает энтерарайз - это не какие-то космические вычисления, это просто парсинг потоков данных вагинирующих от одного сервиса к другому с какми-то элементарными операциями над ними. А Го в это не может. И тут ещё такой момент - теоретический предел  производительности при парсинге XML, безразлично каким количеством потоков, это биндинг опасной libxml2. Есть поделки и намсамом Го со сравнимой производительностью, но они сильно срезают углы ради этого: ничего не знают про кодировки, например. И меня бы это устроило в том конкретном случае потому, что данный тип файлов у меня в ASCII и го вообще хоть регэкспами чеши. Но кто гарантирует что так будет всегда? А случись пояаиться кодировкам в даанных и эти поделки придется заменять на те, что будут перекодировать данные внося очередной раунд аллокации-копирования-удаления строк. Нет никакого смысла закладываться на такой ущербный инструмент. Тем более, что если мы пишем приложение на опасном языке, и наши данные не требуют особой магии, то появляется возможность маневра в сторону реализаций вообще без аллокации памяти: просто отображаем фай в память и используем строки прямо из этой памяти - такие парсеры прямо в мапе разбрасывают нули в конце строк и передают адрес строки пользователю. Быстро, дёшево и сердито. Но в Го такое випринципе невозможно.  

>> Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не
>> сможет.
> Зато параллельно парсить сможет.

И что нам это даёт? Неконкурентоспособное решение, которому нужно несколько ядер там, где и одного-то за глаза?


Ответить | Правка | Наверх | Cообщить модератору

207. "Релиз языка программирования Go 1.17"  –2 +/
Сообщение от Аноним (209), 18-Авг-21, 20:59 
> Ты не понимаешь как работает SAX - библиотека дергает твои колбеки...

Этот чел вообще мало что понимает. Полный п-ц, на самом деле.

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

216. "Релиз языка программирования Go 1.17"  +/
Сообщение от edo (ok), 19-Авг-21, 01:46 
> По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию.

Постоянно вижу сишный sqlite в программах на go

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

219. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от x3who (?), 19-Авг-21, 02:50 
>> По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию.
> Постоянно вижу сишный sqlite в программах на go

Я вообще не понимяу какая там разница. Ну вот допустим кто-то перепишет sqlite на Го.Что изменится? на каком-то этапе Го всё равно придётся взаимодействовать с опасным внешним миром, написанном на сях. Только это будут сырыа данные из файла, не отфильтрованные опасной библиотекой sqlite, т.е. копирований опасного контента в безопасный будет только больше, производительность будет хуже.. Так чем же это лучше??

Ответить | Правка | Наверх | Cообщить модератору

212. "Релиз языка программирования Go 1.17"  +/
Сообщение от anonymous (??), 18-Авг-21, 23:18 
А не могли бы вы поделиться кодом и sample-ом (который парсите)? Может быть я могу помочь вам с оптимизацией :)
Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

217. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 02:10 
> А не могли бы вы поделиться кодом и sample-ом (который парсите)? Может
> быть я могу помочь вам с оптимизацией :)

Нет. Ни тем ни другим. Там в тесте банально было - никакой осмысленной логики: парсер нашел тег, создаём соответствующего типа объект (просто заглушки со списком детей, на такой случай дженериков тоже языку не хватает кстати), говорим паренту, что у него родился сын - и всё. По возвращении на верхний уровень, скидываем объект верхнего уровня в канал на обработку и всё начинается сначала. Иерархии там не очень большие, каждый такой тег верхнего уровня килобайт примерно сто наверное, хотя бывают всплески и до пары сотен МБ. Но это не важно с т.з. парсинга - что что миллионов раз по сто тысяч байт байт переварить, что сто тыщ раз по сто миллионов байт - без разницы просто.

Короче, оптимизировать там банально нечего. Просто в силу особенностей языка он гарантирует издержки при работе с данными, by design.

Я не хочу показаться хейтером Го. Есть куча ПО, написанного на Го, которое наглядно демонстрирует преимущества этого средства на петоном и прочей "безоппасной" лабудой. Приложения, написанные на Го как правило значительно шустрее и надежнее написанных на этих странных ЯП. Я просто не понимаю зачем на н1м писать :)

Ответить | Правка | Наверх | Cообщить модератору

225. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от anonymous (??), 19-Авг-21, 11:15 
Вы код и sample дайте. Я просто уже давненько применяю Go в high performance, и частенько вижу жалобы (вроде вашей), но в >95% люди просто не правильно использовали Go для своей задачи. И каждый раз твёрдо верят, что такого не может быть.
Ответить | Правка | Наверх | Cообщить модератору

233. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 19:50 
Увы, не выйдет. Это было более полутора лет назад - я уже повыкидывал и Го и хелловорлды свои, да и синтаксис самого Го успел забыть.
Ответить | Правка | Наверх | Cообщить модератору

244. "Релиз языка программирования Go 1.17"  +/
Сообщение от anonymous (??), 20-Авг-21, 09:55 
Ну что тогда сказать? В общем, на самом деле Go нормально подходит для почти любой высокопроизводительной задачи (хотя это нередко приводит к заменителям стандартных package-ей). Реальная проблема там с safety, а не performance. И вызвана она, например, отсутствием immutable переменных (там нет ДАЖЕ аналога Сишного const) и вообще невыразительной системой типов.
Ответить | Правка | Наверх | Cообщить модератору

245. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 20-Авг-21, 11:23 
Так я об этом и говорю, что по всей видимости потери идут при переходе данных из опасного внешнего мира в безопасные потроха гошной программы, на парсинге ХМЛ это очень заметно, потому что очень много строк приходит. Константных, одинаковых. Не знаю, возможно что-то с этим можно что-то сделать на уровне биндинга к libxml2 - например не конвертировать строку, содержащую имя тега каждый раз как его надо отдавать в Го-программу, а держать таблицу гошных строк и на них ссылаться если такая строка уже есть.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру