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

"Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
Сообщение от opennews (ok), 13-Апр-20, 16:16
Опубликован отчёт о развитии проекта FreeBSD с января по март 2020 года. Из изменений можно отметить:... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52727
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от dvz (??), 13-Апр-20, 16:31	+49 +/–
Прекрасно. Фряшка развивается, что не может не радовать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #76

4. Сообщение от Аноним (4), 13-Апр-20, 16:42	+1 +/–
из всего списка меня больше всего волнует if_bridge
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #129

5. Сообщение от Аноним (86), 13-Апр-20, 16:45	–4 +/–
Подскажите, почему llvm всегда генерирует дефективный код даже на amd64? Ведь сколько лет его разрабатывают, почти что сколько и gcc… Что не логично, так это то, что его и в вулкан пихать пытаются. Я хочу логичное объяснение, почему популярный у проприерасов и всяческих противников свободы компиялтор такое убожество.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #8, #11, #21, #126

6. Сообщение от Аноним (6), 13-Апр-20, 16:51	+3 +/–
Пруфы? Без них просто наброс фанатика GPL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9

7. Сообщение от Аноним (7), 13-Апр-20, 16:55	–20 +/–
Судя по характеру обновлений она скорее деградирует. Следующая на свалку после Solaris.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10

8. Сообщение от Аноним (7), 13-Апр-20, 16:56	+2 +/–
Не дефектный, а с фичами. Используя инструмент проприерасов думай как проприерас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

9. Сообщение от Аноним (86), 13-Апр-20, 17:00	–6 +/–
Не, не, поймите правильно, я не говорю что гцц идеален. У него просто астрономическое количество регрессий и багов выплывает (регулярно), а производительность что-то там на 30% ниже проприетарного интеловского компилятора (который ммм адок ещё тот, насколько мне известно, да и вопросы совместимости есть). Но для свободного продукта это нормально, он хотя бы стабильно лучше "стандарта" msvc. А тут продукт любимый всяческими корпорациями, а код стабильно дерьмовый продуцирует. Под стабильно я понимаю стабильно. Это регулярно обсуждается. Если хочется хомячковый аргумент, то для среднего по больнице можно на мандриву посмотреть, она в любом попугаеметре будет проигрывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #12, #13, #31

10. Сообщение от анонн (ok), 13-Апр-20, 17:05	+24 +/–
> Судя по характеру обновлений она скорее деградирует. Следующая на свалку после Solaris. Что, не обновили в очередной раз CoC? Не решили единым порывом вычистить сорцы от факов и заменить списки рассылок модно-молодежным смузи с тоннами JS, бесконечным скроллингом и прочими "плюшками"? Ну точно деградируют!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

11. Сообщение от анонн (ok), 13-Апр-20, 17:06	–4 +/–
> Подскажите, почему llvm всегда генерирует дефективный код даже на amd64? Ведь сколько > лет его разрабатывают, почти что сколько и gcc… Что не логично, > так это то, что его и в вулкан пихать пытаются. Я > хочу логичное объяснение, почему популярный у проприерасов и всяческих противников свободы компиялтор такое убожество. Может потому что аналога LLVM в GCC - немаэ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

12. Сообщение от Аноним (6), 13-Апр-20, 17:10	+10 +/–
Столько текста и всё зря. Если нет внятного аргумента, а лишь невнятные отсылки, не стоило обсирать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #14

13. Сообщение от анонн (ok), 13-Апр-20, 17:14	–1 +/–
>  А тут продукт любимый всяческими корпорациями, а код стабильно дерьмовый > продуцирует. Под стабильно я понимаю стабильно. Это регулярно обсуждается. Если хочется хомячковый аргумент, то для среднего по больнице можно на мандриву посмотреть, > она в любом попугаеметре будет проигрывать. Но пруфов не будет, ведь это знают все! https://www.phoronix.com/scan.php?page=article&item=openmand... Ой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #25

14. Сообщение от Аноним (86), 13-Апр-20, 17:18	–4 +/–
А смысл? Я ничего не обсираю, это общеизвестная общепринятая информация. Вон в соседнем треде разбирали генерируемый им ассемблер. Он может нагенерировать лапшу из переходов, но не может выбрать нормальные инструкции. А "срезать углы" замечательно и gcc может, pgo просто сказка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #16, #37

16. Сообщение от Аноним (6), 13-Апр-20, 17:24	+/–
Ссылочку на тот тред, пожалуйста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #20

17. Сообщение от Alexey (??), 13-Апр-20, 17:33	+/–
А в чем собственно проблема с GCC, ставьте из портов не забывая обновить дерево. И, если не ошибаюсь, то с опциями оптимизации сильно увлекаться не стоит, по рекомендации BSD-шников, типа флаг=-O3. А по поводу пути "Солярки", попадание оной грозит свалке долгой стабильной работой (хотя хотелось бы посмотреть на ту свалку космических масштабов). Дальнейшего развития товарищам.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #29, #42

18. Сообщение от abi (?), 13-Апр-20, 17:36	+/–
ng_bridge этих недостатков не имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #22, #24

19. Сообщение от abi (?), 13-Апр-20, 17:38	+/–
> А в чем собственно проблема с GCC Так лицензия же, её не включить в base
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #23

20. Сообщение от Аноним (86), 13-Апр-20, 17:41	+/–
Как? Поисковики не индексируют, поиска тут нет. Вся конкурентоспособность сводится к способности генерировать лапшу из переходов. Но лапша эта может оказаться совершенно не эффективной в зависимости от данных. Вот какая-то хомячковая статья откуда-то оттуда же, может для иллюстрации сойдёт https://habr.com/ru/post/483864/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #49

21. Сообщение от slava_kpss (ok), 13-Апр-20, 17:44	+2 +/–
А почему никто не жалуется, что в Windows программы не собирают с помощью свободного божественного GCC?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #26, #27

22. Сообщение от Аноним (22), 13-Апр-20, 17:45	+/–
С фигали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

23. Сообщение от Аноним (22), 13-Апр-20, 17:48	+/–
Зачем он тебе в базе? Поставил из портов и собираю базу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #30

24. Сообщение от Аноним (4), 13-Апр-20, 17:51	–3 +/–
ты думаешь у них разные клумбы в цветочнике по имени ядро?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #59, #174, #175

25. Сообщение от Аноним (7), 13-Апр-20, 17:54	+/–
Тест того как дистры работают на процессоре AMD 3970x? Тем более там везде разные победители. Вот что интересно так это даст ли какой то прирост компиляция про помощи amd'шного компилятора aocc который тоже на llvm или нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #28, #32

26. Сообщение от Аноним (86), 13-Апр-20, 17:54	–1 +/–
Вообще-то собирают, любой опенсорс и не только всегда им собирался. Для навязывания msvc создавалась несколько нездоровая атмосфера принуждения, сейчас нечисть Балмера отправили на пенсию и взгляды несколько поменялись, шланг внедрили во многие продукты и он резко обрёл популярность. Способность полноценно генерировать нужный код для венды изначально была угловым камнем для шланга, гцц подтянулся уже после него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #140

27. Сообщение от Аноним (7), 13-Апр-20, 17:57	+/–
Потому что все что надо им собрать нормально собирается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #58

28. Сообщение от Аноним (86), 13-Апр-20, 17:58	+1 +/–
Ну он просто увидел картинку, где жаба собранная шлангом на любимой десяточке впервые в чём-то победила и потёк. Подумать о результатах уже слишком сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #34

29. Сообщение от Аноним (29), 13-Апр-20, 18:08	+/–
Я всё уже много лет собираю на Фрибсд с -O3 и нет проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #33

30. Сообщение от Аноним (30), 13-Апр-20, 18:13	+/–
Так продаваться несолидно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

31. Сообщение от Аноним (31), 13-Апр-20, 18:16	+/–
Тестил как-то на фре порты, собранные разными компиляторами, и с разными оптимизациями и без. Во-первых разница между всеми комбинациями была небольшая, 1-3% Сказочки про 30143% не рассказывай взятые из головы. Во-вторых LLVM как раз таки на эти пару процентов обгонял GCC. Разумеется, это справедливо только для того конкретного софта и системы. В каких-то случаях и флаги оптимизации оправданы, в каких-то и GCC обходит, не расстраивайся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #35, #47

32. Сообщение от анонн (ok), 13-Апр-20, 18:16	+/–
> Тест того как дистры работают на процессоре AMD 3970x? Тем более там > везде разные победители. И? Что там писалось? > она в любом попугаеметре будет проигрывать. Вот контрпример. А больше влет и не гуглится - несмотря на горячие заверения "это знают все!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

33. Сообщение от Аноним (31), 13-Апр-20, 18:22	+/–
Порты? Или и систему тоже?)) -О3 кажется даже дает небольшое падение производительности по сравнению с -O2 (по дефолту обычно идет), но я глобально не тестил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #100

34. Сообщение от анонн (ok), 13-Апр-20, 18:22	+2 +/–
> Ну он просто увидел картинку, где жаба собранная шлангом на любимой десяточке _моей_ любимой десяточки там нет - моя любимая десяточка уже EoL. Поэтому у меня любимая двенадцаточка. Которой там, впрочем, тоже нет. Или имелась в виду "любимая десяточка" анонима? Странно, я-то думал что аноним больше по макоси. > впервые в чём-то победила и потёк. Подумать о результатах уже слишком сложно. Смотрим глазами: > msec, Fewer Is Better > OpenMandriva 4.1 Znver  2585 > OpenMandriva 4.1 x86_64  2639 > Windows 10 Enterprise  2999 > Windows 10 Pro  3044 . > DaCapo Benchmark v9.12-MR1 > Java Test: Jython > msec, Fewer Is Better > Clear Linux   3513 > Manjaro Linux 19.0.  3623 > Windows 10 Enterprise 4633 Т.е. ты, балаболка анонимная, не то что пруфануть - даже картнику толком посмотреть не осилил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

35. Сообщение от Аноним (86), 13-Апр-20, 18:23	–2 +/–
Вон я там ссылку привёл. Шланг никогда _никогда_ не обходит гцц, если это только не баг генерации или подобное. И разница там на 3%, ближе к 20 (иногда и все 300). >В каких-то случаях и флаги оптимизации оправданы В любых случаях pgo, включающий необходимые оптимизации в нужных местах, мешает шланг с землёй. Ну если задача вообще зависит от качества генерации кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #39, #60

37. Сообщение от TheFotoMag (ok), 13-Апр-20, 18:41	+1 +/–
>> Я ничего не обсираю, это общеизвестная общепринятая информация То есть, от разработки вы далеки бесконечно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #41

