Обнаружил, что падение производительности вызывает та самая загадочная замена i*2 на rotl(i,1U)
Во вторых, да, все вот так просто. Как-бы в мире существует не одна «железка», их множество и на каждой все по разному работает. Поэтому оставьте i*2, компилятор сам сделает что нужно (только если вы заранее не компилируете). А что до «упавшей» скорости, возможно вы что-то не то сделали.
А i изменяется в пределах от 0 до 3, значит у нас еще 29 «лишних» бит и за пределы регистра мы не выйдем ну никак.
Это не отменяет того, что это ошибка, а про «выход за пределы» я говорил о простом сдвиге. Если уж так хотели «заоптимизировать», написали бы i<<2.
Во первых, rotl() это циклический сдвиг и работает он медленее чем обычный сдвиг (в который оптимизируется i*2).
Во вторых, как это вы так заменили? Это же ошибка! Если у вас слева будет единица, то она появится справа. Конечно, если такое значение умножить на 2 будет выход за пределы регистра и установкой Флага Переноса, но ошибка от этого не перестает быть ошибкой!
Не знаю что там у товарищей с Ubuntu, но когда я начинал (если не считать что-то серьезное), а была это OpenSUSE, у меня проблем не было. Там есть Yast2 в котором можно настроить все что хочешь, а так-же он есть в ncurses варианте, если оно нужно в терминале.
Нет, конечно были проблемы с проприетарными драйверами, т.к. я их ставил не с репозитория, а с *.run файла, но когда я нашел и распечатал инструкцию проблемы тут-же исчезли.
Помнится я таким образом купил Portal и решил его «активировать»… в итоге только через несколько лет (с появлением широкополосного доступа) понял, что когда я указал ключ в Steam я не с диска ставил, а с интернета. А способ установки с диска узнал чисто случайно, т.к. если запустить «setup.exe» он сначала Steam ставит, а у меня он не стоял и я думал что это установщики Steam, а файлы с диска он сам подхватит при активации.
Потестил я Snappy. Опять-же, скорость не выросла, а наоборот ухудшилась (по сравнению с LZO1X). Скорее всего это из-за того, что файлы получаются гораздо, гораздо более объемными и скорость сжатия/декомпрессии просто теряется на фоне скорости I/O операций.
Это не отменяет того факта, что generic VFS не очень, поэтому лично я эту позицию полностью поддерживаю.
Да и потом, смысл включать код в ядро? Была бы Namesys, то Reiser4 пилили и поддерживали и без этого. Эдуард Шишкин в интервью об этом упоминал:
хочу сказать, что не понимаю навязчивую идею «путёвки в жизнь», якобы даваемой включением проекта в основную ветку ядра Линукс. Reiser4 — это результат 18-летних исследований в области хранения данных, не привязанный к конкретной операционной системе. Результат, над которым работало много ученых.
От включения в основную ветку внезапно не появятся люди, которые будут писать/править/тестировать код. Тем-же BFS, BFQ или TuxOnIce вполне хорошо живется и вне основной ветки.
все проблемы из знаменитого «списка для включения»
Это так-же включает в себя дублирование кода, которое написал Райзер. Но стоит отметить, Ганс Райзер написал свое из-за того, что оно работало медленнее и вообще было архаичным. А Линус, Мортон, Кокс и остальные просто взяли и уперлись.
Собственно эти вопросы обсуждались еще в те времена, когда Namesys еще существовала: [1, 2].
Добавили не в ZFS, а в Illumos. Соответственно в ZFSOnLinux он появился от туда.
Ну я в статье и написал, что конкретно в ZFS, по сравнению с lzjb, оно выиграет, но добавили бы они туда LZO1X было бы еще лучше.
Мысль здравая, но все равно пришлось бы давать ссылки на информацию, т.к. описать dancing trees, tail packing и т. д. простым описанием, не представляется возможным.
С официального сайта Namesys.
На данный момент сайт не работает, т.к. Namesys лишилась финансирования и закрылась (после ареста Ганса Райзера), поэтому только через WebArchive.
Во вторых, да, все вот так просто. Как-бы в мире существует не одна «железка», их множество и на каждой все по разному работает. Поэтому оставьте i*2, компилятор сам сделает что нужно (только если вы заранее не компилируете). А что до «упавшей» скорости, возможно вы что-то не то сделали.
Это не отменяет того, что это ошибка, а про «выход за пределы» я говорил о простом сдвиге. Если уж так хотели «заоптимизировать», написали бы i<<2.
Во первых, rotl() это циклический сдвиг и работает он медленее чем обычный сдвиг (в который оптимизируется i*2).
Во вторых, как это вы так заменили? Это же ошибка! Если у вас слева будет единица, то она появится справа. Конечно, если такое значение умножить на 2 будет выход за пределы регистра и установкой Флага Переноса, но ошибка от этого не перестает быть ошибкой!
Стоять, как это «неограниченное количество»? Там ограничение в 128 разделов. Даже на схеме это хорошо видно.
Нет, конечно были проблемы с проприетарными драйверами, т.к. я их ставил не с репозитория, а с *.run файла, но когда я нашел и распечатал инструкцию проблемы тут-же исчезли.
Вообще-то кластерные системы настраиваются сисадминами, а профессора используют MPI. Точнее это делают специально обученные люди.
Да и потом, смысл включать код в ядро? Была бы Namesys, то Reiser4 пилили и поддерживали и без этого. Эдуард Шишкин в интервью об этом упоминал:
От включения в основную ветку внезапно не появятся люди, которые будут писать/править/тестировать код. Тем-же BFS, BFQ или TuxOnIce вполне хорошо живется и вне основной ветки.
Это так-же включает в себя дублирование кода, которое написал Райзер. Но стоит отметить, Ганс Райзер написал свое из-за того, что оно работало медленнее и вообще было архаичным. А Линус, Мортон, Кокс и остальные просто взяли и уперлись.
Собственно эти вопросы обсуждались еще в те времена, когда Namesys еще существовала: [1, 2].
Ну я в статье и написал, что конкретно в ZFS, по сравнению с lzjb, оно выиграет, но добавили бы они туда LZO1X было бы еще лучше.
На данный момент сайт не работает, т.к. Namesys лишилась финансирования и закрылась (после ареста Ганса Райзера), поэтому только через WebArchive.