| 1.1, oops (ok), 17:55, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
 Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется
| | |
| |
| 2.2, anonimchiikun (?), 18:02, 29/11/2013 [^] [^^] [^^^] [ответить]
| +16 +/– |
У меня такое чувство, что патч не может быть под какой-либо другой лицензией, кроме материнской.
| | |
| |
| 3.3, annulen (ok), 18:11, 29/11/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Патч может. Правда в этом случае его вряд ли возьмут в апстрим.
| | |
| 3.27, oops (ok), 02:02, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Еще как может, gcc как пример, там куча патчей под разными лицензиями
| | |
| 3.37, linux must __RIP__ (?), 14:21, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
может. Как показала практика - разработчики Linux ядра могут взять исходники под BSDL потом наложить патчи под GPL и отказаться отдавать изменения в upstream мотивируя что они не хотят лицензировать свои изменеия под BSDL.
| | |
| |
| 4.45, Аноним (-), 21:28, 01/12/2013 [^] [^^] [^^^] [ответить]
| +/– |
И всё правильно. Включали в ядро код одни люди, писали патчи совсем другие. И эти другие совсем не обязаны писать патчи под BSDL, это их выбор.
| | |
|
|
| 2.9, Аноним (-), 18:36, 29/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется
А мы не задолбаемся таким макаром? Особенно в новостях про линевый кернел? А то патчей бывает много разных. Но вообще-то обычно патчи не меняют лицензию проекта. Если это не так - вот тут уже стоит написать в новости, да :).
| | |
| 2.10, Аноним (-), 18:36, 29/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется
Под лицензией zlib, наверное. Под какой же еще?
| | |
|
| |
| 2.12, Аноним (-), 18:37, 29/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Судя по всему, только на процессорах Intel? Или я просто К.О...
Понятно что интел оптимизил под себя, но SSE2/SSE4.2 есть не только у них.
| | |
| |
| 3.31, тоже Аноним (ok), 10:50, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Вопрос в том, ограничились ли они применением только тех оптимизаций, которые есть не только у них. Достаточно один раз обратиться к Intel-only логике, чтобы весь патч уже был непригоден для amd64.
Или просто рассчитывать исключительно на топ, игнорируя свои же старые модели. В отстающем AMD сразу отваливается большая часть моделей. Судя по списку ниже, так и сделано.
| | |
|
| 2.26, ADMIN (?), 02:00, 30/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Intel
- Westmere processor (March 2010).
- Sandy Bridge processor
- Ivy Bridge processor
- Haswell processor
AMD:
- Bulldozer processor (2011).[5]
- Piledriver based processors (including newer AMD A-series APUs)
The presence of the CLMUL instruction set can be checked by testing one of the CPU feature bits.
| | |
|
| 1.6, 3draven (ok), 18:28, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
 Что то патчи сыпятся как из рога изобилия. Судя по всему, началось настоящее освоение возможностей многоядерных современных процессоров...я так ждал, так ждал :)
| | |
| |
| 2.11, Аноним (-), 18:37, 29/11/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> настоящее освоение возможностей многоядерных современных процессоров...
Интересно, где там многоядерность? Скорее, новые наборы команд освоили. Но тоже хорошо. А чего они просто так в железе место занимают? :)
| | |
| |
| 3.16, 3draven (ok), 18:54, 29/11/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
Ну, в этой новости не было, но было в других с патчами "офигенной производительности"...судя по всему разрабы перешли таки в век 21 :)
| | |
|
| |
| 3.38, burjui (ok), 18:30, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Будет весело, когда мы окончательно упрёмся в ограничения физики и больше не сможем наращивать мощь железа. Разработчики будут вынуждены заниматься оптимизацией, и, быть может, мы даже застанем софт, который с каждой новой версией будет работать быстрее на том же железе. А то сейчас такая мода - поставить проц пожирнее да памяти побольше, когда софт работает слишком медленно.
| | |
| |
| 4.46, fi (ok), 22:48, 01/12/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > когда мы окончательно упрёмся в ограничения физики
тогда мы перейден на новый уровень игры :))
зы. я лет 20-ть назад делал моделирование кристалла с переменный порогом уровней (что дает кристалл с примесями ) - электрон просто летал :))) Пишут что IBM уже тестируем образцы.
| | |
|
|
|
| |
| 2.13, Аноним (-), 18:42, 29/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> а смысл уже использовать zlib
Веб-сервера, веб-браузеры (deflate).
| | |
| |
| 3.23, apollo2k4 (ok), 23:17, 29/11/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
 К.О. намекает, что для этого эти патчи не предназначены т.к. увеличена скорость, но уровень сжатия снизился…