38. Сообщение от Deanon (?), 13-Апр-20, 18:44	+6 +/–
О отличная новость, ОСь развивается в нужном направление без спешки. Очень удобная для изучения, да и для работы во многом выручает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #77

39. Сообщение от TheFotoMag (ok), 13-Апр-20, 18:46	–2 +/–
>> Шланг никогда _никогда_ не обходит гцц Шланг содержит ПОЛНОЦЕННЫЕ СРЕДСТВА ДИАГНОСТИКИ и позволяет, в отличие от гцц с коркой «рантайм еррор, стоппед», получать сообщения «ошибка приведения типов в функции имя функции строка 6778 аргумент блаблабла» Но вы этого никогда не узнаете, поскольку с кодом не работаете. В связи с этим, зачем и о чем вы тут высказываетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #40

40. Сообщение от Аноним (86), 13-Апр-20, 19:02	+/–
Лол. Что это ещё за фантазии? Оно появилось в гцц лет 10 назад, сразу после шланга (я нигде не говорил, что от шланга нет пользы).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #54

41. Сообщение от Аноним (86), 13-Апр-20, 19:05	+/–
Вы, видимо, ещё дальше -- я там увидел "аргумент" про отсутствие достаточной диагностики в гцц, хех.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

42. Сообщение от анонн (ok), 13-Апр-20, 19:07	+7 +/–
> А в чем собственно проблема с GCC, ставьте из портов не забывая > обновить дерево. Если вы Настоящий Линуксоид Опеннета, то проблема в недостаточной гибкости вашего восприятия! Ведь одно дело - Самое Лучшее Ядро. Ну нельзя его под GPLv2 переводить - Платиновые Папик^W партнеры недовольны будут! И отсутствие изкоробочного компилятора под GPLv3 в той же бубунте и прочих мейнтсримных дистрах - это ... необходимость и Хитрый План! Понимать надо! И совсем-совсем другое - бзды! Тут отсутствие пропатченой GPLv3 компоненты (из-за которой вполне можно потребовать перевести все остальные компоненты под ту же лицензию, что в свою очередь потребует или выкидывание и переписывание кучи компонентов или услуги некромантов и медиумов для получения согласия всех учавствовавших разработчиков. О возможной, очередной смене лицензии без предупреждения, во время минорного обновления - просто скромно не будем вспоминать) в бсдшом бейз-бандле -- явный признак прогиба под проприерасов! Понимать надо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

44. Сообщение от Аноним (44), 13-Апр-20, 19:22	–10 +/–
>Из дерева исходных текстов FreeBSD-CURRENT удалён набор компиляторов GCC, а также неиспользуемые утилиты gperf, gcov и gtc (компилятор devicetree). Всё пацаны! Это начало конца ФриБЗД. Отказ от ГНУ это непростительная ошибка и начало деградации.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #61

46. Сообщение от Аноним (46), 13-Апр-20, 20:06	–3 +/–
>лицензию GPLv3, которая была признана неприемлемой В угоду корпорастам.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50, #82

47. Сообщение от Аноним (86), 13-Апр-20, 20:07	+/–
Сорян, есть обновлённая инфа из проверенных источников. На операциях с малыми объёмами данных (конкретно 500 конкатенаций строк ~10-15 символов или около того) clang-10 O3 может показать превосходство над gcc93 Ofast порядка 20%, по сравнению с gcc93 -O3 разница в производительности легко может доходить до 50%. clang-10 O3 быстрее gcc93 Ofast + lto + pgo на ~1.5%. Скорее всего там та самая лапша из переходов, из-за которой шланг сыпется на более сложных кейсах, я не могу проверить. Бинарники у шланга в 2 раза больше с lto=thin, в 1.7 с lto=full, по сравнению с гцц lto + pgo.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #53

49. Сообщение от Аноним (6), 13-Апр-20, 20:15	+/–
>Поисковики не индексируют Индексируют. Запрос вида: site:opennet.ru запрос
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #52

50. Сообщение от zzz (??), 13-Апр-20, 20:33	+6 +/–
Как там идет процесс перевода линуксового ядра под GPLv3?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #55

51. Сообщение от IdeaFix (ok), 13-Апр-20, 20:37	–2 +/–
Докер всё там же? Прошу понять правильно, клетка не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67, #74, #81, #134

52. Сообщение от Аноним (86), 13-Апр-20, 20:37	+/–
По-моему там только новости, не комменты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #57

53. Сообщение от Аноним (86), 13-Апр-20, 20:42	+/–
Это кстати для си, с плюсами всё куда интересней может быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #101

54. Сообщение от TheFotoMag (ok), 13-Апр-20, 20:50	+/–
> Лол. Что это ещё за фантазии? Оно появилось в гцц лет 10 > назад, сразу после шланга (я нигде не говорил, что от шланга > нет пользы). Понятно. И гцц, и шланг ты видел на картинке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #56

55. Сообщение от Annoynymous (ok), 13-Апр-20, 20:55	+10 +/–
Никак. В угоду корпорастам, которые это ядро и развивают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

56. Сообщение от Аноним (86), 13-Апр-20, 21:00	+/–
> Понятно. И гцц, и шланг ты видел на картинке. Угу, кончено. Оно теперь даже говорит (в гцц), что ты забыл, и на что надо исправить. Лютая дичь, как по мне. Но я думаю тем, кто привык к msvc, шланг действительно кажется чем-то волшебным. Диагностические средства (рантайм, не статистические) у них одинаковые насколько я помню, +- парити поддерживают. Из ярких преимуществ гцц, помимо нормально генерируемого кода... Я вот не знаю как билдить любую программу совершенно без проблем с пго в шланге. В гцц это задача совершенно элементарная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

57. Сообщение от Аноним (6), 13-Апр-20, 21:16	+/–
В гугле ищи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

58. Сообщение от Аноним (31), 13-Апр-20, 22:13	–1 +/–
Телеметрию?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #110

59. Сообщение от ААА (?), 13-Апр-20, 22:23	+6 +/–
В цветнике. Цветочник это дяденька такой, цветы продаёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

60. Сообщение от Ordu (ok), 13-Апр-20, 23:03	+/–
> Вон я там ссылку привёл. Шланг никогда _никогда_ не обходит гцц Сходи и посмотри на ссылку ещё раз. clang там обходит gcc, в табличке написано. g++ обходит clang++, но я это не смог проверить, поскольку C++ код автор забыл выложить. Он утверждает что g++ быстрее, но там же в примечаниях он указывает, что перестановка сравнений в в коде приводит к тому, что clang++ оказывается быстрее g++. То есть твои "никогда _никогда_" -- это прямое следствие твоего нежелания видеть свидетельства тому, что ты не прав.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #62

61. Сообщение от Аноним (61), 13-Апр-20, 23:08	+/–
С тех пор, как GNU выгнали Столлмана, они перестали вызывать у меня симпатию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #65

62. Сообщение от Аноним (86), 13-Апр-20, 23:13	+/–
Да не, там история большого факапа в табличке, можно было со значительно большей пользой время на порнхаб потратить. Ну как бы такие различия намекают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #63

63. Сообщение от Ordu (ok), 13-Апр-20, 23:39	+1 +/–
> Да не, там история большого факапа в табличке, можно было со значительно > большей пользой время на порнхаб потратить. Ну как бы такие различия > намекают. Эмм... Что за факап? Что различия намекают? Если табличка противоречит чистой религиозной вере, то тем хуже для таблички? Или ты к тому, что это история факапа gcc? Увидев в табличке rust, я заглянул в код и увидел там unsafe, используемый ради ухода от проверок на выход за границы массивов. Мне стало интересно что будет, если убрать unsafe и вернуть проверки, и поэтому я скачал C'шный вариант и rust'овый, а скачав я не поленился в разных вариантах их скомпилировать. clang++ и gcc++ я попытался использовать на сишном сорце, но они ругаются из-за сишных приведений типов указателей -- это несложно пофиксить, но... явно это не тот код, которым автор тестировал C++, так что я не стал париться. И выходит что-то типа: clang: 1.12с rust-unsafe: 1.18с gcc: 1.27с rust: 1.49с Это плюс-минус то, что в табличке. Плюс-минус километр, конечно, но учитывая отличающиеся версии компиляторов и разное железо, вполне объяснимая погрешность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #70

64. Сообщение от Фанат (?), 14-Апр-20, 00:04	+/–
Проблемы у MSVC и GCC сходны и видны невооруженным глазом. https://cloud.mail.ru/public/4UL7/5z6UKchAc GCC и MSVC разрывает последовательность записи и чтения блока данных.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #105

65. Сообщение от Аноним (65), 14-Апр-20, 00:05	+/–
Столлмана выгнали не GNU, А FSF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

66. Сообщение от Ivan_83 (ok), 14-Апр-20, 00:08	+/–
Это всё здорово, но есть штуки типа этой: https://reviews.freebsd.org/D21206 вроде мелочь но сильно портит жизнь не только на десктопе но и на серверах. И в багтрекере таких коммитов ещё с десяток, которые иногда даже в апстрим взяли уже, и тут готовый патч лежит который только вмержить но нет. В amdgpu работа в этом году состоит менее чем в 10 коммитах.
Ответить | Правка | Наверх | Cообщить модератору

67. Сообщение от Аноним (67), 14-Апр-20, 00:18	+/–
На сегодняшний день, если нужен докер - используй линь, если не нужен - спокойно можешь работать в фри.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

68. Сообщение от paulus (ok), 14-Апр-20, 00:57	+/–
>NomadBSD 1.3.1, представляющего собой редакцию FreeBSD Редакция эта что-то на двух ноутах даже Х-ы не подняла :( Линуксы от мала до велика себе такое не позволяют...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69, #91, #125

69. Сообщение от G0Dzilla (??), 14-Апр-20, 06:17	+2 +/–
Ой ли? На самом деле конфигов ноутов великое множество. Потому я своими глазами вижу, как на части этих ноутов даже Ubuntu без напильника не поднимает X-ы. Совсем небольшая часть от всех ноутов, но все же такие есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #79

70. Сообщение от Аноним (86), 14-Апр-20, 07:35	+/–
Автор чёт сравнивал-сравнивал, рассуждал, но поленился заглянуть в ассемблер. Свои рассуждения по поводу гцц я выразил в #47, ознакомьтесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #72

72. Сообщение от Ordu (ok), 14-Апр-20, 08:41	+/–
> Автор чёт сравнивал-сравнивал, рассуждал, но поленился заглянуть в ассемблер. Если бы он заглянул в ассемблер, то изменились бы цифры в табличке? Или что бы случилось? > Свои рассуждения по поводу гцц я выразил в #47, ознакомьтесь. Я читал. Не интересно. Вот если бы ты вскрыл бы логику и объяснил бы происходящее не словами "запутался в переходах", а в стиле "llvm пытается сделать то-то и то-то, чтобы конвееры были бы забиты работой, а получается сё-то и сё-то, и поэтому половина конвееров простаивает в ожидании", это могло бы быть интересно. А так глянуть на вывод компиляции в -S, прикинуть в уме гистограмму используемых инструкций и строить рассуждения на этом... я не вижу глубинного смысла, и не интересно. При этом совершенно непонятно, что ты сравниваешь. "Конкатенации строк" -- что за строки и как ты их конкатенируешь? C'шные строки с терминатором в конце и неизвестным заранее размером? Ты их копируешь ручками в стиле while(*src) *(dst++) = *(src++)? Или ты используешь функции из string.h? Или ты используешь builtin'ы компилятора? Что с чем ты вообще сравниваешь? Автор статьи хоть и не заглядывал в ассемблер, но по-крайней мере привёл исходный код того, что он сравнивал. По-крайней мере вопросов "что он сравнивал" не возникает, могут быть вопросы лишь о том, почему такие результаты. В твоём случае до вопросов к результатам дело не доходит, потому что нет ответа на вопросы об исходном коде. Но при этом, ты почему-то считаешь, что это с твоими сравнениями всё ок, а у автора статьи факап. Точно не наоборот?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #75

73. Сообщение от Аноним (73), 14-Апр-20, 08:44	+3 +/–
Разработчику NomadBSD в особенности всего наилучшего, лишь бы в комфорте делал свое дело.
Ответить | Правка | Наверх | Cообщить модератору

74. Сообщение от Anonimous (?), 14-Апр-20, 08:55	+5 +/–
Как в 2000 джейлы появились, так с ними и сейчас все ок. Это нативная вещь для FreeBSD, зачем там докеры?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #78, #149

75. Сообщение от Аноним (86), 14-Апр-20, 09:35	+/–
Я не знаю, чем там занимается llvm. Я вижу только ассемблер, который он генерирует. И он генерирует раздутый файл, который на типичном кейсе работает значительно быстрее гцц. Просто моя бытовая задача, не синтетика: распарсить текст (баш) и добавить его в жсон (jq) для дальнейшей обработки. Что и как тут совершенно не важно, важно то, что 500 строк добавляются до 20 секунд в зависимости от успешности компилятора. И лишние секунды начианают напрягать достаточно быстро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #128

76. Сообщение от Аноним (76), 14-Апр-20, 10:02	–4 +/–
Ну да, интеловское видео перетащили из линукса. ZoL тоже. Заживём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #85

77. Сообщение от Аноним (76), 14-Апр-20, 10:07	+/–
Как там с десктопом? Всякие зоомы, и шлаки и скупые запускаются?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #108, #114

78. Сообщение от Аноним (76), 14-Апр-20, 10:08	–4 +/–
И как в бзд-джейле запустить уже готовый докер-контейнер?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #93, #106

79. Сообщение от Аноним (76), 14-Апр-20, 10:12	–1 +/–
Есть у меня ленивец Е440. На линуксах работал всегда, но ни в одной из БЗДей(10, 11 и производные ливни) - не подымались иксы. Зато есть войфай! Псевдографики всем! И пусть все будут довольны. Видеокарты конечно бывают разные, но штеудовский интеграт... Завёлся даже в гайке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #111

81. Сообщение от Аноним (81), 14-Апр-20, 10:18	+/–
Софт на Go-вне не нужен от слова совсем. Докер не исключение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #84

82. Сообщение от iPony129412 (?), 14-Апр-20, 10:25	+/–
Да всем в угоду. Не каждый в восторге от софта, где лицензия на кучу страниц. И бывает, что честному разработчику для разъяснения как оно согласуется с лицензией другого продукта с открытым кодом, надо проходить суд на один год, задействовать кучу юристов и консультантов. А тем временем, в каком-то подпольном Китае нечестные вообще клали на этот GPL, и ничего им за это не будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

83. Сообщение от Аноним (84), 14-Апр-20, 11:05	–4 +/–
Для это поделки фрибсд даже Firefox официальный не выпускают. Вывод фря не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

84. Сообщение от Аноним (84), 14-Апр-20, 11:07	–1 +/–
Лучше на Go-вне чем на винде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

85. Сообщение от Аноним (85), 14-Апр-20, 11:52	+6 +/–
> Ну да, интеловское видео перетащили из линукса. Вообще-то из интеля. Или загружаемые чере NDISWrapper дрова у вас "из винды утащены!". > ZoL тоже. Но только у опеннетчиков на опеннете. У них тут своя, опеннетная реальность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #86

86. Сообщение от Аноним (86), 14-Апр-20, 12:00	–3 +/–
>NDISWrapper Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень прекрасно работало. И разве оно не заггружалось через прослойку в неизменном виде? У вас там что, дрова тоже через линуксулятор работают? 32 бита онли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #89

87. Сообщение от Dmitry (??), 14-Апр-20, 12:12	+4 +/–
Аноним не осилил "pkg install firefox" ? Да, уровень свидетелей святого ядра скатывается все ниже и ниже...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #88, #107

88. Сообщение от Аноним (86), 14-Апр-20, 12:16	+/–
Я Оперу хотел скачать, в интернете мне предложили только линуксулятор, который так и не смог её запустить потому что она 64 бита и там какие-то проблемы с версиями. Вот так. Зачем нужна такая система на десктопе, если для неё нет единственной приличной хромосборки. И с электроном кстати тоже проблемы возникли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #90

89. Сообщение от Аноним (-), 14-Апр-20, 12:18	+2 +/–
>>NDISWrapper > Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень прекрасно работало. Ммм, как бы тебе сообщить это: даже если это так, то ... это ровным счетом ничего не меняет. > И разве оно не заггружалось через прослойку в неизменном виде? Принцип тот же - великодушно выпущенные (и зачастую креноватые и доводимые до "gpu hung всего лишь раз в неделю! Ура!" состояния иногда по нескольку лет) для пингвинят дрова от интеля загружается через враппер - потому что менять там что-то даже сами интеловцы не очень любят. > У вас там что, дрова тоже через линуксулятор работают? 32 бита онли? Казалось бы, причем тут линуксулятор, да еще и 32 бита?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #92

90. Сообщение от Аноним (31), 14-Апр-20, 12:25	+/–
Зачему тебе эти хромые сборки и электроды? Вот качай нормальную Оперу: https://ftp.opera.com/pub/opera/unix/1216/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #95

91. Сообщение от zshfan (ok), 14-Апр-20, 12:25	+3 +/–
Простой личный пример: Дано: Ноутбук Dell Inspiron 15 7000 Gaming NomadBSD - запустилась, подхватила иксы, подхватила Wi-Fi, всё работает. Ubuntu Beta 20.04 запустилась, при открытии любого приложения иксы слетают на 1024х768, постоянно теряется Wi-Fi, вот такие вот дела.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #109

92. Сообщение от Аноним (86), 14-Апр-20, 12:28	–3 +/–
Ну ты сравнил проприетарные блобы другой системы, нелегально загружаемые через крап, и ворованные исходники, написанные (пусть и криво) производителем для своих карточек. Это разные вещи. >причем тут Вот и мне непонятна логика твоих сравнений портированных исходников дров (с клеем или без -- неважно) с эмуляцией для блобов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #96

93. Сообщение от Аноним (-), 14-Апр-20, 12:29	+1 +/–
> И как в бзд-джейле запустить уже готовый докер-контейнер? И как в этом вашем дыркере запустить бзд-джейл-контейнеры? https://bastillebsd.org/templates/ https://gitlab.com/bastillebsd-templates
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #120

95. Сообщение от Аноним (86), 14-Апр-20, 12:36	+/–
> Зачему тебе эти хромые сборки и электроды? > Вот качай нормальную Оперу: https://ftp.opera.com/pub/opera/unix/1216/ Не, она конечно нормальная (особенно потому что она куда экономней нынешних браузеров), но уже лет 8 назад у неё были проблемы на куче сайтов (они тогда ещё решались подменой юзерагента). С производительностью и текучестью правда всегда проблемы были. Мне не совсем нравится нынешняя опера, пару лет назад она была куда круче и удобней (а ещё все её прокси можно было использовать свободно в любом браузере), но она всё ещё самая лучшая и удобная сборка хрома. А без хрома сегодня жизни нет. Электрон нужен, потому что много софта использует электрон. А тому нужны рабочие opengl и vulkan, среди прочего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

96. Сообщение от Аноним (-), 14-Апр-20, 12:37	+3 +/–
>  и ворованные исходники И у кого интель их слямзил? > Вот и мне непонятна Судя по всему, вся тема в целом анониму не очень понятна, но почему-то аноним настойчиво высказывает свое ценнейшее мнение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #97

97. Сообщение от Аноним (86), 14-Апр-20, 12:47	–2 +/–
> И у кого интель их слямзил? При чём тут интел, когда он абстрактный? > Судя по всему, вся тема в целом анониму не очень понятна, но > почему-то аноним настойчиво высказывает свое ценнейшее мнение. Зато анониму надо обязательно приплести неревантный треш из каменного века, из тех времён, когда драйверов с исходниками производители принципиально не выпускали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #102

99. Сообщение от аНоним (?), 14-Апр-20, 13:41	–2 +/–
Новости из теплого, лампового 2007 года.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #137

100. Сообщение от Аноним (29), 14-Апр-20, 13:55	+/–
И порты и систему. Работает быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

101. Сообщение от Аноним (86), 14-Апр-20, 14:13	+/–
Теперь о плохом. Вот mediainfo (плюсовая программа, весьма тяжёлая и тормозная) шланг нисколько не помог и только замедлил, у g++ на O2 код более эффективный и быстрый генерируется. Я уже проверял это прежде, потому что она очень уж тормозная и авторы вроде советуют шлангом собирать. После прогона сборки с PGO, g++ билд оказался на 15% быстрее clang++-10 O3 и на 10% быстрее g++-9.3 O2, Правда, стоило бы собрать более полноценную статистику, я прогнал только для 1 наиболее часто используемого варианта. Но суть остаётся. Всегда поражало нездоровое желание плюсовиков собирать релизные билды шлангом. Не знаю, как в венде (там есть варианты из-за тех же экцепшенов и много чего ещё), а в свободных системах шланг совершенно не конкурент гцц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #115, #132

102. Сообщение от Аноним (102), 14-Апр-20, 14:25	+/–
>> И у кого интель их слямзил? > При чём тут интел, когда он абстрактный? В вакууме, сферический? > Зато анониму надо обязательно приплести неревантный треш из каменного века, из тех времён, когда драйверов с исходниками производители принципиально не выпускали. Если аноним опеннета чего-то не понял, то это не пробел в знаниях опеннетного анонма (ибо опеннетные анонимы знают все-все-все), а просто "нерелевантный треш". Именно так и никак не иначе!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

105. Сообщение от Аноним (86), 14-Апр-20, 15:32	–1 +/–
Gcc на O3 генерирует очень, очень тормозной и раздутый код, следуя одному ему (меняющейся регулярно) понятной логике (которая вне всяких сомнений применима… где-то, но не здесь). Какой смысл выбирать O3? Польза иногда действительно перевешивает, но только на всяких кодерах и компрессорах. Вместо O3 надо использовать PGO, который включает оптимизации из O3 (и некоторые дополнительные) в нужных местах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

106. Сообщение от YetAnotherOnanym (ok), 14-Апр-20, 16:33	+/–
Ты, наверное, в картер двигателя заливаешь олифу, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #113

107. Сообщение от Аноним (110), 14-Апр-20, 16:48	–3 +/–
pkg от Васяна который неизвестно что собрал и к фиксам которого Мозилла никакого отношения не имеет? Нет уж если уж говорите что десктоп то или поддерживайте или валите на роутеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #112, #136, #161

108. Сообщение от Аноним (110), 14-Апр-20, 16:53	–2 +/–
Электрон не осуществляет поддержки фрибсд. Все работает на страх и риск бзднутых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

109. Сообщение от Аноним (110), 14-Апр-20, 17:08	+/–
Ubuntu 20.04 стабильная еще не вышла.   И даже 23 числа когда выйдет по хорошему надо ждать полгода чтобы ставить до 20.04.1. Так что не показатель.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #119, #142

110. Сообщение от Аноним (110), 14-Апр-20, 17:09	+/–
GCC можно и без телеметрии, а msvc ты без телеметрии от visual studio не обойдешься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

111. Сообщение от G0Dzilla (??), 14-Апр-20, 17:10	+/–
Многие современные производители пользовательской техники немного «подзабили» на унификацию. Несмотря на одну и ту же модель, иногда на двух соседних ноутах стоят разные компоненты. Поэтому на одних и тех же моделях операционная система, которая ценится за серверные качества, может вести себя по разному. Lenovo в этом плане не исключение. P.S. Бывший сотрудник сервисного центра этой компании и именно на этом бренде основывается мой опыт работы с Linux на рабочих компьютерах. P.P.S. Я так думаю, не нужен десктоп для FreeBSD. Каждый хорошей на своём месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #124, #133

112. Сообщение от Аноним (31), 14-Апр-20, 18:00	+3 +/–
Само дерево портов это часть ОС. Это у вас там ядро от Васяна, просто по удачному стечению обстоятельств оказавшееся в нужное время в нужном месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #123

113. Сообщение от Аноним (76), 14-Апр-20, 18:02	–1 +/–
Изначальный вопрос в треде звучал так, между прочим: > Докер всё там же? Прошу понять правильно, клетка не нужна. А кому нужен джейл - запустят джейл. Кому LXC/OpenVZ/Virtuozzo - запустят их. Линуксатор в бзде - есть. Со стороны докера же - есть нехилая библиотека образов. Сильно побогаче той, что у анонима выше. Так что продолжай дальше заливать про карбюратор. Я бы не прочь запустить докер на бзде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

114. Сообщение от аннон. (?), 14-Апр-20, 18:08	+4 +/–
> Как там с десктопом? Всякие зоомы, и шлаки и скупые запускаются? Кто о чем, а пингвиняши о нежно любимых проприетарных зондах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #118

115. Сообщение от Аноним (86), 14-Апр-20, 18:27	+/–
ПС мои "тесты" гцц херня скорее всего, там замедляющих харденед флагов по самые яйца напихано. А в шланговом билде их нет. Т.е. гцц ещё быстрее, чем у меня вышло. %)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #116