| | |
|
| 2.14, Аноним (-), 18:47, 29/11/2013 [^] [^^] [^^^] [ответить]
| +18 +/– | |
> а смысл уже использовать zlib, когда lz4 в ядре?
Капитан намекает, что самокат, фургон и боинг имеют разные области применения.
LZ4 - "максимально быстрый компрессор". Там никто не заморачивается степенью сжатия - "как-то жмет". Зато "очень быстро". Это одностадийный LZ, простой как топор и быстрый как ракета. Он на современном компьютере может достигать скоростей в сотни Мб/сек и даже Гб/сек на поток. Это позволяет ему жать например данные на диске и при этом еще и выигрывать в скорости записи/чтения, несмотря на, казалось бы, добавочную работу.
Zlib - середнячок. Он не мегатормоз но и не чемпион по скорости. Жмет тоже средне. После lempel-ziv'а прикручен huffman, так что за счет дожатия хаффманом он при прочих равных имеет шансы сжать лучше чем LZ без нифига типа LZ4. Но т.к. это дополнительная стадия - сжатие и распаковка будут разумеется медленеее.
Ну а если нам надо будет тяжеловеса - мы вообще позовем LZMA. Этот жмет весьма конкретно. Но медленнее, особенно на сжатие (у LZ-based есть асимметрия, тормознуть декомпрессию сложно, а вот компрессор при желании может довольно долго сопли жевать, выискивая наилучшие совпадения из всех возможных).
| | |
| |
| 3.39, bircoph (ok), 18:31, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Ну а если нам надо будет тяжеловеса - мы вообще позовем LZMA. Этот жмет весьма конкретно. Но медленнее, особенно на сжатие (у LZ-based есть асимметрия, тормознуть декомпрессию сложно, а вот компрессор при желании может довольно долго сопли жевать, выискивая наилучшие совпадения из всех возможных).
Нет, это ещё не тяжеловес, так, чуть выше среднего. Если нужно действительно сильное сжатие, есть paq8l -9. Логи и XML жмёт в 2 раза эффективнее xz -9e, но кушая очень много RAM и CPU, причём скорость распаковки равна скорости сжатия.
Матан семейства PAQ посмотреть можно тут: http://en.wikipedia.org/wiki/PAQ
Там адаптивные алгоритмы и нейронки.
| | |
| |
| 4.41, pavlinux (ok), 19:33, 30/11/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
 $ paq8 -8 DATA.rnd