116. Сообщение от Аноним (-), 14-Апр-20, 18:34	+/–
> ПС мои "тесты" гцц херня скорее всего, Скорее всего "скорее всего" тут лишнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #117

117. Сообщение от Аноним (86), 14-Апр-20, 18:48	+/–
Не, ну что-то они показывают. В частности превосходство гцц над шлангом, а вот степень может варьироваться, поскольку стек протектор и _FORTIFY_SOURCE=2 имеют оверхэд в рантайме. И это ещё не всё, там с линкером подшаманено. Но при этом показывает сопоставимые результаты там, где медленней, и отрыв может быть больше там, где быстрей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

118. Сообщение от Аноним (76), 14-Апр-20, 19:01	–1 +/–
У тебя реально на десктопе только бздя? Просто я как-то не верю... А возможность запустить зонт - как-то лучше отсутствия оной. Вот у нас на работе - все в зооме, например. И реально был случай, когда одна девочка так и не смогла вернуться на бздю. Вроде на линуксе ей тоже неплохо, вот только ты потерял ещё одного пользователя, и мне от этого - совсем не приколько. Так что давай, расскажи с вантузомакакоси насколько зонды не нужны на бзде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #127

119. Сообщение от xm (ok), 14-Апр-20, 19:06	+/–
В Ubuntu вообще надо ждать. Некоторые вещи годами. Ну чистый дзен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

120. Сообщение от Аноним (76), 14-Апр-20, 19:08	–2 +/–
> И как в этом вашем дыркере запустить бзд-джейл-контейнеры? Да я и не против бы это сделать, честно. Больше возможностей - лучше для меня. Меньше - хуже. Итак, есть у нас десятки шаблонов под джейлы и лимоны - дыркер-контейнеров. Вот он, выбор. https://forums.freebsd.org/threads/docker-is-dead.69955/ Для LXC тоже есть какие-то шаблоны, так что джейлы мне ничего нового не датут. А жаль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

123. Сообщение от Аноним (76), 14-Апр-20, 19:18	+/–
> ядро от Васяна, просто по удачному стечению обстоятельств оказавшееся в нужное время в нужном месте. Не в обстоятельствах единых дело. Вон ведро от ваших Васянов появилось здесь слегка раньше ведра от наших Васянов. И чо? А... Так фришным ваше ведро стало слегка позже вашего...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

124. Сообщение от Аноним (76), 14-Апр-20, 19:22	+/–
Знаешь, нужен. Хотя бы мне. Наличие альтернатив - всяко лучше, чем отсутствие оных. Кстати видяшка в этом ленивце - i915. Что может быть ещё унифицированнее?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #141, #151

125. Сообщение от Аноним (125), 14-Апр-20, 19:24	+/–
Это не к вам, а в целом, к свидетелям дефолтных конфигов: не ебитесь, поставьте винду. Если вы хотите yes->yes->next->install - не надо гнать на бзды и перебирать линксовые дистры. Не хотите разбираться, хотите next->next->ok? Ну так это в винде тру. Хотите вкурить линуксы? Ну это явно не убунта со стимом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

126. Сообщение от neAnonim (?), 14-Апр-20, 20:04	+/–
vulkan построен поверх spir-v что является форком llvm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #131

127. Сообщение от анонн (ok), 14-Апр-20, 20:09	+1 +/–
> У тебя реально на десктопе только бздя? Да. > Просто я как-то не верю... Это твои проблемы и комплексы. > А возможность запустить зонт - как-то лучше отсутствия оной. Вот у нас > на работе - все в зооме, например. И реально был случай, Прикинь, если мне действительно нужно будет - я запущу. Я ж не опеннетная Пингвиняша, впадающая в уныние от того, что в любимом дистре сменили тему и набок иконок и теперь придется искать новый любимый дистр. И для которой Пингвинчик - замена Венды, только "на ХАЛЯВУ!" и поэтому привычно и по виндусячьи запускающая двойным кликом пропритерный setup.elf (даже не подумав упихать сие в виртуалку или контейнер). > вот только ты потерял ещё одного пользователя, и мне от этого - совсем не приколько. Оу, не переживай - мне лично от "потери" очередного "потреблятеля" ни холодно ни жарко. А уж от потери "потреблятеля", выдуманного опеннетным анонимом ... > Так что давай, расскажи с вантузомакакоси насколько зонды не нужны на бзде. Т.е. настойчиво пропаган^W предлагаешь установить винду или макось? Да ты настоящий опеннетный Линухоид! А можно, я воздержусь или из виртуалки это сделаю? И чур, лицензия с тебя (а то у меня есть только XP - из тех самых официальных халявных образов VDI "для вебдевов", с ограничением на полтора часа).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

128. Сообщение от Ordu (ok), 14-Апр-20, 20:29	+1 +/–
> Просто моя бытовая задача, не синтетика: распарсить текст (баш) и добавить его > в жсон (jq) для дальнейшей обработки. Что и как тут совершенно > не важно, важно то, что 500 строк добавляются до 20 секунд > в зависимости от успешности компилятора. Не, всё чуть сложнее. Низкоуровневая оптимизация, как и любая оптимизация, совершенно бессмысленна в отрыве от задачи. Любые попытки выделить маленький кусочек из задачи и оптимизировать его будут бессмысленны, до того как ты не прошёлся оптимизацией по задаче в целом, не выбрал алгоритмы и структуры данных, и до того, как ты не провёл профилирование и не выяснил, что эта подзадачка поедает у тебя хотя бы процентов 10 времени. Когда ты выдираешь из своей несинтетичной бытовой задачи маленькую подзадачку, то эта твоя маленькая подзадачка становится той самой синтетикой. Внутри strcpy есть условный переход, из-за него всё происходит не так быстро, как могло бы. Если ты работаешь с C'шными строками, то процессор копируя его постоянно лочится на этом условном переходе, и по сути у тебя работает один конвеер, и далеко не в полную силу. Если ты этот strcat срастишь со своим лексером, чтобы они стали единым целым, то есть шансы, что тебе удастся сделать это не добавив к лексеру ни единого условного перехода. Таким образом "пустой" прогон лексера (который обходит все синтаксические конструкции но ничего не делает) будет отличаться от прогона в котором лексер копирует полезные строки куда-то на {0-1 такт} умножить на {количество скопированных символов}. То есть реально при некотором везении его скорость работы будет неотличима от пустого прогона, то есть ты получишь _бесплатный_ strcat. В реальности, правда, будет чуть больше кеша использоваться и надо полагать будут почаще промахи поисходить, и может в результате твой лексер будет под нагрузкой работать на 1% дольше, чем без неё. Если ты правильным образом подберёшь место куда лексеру надо копировать char'ы -- можно ведь сделать так, чтобы он сразу копировал их в строки вида: "name" = "value", то затем тебе останется взять эти строки и скормить их сисколлу writev. Если тебе удастся прям сразу собирать одну большую строку финального json, то тебе даже не придётся доковыриваться до сисколлов, и ты сможешь сделать это аналогом сисколла write который есть в стандартной библиотеки практически любого языка. Навскидку я скажу вот что: если у тебя 500 строк добавляются 20 секунд, то там что-то серьёзно не так с парсером и даже если ты проведёшь все низкоуровневые оптимизации, ты сэкономишь допустим 50% времени, строки будут добавляться 10 секунд, и всё равно эти числа будут указывать на то, что с парсером что-то серьёзно не так. То есть на несколько порядков не так. Или может у тебя многие гигабайты bash-кода, и нужные строки там попадаются редко и таким образом у тебя бутылочным горлышком оказывается ввод/вывод, а не парсинг и генерация json?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #130

129. Сообщение от Аноним (4), 14-Апр-20, 21:10	+/–
жаль, что tuntap на данный момент имеет те же проблемы, как написал в рассылке kp@
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

130. Сообщение от Аноним (86), 14-Апр-20, 21:21	+/–
Всё как раз предельно просто. Все вопросы к автору jq, я не могу его ускорить. Разве что bison внезапно волшебным образом ускорится, подождём. PS. Если мне надо будет быстрее, я возьму тот же питон, правда я сомневаюсь, что станет значительно быстрее. Да и дело то совсем не в этом. Это вся задача целиком, единственная цель тут - взять сотни жсона и добавить их к другим жсонам. В реальной версии добавляется ещё произвольные запросы жсона из тысяч жсона и мешок регулярок, копированием строк тут не обойдёшься. Быстрее не будет, потому что быстрее физически невозможно, не нарушая условия. В питоне можно разве что можно избавится от запуска процесса на каждую строку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #135

131. Сообщение от Аноним (86), 14-Апр-20, 21:41	+/–
> vulkan построен поверх spir-v что является форком llvm. Eue, даже более того, нвидиевский nvvm тоже llvm (я всё ещё собираю гцц по старинке, но куда работает только с 8 -- видимо всё).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

132. Сообщение от Аноним (86), 14-Апр-20, 21:57	+/–
Делают ли 30% погоду? Визуально стало очень приятно. Прямо очень, а то чутка напрягало. Может ли ускорение на треть принести счастье? Такое ощущение, что может. Пго прелесть всё-таки, респект разрабам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

133. Сообщение от paulus (ok), 14-Апр-20, 22:23	+/–
> Многие современные производители пользовательской техники немного «подзабили» на унификацию. Согласен, но древняя toshiba с radeon'ом как могла не взлететь? Может таки проблема nomadbsd, а freebsd может завестись с Х'ами? Что-то типа frenzy на bsd существует?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #182

134. Сообщение от FGSFDS (?), 14-Апр-20, 22:29	+/–
Докер в БЗДе там же, где и в других ОС, не поддерживающих cgroups нативно. Т.е. ставите Linux в виртуалку, ставите /usr/ports/sysutils/docker, докерите себе на здоровье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #150

135. Сообщение от Ordu (ok), 14-Апр-20, 22:54	+/–
> Быстрее не будет, потому что быстрее физически невозможно, не нарушая условия. Если физически невозможно, не нарушая условия, то можно даже не заморачиваться на оптимизацию. Оптимизация возможна только тогда, когда есть физическая возможность. > Все вопросы к автору jq, я не могу его ускорить. Ты не пробовал. Возьми профайлер и выясни почему он тормозит. Когда ты поймёшь почему, тогда можно будет рассуждать о существовании или несуществовании возможности ускорить. Хотя, с учётом дополнительной капли информации о задаче, которую ты выдал, я уже даже не знаю, что предположить. Я начинаю подозревать, что проблема в твоём коде: bison никоим образом нельзя назвать генератором самых быстрых парсеров, но всё же его парсеры неплохи в смысле производительности. Можно допустить что jq использует bison как-то не так, но мне это кажется менее вероятным, чем то, что ты jq используешь как-то не так. И если делать ставки, то (учитывая "запросы жсона из тысяч жсона и мешок регулярок") я бы поставил на то, что ты решаешь задачу на уровне json'а, хотя следовало бы решать её на уровне данных -- то есть парсить json в данные, работать с данными, а потом сериализовать эти данные в json. Реально попробуй весь этот json складывать в sqlite, и потом выполнять основной процессинг данных на языке программирования SQL. Кстати, если я угадал в чём дело, то python может оказаться быстрее C. Если я прав в своих предположениях, то можно и без sql сделать, но там тебе ручками придётся создавать индексы, жонглировать хеш-табличками -- в C примерно так же сложно, как пользоваться SQL, поэтому в любом случае лучше взять python, ruby, go, rust, или C++ на крайняк... что-нибудь из этого списка взять и сделать там. Я повторю ещё раз: 20 секунд на 500 строк -- это уровень производительности пристойный для 70-х годов. Если низкоуровневая оптимизация компилятора применяемая к strcpy может уменьшить эти 20 секунд до 19, то вместо того, чтобы перебирать компиляторы и флаги к ним, тебе следует объявить strcpy своим личным врагом и выкинуть из программы хотя бы 90% вызовов strcpy, заменив их чем-нибудь другим. Тогда твои 20 секунд уменьшатся сразу до 5 секунд или даже вообще превратятся в виртуальный 0 секунд, потому как твоя психика будет воспринимать время работы программы как моментальное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #138

136. Сообщение от Аноним (136), 14-Апр-20, 23:04	+/–
Свидетели ядра и ппа-помоек что-то говорит про васянов. Спешите видеть. Собирается все из исходников с сайта мозиллы. Что еще тебе нужно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

137. Сообщение от Аноним (137), 14-Апр-20, 23:32	+3 +/–
> Новости из теплого, лампового 2007 года. Да уж, ретрограды! Ни одного упоминания systemd!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

138. Сообщение от Аноним (86), 14-Апр-20, 23:38	+/–
Не низкоуровневая оптимизация, самая обычная. 20 секунд превращаются в 12 пересборкой одного jq (или сменой компилятора который его собирает, лол). В том и дело, что не тормозит. Я решаю задачу максимально быстро, используя все фишечки баша, и работаю я естественно с данными (которые все в памяти), которые для баша просто текст (это не текст, а текст, списки, и много чего ещё, но башу об этом знать не обязательно), но жсон-то прибавляет jq и тут ничего не сделать, разве что заменить его на что-нибудь, что будет исключительно складывать жсон (jq умеет многое, и часть из этого я использую помимо наиболее частой операции сложения). Смысла в этом не много. Или добавить поддержку жсона в баш (на си) или ещё лучше примитивно разбирать и складывать жсон, но это не очень красиво будет. Вообще, это нормально для баша -- пересылать одни и те же байты туда-сюда и копировать тысячу раз, это всё в порядке вещей. Я могу взять вместо жсона что-нибудь, что будет висеть в памяти, но быстрее оно не будет (пока жсон не разросся до миллионов значений, не актуально). Просто сравнил на кейсе, который достаточно медленно и печально отрабатывает, и шланг оказался где-то пригодным. Или вот другая задача, более примитивная: гигабайт чисел можно сложить в баше очень быстро, или можно сделать это значительно медленней сотней способов (более универсальных при этом). Можно попробовать поскладывать несколько гигов, и сравнить компиляторы. Но это уже действительно будет синтетика, что интересного в сложении чисел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #139

139. Сообщение от Ordu (ok), 15-Апр-20, 00:40	+/–
> Я решаю задачу максимально быстро, > используя все фишечки баша, > это нормально для баша -- пересылать одни и те же байты ... тысячу раз Эмм, ты нашёл какие-то таблетки от когнитивного диссонанса? Или как тебе удалось, при подобном уровне внутренних конфликтов, избежать принудительной изоляции от интернета? Вообще, я тут подумал, что если тебя тянет на олдскульные решения, то посмотри на R. Там мозголомность синтаксиса подстать башу, но он заточен на работу с табличками в памяти, и этот его синтаксис даёт плюс-минус те же возможности, что и хипстерский SQL. И да, R создан чтобы работать в виде командной строки, помимо этого к нему есть обёртки, чтобы помимо командной строки у тебя были бы всякие другие плюшки, которые может предоставить gui. А ещё R -- это обработка данных, оттуда один шаг до хайпа бигдаты. Если же тебе важнее результат, а не олдскульность решения, и бигдата тебе неинтересна, то, реально, глянь на python или Go. Их освоить проще чем bash, и они в отличие от bash заточены на то, чтобы обрабатывать данные в памяти. Баш хорош только для того, чтобы вызывать другие программы, которые будут обрабатывать данные в памяти. > гигабайт чисел можно сложить в баше очень быстро, или можно сделать это значительно медленней сотней способов Эмм... Я не думаю, что можно сделать медленнее чем в баше. То есть понятно, что скорость упрётся в скорость используемой реализации чисел произвольной точности, но либо bash не повлияет существенно на скорость, либо он её снизит. Если точный результат не нужен, то можно попробовать разбить гигабайт на килобайты, каждый сложить в отдельный float, получить миллион флоатов, разбить их на куски по 1000 флоатов, просуммировать каждый, получить несколько сотен флоатов и уже сложить их -- точность результата будет не фонтан, но по-крайней мере не придётся упереться в насыщение, когда добавление очередного положительного числа к сумме не меняет сумму. Но это варианты не совсем для bash'а: можно извернуться при помощи какого-нибудь там parallel, чтобы удобно разбивать задачу на подзадачи, да ещё и все ядра задействовать при этом, но проще и быстрее написать на C, и результат будет быстрее. Хотя если связаться с pthreads и раскидывать задачи по потокам, то сумма времени написания кода и выполнения его скорее всего окажется больше, чем в случае с bash и parallel. > 20 секунд превращаются в 12 пересборкой одного jq (или сменой компилятора который его собирает, лол) [...] сравнил на кейсе, который достаточно медленно и печально отрабатывает Если у тебя есть возможность выложить этот интересный кейс, чтобы я мог бы его воспроизвести, то я буду очень благодарен. Реально интересно: я подозреваю, что это глупость какая-то, то ли в ./configure, то ли ещё где-то. Но не факт: я бы скорее ожидал, что глупость такого рода будет давать пенальти к производительности при использовании llvm, потому как он менее популярен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #143