Creating archive DATA.rnd.paq8l with 1 file(s)...
DATA.rnd 4194304 -> 4197134
4194304 -> 4197164
Time 446.99 sec, used 1643022601 bytes of memory
Архив стал больше исходного, аж на 2860 байт!
Процесс сжатия файла размером 4 мегабайта занял 7.5 минут!!!
При этом сожрав 1.5 гигабайта оперативки!!!
Кому он, такой красивый, нужен? :D
| | |
| |
| 5.48, Аноним (-), 16:58, 02/12/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Кому он, такой красивый, нужен? :D
Это переложение анекдота "про суровых сибирских лесорубов и новую японскую бензопилу" на опеннетовскую тематику?
| | |
| 5.52, Гентушник (ok), 14:28, 07/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > paq8 -8 DATA.rnd
Вы случайно жали не набор рандомных байт?
Чёрт, я год перепутал. Привет вам из 2016-ого!
| | |
|
|
|
| 2.28, Led (ok), 02:46, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > а смысл уже использовать zlib, когда lz4 в ядре?
А смысл в lz4, когда lzo давным давно в ядре и он ничем не хуже lz4 (а lz4hc - значительно тормознее)?
| | |
|
| 1.8, Аноним (-), 18:35, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
С ухудшением сжатия не нужно. Но вообще штука очень полезная например при рендеринге карт openstreetmap, где нужно сжимать 100500 png'шек.
| | |
| |
| 2.15, Аноним (-), 18:49, 29/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> С ухудшением сжатия не нужно.
Когда заказывают fastest сжатие - степень сжатия явно не в приоритете, так что некоторый пойнт в таком решении есть.
| | |
| |
| 3.18, Аноним (-), 19:46, 29/11/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
А случаем никто не объяснит как получилось так, что оптимизация повлияла на степень сжатия? Получается, что изменился алгоритм.
| | |
| |
| 4.22, Аноним (-), 23:01, 29/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
> А случаем никто не объяснит как получилось так, что оптимизация повлияла на
> степень сжатия? Получается, что изменился алгоритм.
Сгенерировать один и тот же формат потока можно бесконечным количеством способов. А разогнать любой LZ можно путем более раннего забивания на поиск совпадений, например. При том на fastest методе сжатие такое ничем особо и не плохо, если кто просил побыстрее - значит ему нагрузка на проц и/или скорость работы была важнее.
| | |
| |
| 5.30, Fracta1L (ok), 10:10, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Сгенерировать один и тот же формат потока можно бесконечным количеством способов.
пруф?
| | |
| |
| 6.34, www2 (ok), 11:01, 30/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Не нужно цепляться к словам. Не бесконечным, конечно, но довольно большим.
| | |
| 6.42, pavlinux (ok), 19:53, 30/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Сгенерировать один и тот же формат потока можно бесконечным количеством способов.
> пруф?
Моск?
2 - 1 = 1,
3 - 2 = 1
49999999999999999999999999 - 49999999999999999999999998 = 1
...
| | |
|
|
| 4.32, тоже Аноним (ok), 10:58, 30/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Элементарно: если алгоритм рассчитан на работу с байтиками, а процессор вполне оптимально ворочает сразу бОльшими блоками, то переориентация на эти блоки ускорит работу, но ухудшит результат.
| | |
| 4.47, Аноним (-), 14:31, 02/12/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если в новости не слепили кислое с зеленым, то, видимо, какой-то сайд-эффект уменьшения точности работы с вещественными числами от перехода на новые инструкции.
В SSE регистры 64-разрядные против 80-тиразрядных традиционных - это само по себе съедает точность, но можено выставить и еще меннее качественную (и более быструю) математику.
| | |
| |
| 5.50, XoRe (ok), 18:33, 05/12/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > В SSE регистры 64-разрядные против 80-тиразрядных традиционных
<sarcasm> вот где "проигрыш примерно на 30%"! </sarcasm>
| | |
|
|
|
|
| 1.19, gegMOPO3 (?), 20:52, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%
Они офигели? Почему бы честно не взять уровень сжатия на единицу меньше?
| | |
| |
| 2.20, Аноним (-), 21:55, 29/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Почему бы честно не взять уровень сжатия на единицу меньше?
Больше даже похоже на "а почему они не попробовали при произведении измерений включить сжатие?"
| | |
| 2.21, Аноним (-), 22:58, 29/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Почему бы честно не взять уровень сжатия на единицу меньше?
... при том что это уже и так fastest? :)
| | |
| 2.25, Серж (??), 01:28, 30/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Зато
Level 9 is about 22% faster with no change in compression.
Level 6 is about 50% faster with negligible change in compression.
| | |
|
| 1.24, Zenitur (ok), 01:13, 30/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > в режиме высокой скорости сжатие стало на 71% быстрее (правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%)
Да я и на AMD могу ускорить сжатие в ущерб размеру архива.
| | |
| |
| 2.33, тоже Аноним (ok), 10:59, 30/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Да я и на AMD могу ускорить сжатие в ущерб размеру архива.
Вы можете сделать это для каждой команды deflate по всем серверам мира?
(А Интел - может ;) )
| | |
| |
| 3.43, Anonymous1 (?), 12:43, 01/12/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Да я и на AMD могу ускорить сжатие в ущерб размеру архива.
> Вы можете сделать это для каждой команды deflate по всем серверам мира?
> (А Интел - может ;) )
Все сервера мира вовсе не обязательно на процессорах Intel...
| | |
|
|
| 1.44, pavlinux (ok), 16:14, 01/12/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Под какаю версию патчи? Кто уже юзал? Иль как всегда - попердели в лужу и разбежались?
| | |
| |
| 2.49, pavlinux (ok), 18:07, 02/12/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>Иль как всегда - попердели в лужу и разбежались?
Судя по минусу, всё ясно. :D
Ну так вот, на git версию, и на 1.2.8 не накладываются, ~ 90% FAILED, остальные hunk offset.
В ручную идейно не буду править.
| | |
|
|