140. Сообщение от Lex (??), 15-Апр-20, 01:24	–1 +/–
Им собирают не потому, что он такой хороший, а вс - плохая... Просто, немалое количество проектов пилится под чем-то юникс-подобным, где гцц / шланг - базовые инструменты, такие же, как и вс-ка - для винды. Как ни странно, проекты, заточенные под один инструментарий( особенно, большие проекты ), проще собирать с его помощью, а не переносить на другой.. регулярно. И к слову, та же вс-ка( для винды ) очень даже неплоха.. по крайней мере, была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #144

141. Сообщение от G0Dzilla (ok), 15-Апр-20, 04:31	+/–
Тем, кому нужно, и на QNX соберут рабочее окружение. Мой посыл выше был о том, что разработчикам FreeBSD не нужно сильно ориентироваться на десктоп. А то мы ведь уже видели примеры десктопизации. Еще раз: каждый хорош на своем месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

142. Сообщение от zshfan (ok), 15-Апр-20, 06:38	+/–
Ну не соглашусь, убунту 20.04 это лтс, она должна быть вылизана изначально, ибо предполагается что она на поддержке будет долго, при том что сидя на каррент ветке фри такого не наблюдается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #145, #146, #147

143. Сообщение от Аноним (86), 15-Апр-20, 08:45	+/–
Смари. Делаешь файл с 500 строк в формате типа такого (у меня его генерирует sed), каждая строка должна выглядеть так и начинаться с точки, иначе мы её пропускаем, key будет разный (иначе в чём смысл), но может и повторяться: ."key" += {"item":["value"]} Более сложная структура не нужна. Потом построчно скармливаешь это jq по типу такого data="{}" faileddata="" while read object; do     if [[ '."' != "${object::2}" ]];then         faileddata+="${object}"$'\n';         continue;     fi     data=$(jq --sort-keys -c "${object}"<<<"${data}") done<<<"$srcdata" Учить как собирать программы я не буду, у меня генту и я просто переопределяю CC/CXX и флаги, а потом собираю как обычно пакетным менеджером. Можно наверно вручную покопаться в мейкфайле. ПС и пожалуйста, хватит рассказывать, что мне делать, лучше ускорь jq с любимым strcpy. Всего оверхэда тут на вызов процессов, потому что средствами самого баша не решаемо (sed можно заменить, но тормозит-то не он). ППС сразу говорю, если убрать сортировку, сколько-нибудь быстрее не будет, а пробелы уже убраны (-0.001с ориентировочно).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #148

144. Сообщение от Аноним (86), 15-Апр-20, 08:54	+/–
Нет. Одни и те же программы собирают msvc и продают за деньги. И собирают gcc и продают за деньги другие ребята, менее корпоративные. Не нужно путать ситуации, когда гцц используется из-за необходимости тащить cygwin.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

145. Сообщение от iPony129412 (?), 15-Апр-20, 09:12	+/–
> Ну не соглашусь Ну молодец. > убунту 20.04 это лтс, она должна быть вылизана изначально, она должна быть вылизана изначально, ибо предполагается что она на поддержке будет долго Нет. Как раз по этому зачастую туда пропихивают что-то по новее, ибо потом поддерживать долго. Например, тот же GNOME 3.26 вышел в 11 марта 2020. Понятно, что за полтора месяца выловить и починить свежие баги на разных конфигурациях сложно. Поэтому правило до первого сервис пака в полную силу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

146. Сообщение от iPony129412 (?), 15-Апр-20, 09:22	+/–
> на поддержке будет долго Или вот, понятно, что python2 выкинули в Ubuntu - ну не поддерживать же его дальше. Ну и привет. Steam вроде до сих пор просто так не ставится. Не факт, что всё утрясут до релиза. https://github.com/ValveSoftware/steam-for-linux/issues/6869
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

147. Сообщение от Аноним (-), 15-Апр-20, 10:53	+1 +/–
> Ну не соглашусь, убунту 20.04 это лтс, она должна быть вылизана изначально, > ибо предполагается что она на поддержке будет долго, при том что сидя на каррент ветке фри такого не наблюдается. Просто пример был изначально неправильный, с неправильными результатами - вот если бы под Линуксом работало хорошо, а под васянской сборкой CURRENT тормозило и фризилось -- никто бы и слова не сказал о "показателях".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

148. Сообщение от Ordu (ok), 15-Апр-20, 11:28	+/–
> Учить как собирать программы я не буду Я думал ты стебёшься, но когда увидел, что вытянутый с github'а актуальный коммит в master не собирается, потому как там Makefile'ы поломаны, понял что нет. Ппц. Что за быдлософт? > у меня генту и я просто переопределяю CC/CXX и флаги, а потом собираю как обычно пакетным > менеджером. А, да, точно, про пакетный менагер я чёт забыл. Там скорее всего подобран такой коммит из git, который собирается. Ты собирал с USE=oniguruma или без него? Влом разбираться, что это такое вообще. Поставил без этого аниме. > Можно наверно вручную покопаться в мейкфайле. Не, всё проще: CFLAGS="-O2 -march=native" ./configure. В configure можно и другие переменные передавать, если сделать configure --help, он расскажет какие. > ПС и пожалуйста, хватит рассказывать, что мне делать, лучше ускорь jq с > любимым strcpy. "Любимым"? C'шная обработка строк -- это один из _худших_ подходов, которые можно придумать. > Всего оверхэда тут на вызов процессов, Чта? У тебя тут оверхеда на O(N^2) парсинга, ты складываешь кусочек данных в data, и потом эту data парсишь заново. И потом ещё раз, и ещё раз... Правда я не заметил изменений во времени выполнения jq. Оно увеличивается к концу, но несущественно: за 2k строк время затрачиваемое на выполнение jq изменилось где-то от 0.055 до 0.075. То есть энквадрат сложности не успевает показать себя. Что наводит на мысль, что тормоза берутся не столько из-за парсинга или ещё какой-то обработки входных данных, сколько из-за накладных расходов на запуск. jq<<<"" отъедает 0.055-0.060 сек. Для сравнения: генерация 2k строк в том виде, как ты показал, отправленная в /dev/null занимает 0.008 сек. Запуск этого же генератора через cargo (который помимо запуска бинаря проверяет грядку файлов, чтобы не пропустить момент, когда надо пересобрать бинарь) отъедает 0.042 сек: $ time target/release/gen-strings >/dev/null real    0m0,008s user    0m0,006s sys    0m0,001s $ time cargo run --release >/dev/null real    0m0,042s user    0m0,029s sys    0m0,012s $ time jq</dev/null real    0m0,057s user    0m0,054s sys    0m0,002s Какая-то заморочная инициализация в jq? Что он там делает? Телеметрию на сервер отправляет? Не знаю, буду ли я ковырять jq, чтобы выяснить, чё он так тупит или нет, если будет настроение вечером, поковыряю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #152

149. Сообщение от IdeaFix (ok), 15-Апр-20, 12:00	–1 +/–
> Как в 2000 джейлы появились, так с ними и сейчас все ок. > Это нативная вещь для FreeBSD, зачем там докеры? Джейлы не нужны. Фрю юзает примерно 0% рынка и под эти нативные реализации полезных фич никто ничего не будет делать вне нуля процентов мира фрибсдшных юзеров. Т.е. докер форева бета... или совсем сломали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #154

150. Сообщение от IdeaFix (ok), 15-Апр-20, 12:02	–1 +/–
> Докер в БЗДе там же, где и в других ОС, не поддерживающих > cgroups нативно. Т.е. ставите Linux в виртуалку, ставите /usr/ports/sysutils/docker, > докерите себе на здоровье. Т.е. фрибсд не нужно... жаль. Так же жаль что по началу докер так лихо втаскивали и говорили вот-вот, еще чуть-чуть и будет хорошо, а теперь чот так же пафосно, но уже злобно шлют в так полюбившуюся клетку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #153

151. Сообщение от IdeaFix (ok), 15-Апр-20, 12:13	+/–
> Знаешь, нужен. Хотя бы мне. Наличие альтернатив - всяко лучше, чем отсутствие > оных. Кстати видяшка в этом ленивце - i915. Что может быть > ещё унифицированнее? Я сейчас буду телепатствовать, но... видимо, по Вашей логике, если у меня на netbsd 8.2 в железном SPARC32 есть пакет i915resolution, то там тоже есть i915?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

152. Сообщение от Аноним (86), 15-Апр-20, 12:43	+/–
>не собирается Да не, нормально. версия в ебилде точно такая же. ;) >oniguruma не, никаких онигурум конечно, и это, --disable-docs --disable-valgrind --disable-maintainer-mode --enable-rpathhack >всё проще Это работает с autotools, но не обязательно работает с любым софтом. >один из _худших_ подходов Ничего плохого не вижу! >потом эту data парсишь заново Ну и что? Где-то будет иначе? Всё равно обходить всё заново. >ерутся не столько из-за парсинга или ещё какой-то Вроде да, разве я не это сказал? >time Замерять по одному вызову такое себе, надо выполнить хотя бы 10 и брать среднее, и то может там в фоне что-то крутится эдакое. time jq</dev/null real    0m0.028s user    0m0.027s sys     0m0.001s Исходя из этих значений, будет на 200% медленнее, чем у меня (у меня старая версия, 1.6-r3). >Что он там делает Емнип там интерпретатор байткода (много фишечек, да), так что не так и много. Весь питон со штатным json кстати столько же примерно инициализируется, поэтому заменять на него смысла и нет. Памяти точно в тысячи тысяч раз больше уйдёт, и скорее всего медленнее будет. А кстати, так и получается, как раз столько и отрабатывает баш (jq собранный обычным способом даёт 16 секунд в норме, можно собрать так, что будет и медленнее). >>> 0.028*457 12.796 Т.е. всё в порядке, не нарушая законы мироздания, нам не ускориться. А что, где-то есть более быстрый и удобный процессор жсона? Я просто раньше питон с этими целями использовал в скриптах, но jq более быстрый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #157, #158

153. Сообщение от ГабенВул (?), 15-Апр-20, 13:55	+1 +/–
Ну какому-то васяну, в чьей вселенной  "докер это единственное и самое важное качество ОС" скорее всего не нужно. Остальные могут в докер на виртуалке, сидят работают и в общем-то их все устраивает. Такие дела
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #181

154. Сообщение от Аноним (154), 15-Апр-20, 14:00	+/–
>> Как в 2000 джейлы появились, так с ними и сейчас все ок. >> Это нативная вещь для FreeBSD, зачем там докеры? > Джейлы не нужны. Анонимные опеннетные оналитеки тоже не очень нужны. > Фрю юзает примерно 0% рынка и под эти нативные реализации полезных фич никто ничего не будет делать вне нуля процентов мира фрибсдшных юзеров. То ли дело портировать для того же нуля процентов пингвинячье нагромождение костылей и подпорок. Л-логика. > Т.е. докер форева бета... или совсем сломали? Смысл его портировать, если почти все образы сделаны хвостатыми - и ожидают именно пингвинчика, к которому они прибиты полуметровыми гвоздями и который придется эмулировать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #155

155. Сообщение от IdeaFix (ok), 15-Апр-20, 14:43	–2 +/–
> Смысл его портировать, если почти все образы сделаны хвостатыми - и ожидают > именно пингвинчика, к которому они прибиты полуметровыми гвоздями и который придется > эмулировать? У докера есть библиотека образов, у бсд есть проблемы. Клетка в частности и БСД в целом не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #156

156. Сообщение от Аноним (156), 15-Апр-20, 15:51	+/–
>> Смысл его портировать, если почти все образы сделаны хвостатыми - и ожидают >> именно пингвинчика, к которому они прибиты полуметровыми гвоздями и который придется >> эмулировать? > У докера есть библиотека образов, у бсд есть проблемы. А в огороде есть бузина ... > Клетка в частности и БСД в целом не нужно. Ценное мнение от очередного Опеннетного Знатока - тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

157. Сообщение от Ordu (ok), 15-Апр-20, 19:39	+/–
>>потом эту data парсишь заново > Ну и что? Где-то будет иначе? Всё равно обходить всё заново. Нет. json парсится в хеш-таблички, поиск в хештабличке и вставка туда элемента -- это O(log N). Если ты выполняешь это N раз, то ты получаешь O(N*log(N)), что в принципе терпимо. >>time > Замерять по одному вызову такое себе, надо выполнить хотя бы 10 и > брать среднее, и то может там в фоне что-то крутится эдакое. Как показывает практика, если запустить один раз для прогрева, и потом второй раз для измерения, то ты получишь числа с точностью достаточной для бытовых нужд. Этот же результат был получен в результате четырёх запусков команды, выкидыванием первого результата, и выбора среднего из оставшихся трёх. И да, если бы эти оставшиеся три сильно различались бы, я бы так не стал делать, а начал бы здесь писать о недетерминированности времени выполнения jq, и о том, что его писали какие-то лохи, которых вообще нельзя допускать до программирования. >>Что он там делает > Емнип там интерпретатор байткода (много фишечек, да), так что не так и > много. Весь питон со штатным json кстати столько же примерно инициализируется, > поэтому заменять на него смысла и нет. Памяти точно в тысячи > тысяч раз больше уйдёт, и скорее всего медленнее будет. Если есть длинная инициализация, то напрашивающийся способ оптимизации -- выполнять эту инициализацию единожды. В этот jq можно засунуть сразу _все_ его команды, чтобы он их выполнил последовательно за один запуск процесса? на пайтоне нет проблем написать скрипт, который будет читать строки вида ."key" += {"item":["value"]}, парсить их в три локальные переменные key, item и value, а потом делать data[key][item]=value. То есть весь код будет выглядеть так (warning: псевдокод, я не помню python'а и не знаю его API для работы с json'ом): def read_input_line():     // тут мы читаем входную строку, парсим её в три строки и возвращаем их while (key, item, value) = read_input_line():     data[key][item] = value print(json_to_string(data)) > где-то есть более быстрый и удобный процессор жсона? Я просто > раньше питон с этими целями использовал в скриптах, но jq более > быстрый. Для быстроты основной подход -- процессить не json, а структуры в памяти. В нативные для языка структуры в памяти. И после процессинга сериализовать в json. Если ты в bash напишешь скрипт, который соберёт все эти строчки в ассоциативный массив ассоциативных массивов, а потом сериализуешь эту конструкцию в json, у тебя получится быстрее чем 500 запусков jq, написанного на C. Но у bash, что-то мне подсказывает, есть проблемы с ассоциативными массивами ассоциативных массивов, потому как, видите ли, поддержка такого "ненужна", потому что всегда можно сделать что-то типа: $data[$key@$item]=$value Или это в awk так? Где-то такая офигительная оптимизация работы с хештабличками точно заботливо навязывалась программисту. Типа это быстрее. Я, за давностью лет, не помню где. А насчёт удобства -- я не знаю, я с json'ом сталкиваюсь эпизодически, и поэтому не особо парюсь об удобстве, пишу на том языке, на котором столкнулся с json'ом. Я бы, будучи на голову ушибленным rust'ом, написал бы всё на rust'е. Собственно, я и написал: // сначала тут ~70 строк описывающих генерацию charset'а, и троек случайных строк в этом charset'е, и затем: fn main() {     let mut rng = rand::thread_rng();     let charset = generate_charset("a-zA-Z0-9").expect("Invalid charset");     let mut data: HashMap<String, HashMap<String, String>> = HashMap::new();     for _ in 0..2000 {         let (key, item, value) = random_addition(&mut rng, &charset);         let entry = data.entry(key).or_insert(HashMap::new());         entry.insert(item, value);     }     println!("{}", serde_json::to_string(&data).expect("Fuck up")); } Тут генерится 2000 троек случайных строк (key, item, value), они добавляются в хеш-табличку хеш-табличек, и потом всё это сериализуется при помощи serde_json::to_string(); $ time cargo run >/dev/null    Compiling gen-strings v0.0.1 (/home/rgo/tmp/jq-test)     Finished dev [unoptimized + debuginfo] target(s) in 5.14s      Running `target/debug/gen-strings` real    0m5,781s user    0m1,961s sys    0m0,412s И это отработала версия собранная без особых оптимизаций в debug варианте. Что гораздо хуже, запущенная через cargo, который прежде чем запускать компилировал. Если эту логику написать на python, bash или чём угодно ещё, то оно будет в разы быстрее, потому что не нужна сложная компиляция.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #159

158. Сообщение от Ordu (ok), 15-Апр-20, 20:44	+/–
>>>> 0.028*457 > 12.796 > Т.е. всё в порядке, не нарушая законы мироздания, нам не ускориться. А > что, где-то есть более быстрый и удобный процессор жсона? Я просто > раньше питон с этими целями использовал в скриптах, но jq более > быстрый. Я почитал ман к jq, и написал тебе скрипт, который просто работает: jq -c "$(echo $srcdata | grep '^\."' | tr '\n' '|' | sed -s 's/|$//')"<<<{}
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #162, #167, #168

159. Сообщение от Аноним (86), 15-Апр-20, 21:33	+/–
Так ведь задача была добавить в жсон, потому что это "бд" на диске -- жсон. Всё может быть интересней, когда этот файл модифицируется в несколько потоков, т.е. его надо перечитывать при каждом добавлении (в практическом коде такой вариант есть, воркеры независимы -- нужна только блокировка в момент записи, чтобы избежать гонки в паре мест, а данные кто успел того и тапки, они в случае невероятного совпадения обновятся последним вошедшим). Да и я тут уже нарвался пару раз на ограничения передаваемых по трубе данных… Ну, можно вроде такого, сразу добавить все новые данные на диск jq>"j2.json"<<<$(jq --sort-keys -c '. += {"key1": {"item1":["value1"],"item2":["value2"]},"key2": {"item1":["value1"]}}'<j.json) Только тут ведь как, jq же их все генерирует, эти элементы, и обновляет при необходимости. Ну, чтобы там не было дубликатов, перезаписывает значения, и всё остальное. Я же не буду это в баше делать... Это придётся костылить массивы и прочее, потом каждый элемент хэштейбла будет хэштейблом. который будет содержать ареи и так далее… Хотя… Не, чёт я прогнал, в баше так будет сделать нельзя. Ну, арей хештейблу не присвоишь, только строку. Это городить eval с овер 100500 (буквально) переменных, этот способ ой ой ой какой костыльный, переменные будут называться key1item1=(value1 value2), нам надо вести учёт этих переменных, потом как-то проверять есть ли они вообще, перебирать через eval это всё по 5 раз, посимвольно сравнивать строки миллиарды раз, и вообще это всё очень неприятно. Тут и баш начнёт тормозить. Средствами баша это нормально не решается, скорее всего. А зачем в несколько потоков? Это разные процессы, и они добавляют данные параллельно… Есть логика сравнения времени изменения и синхронизации. Конечно, вариант висеть демоном в питоне, но тогда я опять же ограничен синхронизацией, трубой, 1 потоком, и постоянной сериализацией/десериализацией. Наверное, и не скалируется вообще, и этот многогигабайтный питон висящий фоном… Немного быстрее будет конечно, хотя бы потому что питон может в сложные структуры вроде вложенных хэштейблов, но.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #160

160. Сообщение от Аноним (86), 15-Апр-20, 21:37	+/–
Eval... Хотя завести список keys, список key1items, потом присваивать уже key1item1=(va1 val2). Ну варик наверно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

161. Сообщение от KaZaaM4iK (ok), 15-Апр-20, 22:36	+1 +/–
Почему сразу неизвестно? Зашёл на freshports (https://www.freshports.org/www/firefox/) и увидел все опции/флаги, которые установлены. И лучше уж какие то фиксы будут, чем оставлять известные проблемы без какого либо фикса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

162. Сообщение от Аноним (86), 15-Апр-20, 22:54	+/–
Хех, да, отлично работает. Я так уже делал где-то, не тут. real    0m0.123s user    0m0.117s sys     0m0.006s Но конкретно это не было так чтобы узким местом, Я имею в виду, 15 значений добавляются куда быстрее 500 (типичная нагрузка). И если я использую баш, значит, наверное, такой производительности достаточно… Зато это всё навело меня на определённые размышления. Я так увлёкся "честными" вычислениями, что начал дёргать тяжёлые программы несколько чаще, чем это необходимо. Хотя там это тоже не узкое место, примерно 0.00000000001% времени уходит. А вот в третьем… Чёрт, и там нужно прочитать гигабайты с диска, и основное время уходит на это. Ну хоть для части кейсов ускорю, тем более что это ничего не стоит. Хотя нет, стоит. Вот пересобрать с пго и получить в полтора раза ускорения в бонус, это ничего не стоит, а тут сейчас придётся разбирать xml вместо 10 вызовов утилиты. Пожалуй, оставлю как есть. В любом случае, спасибо за участие! Ускорение в 100 раз получили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #163

163. Сообщение от Ordu (ok), 15-Апр-20, 23:37	+/–
> если я использую баш, значит, наверное, такой производительности достаточно… Не сомневаюсь. Но исходно я ввязался в этот разговор, потому как ты сказал, что твой тест "не синтетичный" и показывает превосходство компилятора на реальном кейсе. Этот кейс может быть и реальный, но он от этого не перестаёт быть синтетикой. Искусственно созданные проблемы. Я, например, до сих пор не понимаю, зачем городить этот огород, если есть SQL. Создать табличку со строками key, item, value, и всех кого можно отправить работать с sql, а не с json'ом. А те, кого нельзя переориентировать на sql, один хрен получают этот json через сокеты общаясь с нашими демонами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #164

164. Сообщение от Аноним (86), 16-Апр-20, 00:13	+/–
> Не сомневаюсь. Но исходно я ввязался в этот разговор, потому как ты > сказал, что твой тест "не синтетичный" и показывает превосходство компилятора на > реальном кейсе. Ведь практически так и есть, я просто не ожидал такого явного превосходства шланга тут (при том, что файлы у него в 2 раза больше, они всё же быстрее запускаются). >Искусственно созданные проблемы. Это не проблемы, а односточник запускавшийся ровно 1 раз, но разница во времени исполнения как по мне очевидна. Пусть это и инициализация интерпретатора или чем он там занимается. Mediainfo работает с файлами на диске (в зависимости от формата файла, делает он это очень медленно), и гцц оказался значительно быстрее (совсем не 3%). >Я, например, до сих пор не понимаю, зачем городить этот огород, если есть SQL. Быстрее явно не будет. Когда объёмы будут такими, что нынешний подход начнёт создавать проблемы, тогда и подумаем. Я думаю, какая-нибудь монга тут более уместна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #165

165. Сообщение от Ordu (ok), 16-Апр-20, 01:20	+/–
> превосходства шланга тут (при том, что файлы у него в 2 раза больше, они всё же быстрее запускаются). Размер кода и скорость его выполнения слабо связаны. while(true); скомпилируется в два байта, но выполняться будет вечно. >> Искусственно созданные проблемы. > Это не проблемы, а односточник запускавшийся ровно 1 раз, но разница во > времени исполнения как по мне очевидна. Пусть это и инициализация интерпретатора > или чем он там занимается. Если нет реалистичной проблемы с производительностью, которая упирается в инициализацию интерпретатора, то тогда у нас нет оснований считать, что скорость этой инициализации сколь-нибудь важна, а это значит что и превосходство llvm на этой инициализации тоже может быть никому не нужным. Это вариация на тему тех претензий, которые предъявляют к любым синтетическим тестам. >> Я, например, до сих пор не понимаю, зачем городить этот огород, если есть SQL. > Быстрее явно не будет. Ты попробуй, прежде чем разбрасываться такими заявлениями. 500 запусков SQLite с добавлением одной строчки таблицы, за которым последует один запуск с извлечением всех строк и сериализацией в json совершенно определённо будут быстрее, чем тот твой скрипт, с которого мы начали. Даже если включить сюда инициализацию базы данных и создание таблицы. Даже если сериализация будет написана на bash. Вот ежели сравнивать выполнение задачи типа "добавить строку, получить сериализованное всё", то тут сложнее утверждать определённо. Можно утверждать определённо, лишь, что существует такой N, что для любого n, такого что n>N, решение на SQL будет быстрее. Но каким должен быть этот N -- я не возьмусь гадать. Может быть 0, а может быть 10000.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #166

166. Сообщение от Аноним (86), 16-Апр-20, 14:50	+/–
Раздутый код будет быстрее, если это лапша из джампов. Или медленнее, если он внезапно перестанет помещаться в кэши процессора (simd векторизация этому очень способствует, например). >нет оснований считать, что скорость этой инициализации сколь-нибудь важна, а это значит что и превосходство llvm на этой инициализации тоже может быть никому Я вроде упоминал, что при поступлении данных приходится делать выборку каждый раз. Мы ускорили только финальный этап записи данных на диск, перед этим в 3 раза больше вызовов происходит (нам нужно узнать, добавлять ли данные, или мы будем менять имеющиеся -- заодно получаем статистику имеющихся данных для key). Т.е. ускорение инициализации тут как раз ключевая задача, и её решение обеспечивает компилятор. >определённо будут быстрее Дело в том, что сейчас я работаю с текстом и по возможности без необходимости не трогаю диск (пока памяти более чем достаточно для данных). Сабж же добавит немало оверхэда и будет дёргать диск сотни тысяч раз. Sqlite можно использовать и для хранения данных в памяти, но на более нормальных языках, а не на баше. Кроме того, на данный момент у меня нет необходимости в каких-то сложных запросах, данные всегда находятся в одном месте (задача перебрать все value для всех item -- самое страшное, что может случиться, и она не очень проблемной окажется).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #170

167. Сообщение от Аноним (86), 16-Апр-20, 17:13	+/–
Я ещё немного подумал над этим, тут есть огромная проблема. Если нужно добавить данных больше лимита ОС, всё сломается. Может быть и 30кб в зависимости от системы. Видимо, я уже когда-то отбросил эту затею. Но я решил это проверить. Оказалось, что на моей системе уже строка в 130кб (всего 3к элементов вместо 450, 450 уже 17кб, что, вероятно является пределом для ряда систем). >просто работает незачёт, не работает. (:
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #172

168. Сообщение от Аноним (86), 16-Апр-20, 17:28	+/–
Более того, jq обламался ещё на 70кб, так что совсем никуда не годится. :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

170. Сообщение от Ordu (ok), 16-Апр-20, 20:14	+/–
> заодно получаем статистику имеющихся данных для key Сам бог велел задействовать sql. >>определённо будут быстрее > Дело в том, что сейчас я работаю с текстом и по возможности > без необходимости не трогаю диск (пока памяти более чем достаточно для > данных). Сабж же добавит немало оверхэда и будет дёргать диск сотни > тысяч раз. Sqlite можно использовать и для хранения данных в памяти, > но на более нормальных языках, а не на баше. В ядре, в списке псевдофс, есть RAM-диски.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #173

172. Сообщение от Аноним (86), 16-Апр-20, 21:40	+/–
Ради интереса передал фильтр через временный файл, jq всё равно фейлится, если он больше 70кб. В общем, смысла трогать не было, это не юзабельно в таком виде, хоть и быстрее. Ладно, если ты видишь проблему, ты можешь её решить. Пока что разбил на блоки по 50кб. Посмотрим, зато добавил какую-никакую недостающую логику обработки фейла и сохранения данных вокруг jq. Это 15мб повторяющихся данных блоками по 50кб (обновляет 17кб данных можно посчитать сколько раз), интересно было бы сравнить эффективность, если скормить одним фильтром, но не очень. Я так прикинул, собственно на вызов jq тут ушло 23 секунды из 7 минут. Лучше, видимо, не получится: gcc (пго старый под строки 100байт) real    7m45.175s user    7m20.088s sys     0m3.645s gcc (O2 lto) real    7m45.812s user    7m21.456s sys     0m3.542s gcc (O2 pgo+lto) real    7m22.190s user    7m6.515s sys     0m3.059s clang (O2 lto=thin, без харденед фишечек) real    7m9.484s user    6m44.182s sys     0m3.512s clang (O3 lto-full, максимально близко к gcc версии, минус stack-clash-protection) real    7m8.272s user    6m45.443s sys     0m3.455s ПС. Компилять гораздо веселее, чем костылять баш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

173. Сообщение от Аноним (86), 16-Апр-20, 21:53	+/–
Надо было брать xml вместо json, в 100500 раз быстрее было бы (это не точно, фишечек в xpath не сильно меньше чем в jq). Одна из задач тут конечно человекочитаемость (и человекоредактируемость), жсон мне кажется куда более приятным. Обновлённые данные в #172, получается, мои первые выводы были довольно близки к истине. Ну 400к (или сколько там) строк добавлять 7 минут это конечно не очень быстро. Но я уже делал что-то похожее со sqlite, и он даже без rowid не очень быстрый был. Postgres вроде норм в первом приближении оказался. Не помню чем закончилось, не то монгой, не то рокс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

174. Сообщение от bOOster (ok), 17-Апр-20, 09:05	+/–
Клумба в виде netgraph то одна, цветочки абсолютно разные. Одни пыльцу и мед пчелкам дают, другие мух ловят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

175. Сообщение от bOOster (ok), 17-Апр-20, 09:08	+/–
Убогие линукс последователи никак врубиться не могут - что сетевая подсистема FreeBSD не работает в общем ядре как таковом. к Ядру прицеплен netgraph а дальше уже стэк протоколов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

176. Сообщение от Аноним (176), 18-Апр-20, 09:18	+/–
Моя самая любимая ОС :) кто-бы що не говорил.
Ответить | Правка | Наверх | Cообщить модератору

177. Сообщение от Сергей (??), 18-Апр-20, 09:18	+/–
Моя самая любимая ОС :) кто-бы що не говорил.
Ответить | Правка | Наверх | Cообщить модератору

179. Сообщение от bOOster (ok), 18-Апр-20, 21:47	+/–
Чето все молчат, а ведь HAMMER от стрекозы - этож идеальная система для десктопа
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #183

181. Сообщение от тигар (ok), 20-Апр-20, 08:57	+/–
дурачек, которому ты отвечаешь, и в линакс с ним не работает:) не понятно, зачем тратить на него байты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

182. Сообщение от тигар (ok), 20-Апр-20, 09:01	+/–
зашибись шутишь. фрнзи, если что, изначально на базе fbsd была. а потом умерла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

183. Сообщение от Аноним (183), 06-Май-20, 22:29	+/–
Файловая система интересная, но сама стрекоза, к сожалению, не может похвастаться ни стабильностью, ни софтом,ни поддержкой оборудования.Не хватает проекту как финансов, так и разработчиков/мэнтейнеров/пользователей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

184. Сообщение от linuxbuild (ok), 30-Июн-20, 11:53	+/–
Могу подтвердить, что с драйверами во FreeBSD становится лучше. Это видно по добавлению поддержки новых устройств в sys: https://github.com/bsdhw/Drivers/blob/master/freebsd/freebsd... Но чтобы не нарваться на неподдерживаемую плату или компонент, надо как и прежде покупать железо специально для FreeBSD. Найти BSD-совместимые конфигурации можно на сайте https://bsd-hardware.info/
Ответить | Правка | Наверх | Cообщить модератору

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

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