VladikSS, думаю, если глубоко не вдаваться в подробности уязвимости Spectre, данный битый файл получен с помощью этой уязвимости. В кратце про Meltdown и Spectre, при попытке чтения сегментов памяти через кэш cpu, есть некий шанс приближенный к 100% (99.8% например) получить абсолютно идентичный дамп.
Верно. Прошу прощения за невнимательность и спасибо, что нашли ошибку. Человеческий фактор, чтоб его.
Действительно, прирост в производительности небольшой: filling_lesssort x 100: 552.314313408 1 iter avg 5.523143134
filling_lesssort_precalc x 100: 540.896136543 1 iter avg 5.408961365
filling_lesssort_alloc x 100: 497.780295379 1 iter avg 4.977802953
Я сделал некоторые оптимизации, связанные с пропущенным оператором break для условия (a5+b5<n5), логично предположить, что последующие итерации с увеличением b приведут к аналогичному результату.
Это дало ощутимый прирост: filling_lesssort_alloc_break x 100: 159.098596131 1 iter avg 1.590985961
Я провел тест и честно говоря ожидал увидеть цифры порядка нескольких минут. Сказать, что я был приятно удивлен — ничего не сказать. Смотрите сами: repeats: 100
count: 10000
filling_origin x 100: 586.399347237
filling_minopt x 100: 585.032718914
filling_alloc x 100: 533.968311924
filling_lesssort x 100: 0.045311705
filling_lesssort_precalc x 100: 0.054538855
filling_lesssort_alloc x 100: 0.045214453
Я уменьшил количество прогонов для n=10000, но все же это какое-то… «безумие» :)
Насколько я понял, получается, что время заполнения вектора можно не учитывать при больших значениях n и это при одном потоке.
P/S Для сравнения, добавил результаты прогона для n=500 при 100 повторений в список. Так же поправил старые результаты из-за некорректного формата вывода времени.
Да, я это обнаружил сразу после отправки комментария (об этом я отписался в личку, поскольку нет прав на редактирование).
Все же я провел некоторые тесты. В случае с «вывернутым» заполнением время сортировки уменьшается в разы, поскольку происходит меньше перестановок во время сортировки. Плюс немного уменьшил некоторое количество вычислений. С тестом можно ознакомиться по ссылке и рядом лежит файлик с результатами прогона:
https://github.com/theg4sh/experiments/blob/master/filling_loop_sortless.cpp
Если «вывернуть на изнанку» циклы, можно получить сортированный вектор сразу на этапе инициализации.
В этом можно убедиться на примере однострочника на баше:
# с использованием сортировки
for a in $(seq 1 9); do for b in $(seq $(($a+1)) 10); do echo -n "$a^5+$b^5 = "; echo "$a^5+$b^5" | bc; done; done | sort -n -k3
# без использования сортировки
for a in $(seq 2 10); do for b in $(seq 1 $((a-1))); do echo -n "$a^5+$b^5 = "; echo "$a^5+$b^5" | bc; done; done
Я полагаю это может убавить заметное время выполнения.
Да, согласен насчет отслоения, думаю, это происходит из-за плохого контакта с поверхностью. Но я нашел выход: печатаю без прямо на стекле на столе с подогревом, перед печатью наношу на место печати лак для волос Syoss экстрасильной фиксации (другие марки не пробовал в связи с прекрасными показателями этой). За все время еще ни разу ничего не отслоилось, только детали бывает с приличным усилием приходится отдирать от нагретого стола. Что показывает, что лак намного лучшее сцепление по сравнению со каптоновым покрытием. Плюс старое напыление после 5+ печатей отлично смывается под струей воды.
Как термокамера для Prusa i3 отлично подошел перевернутый квадратный журнальный столик из Ikea, обернутый упаковочной пленкой. Как вариант, можно кстати сделать стенки из стеклопластика для эстетики, но это уже, как говорится, на вкус и цвет все фломастеры разные :)
Все здорово, но почему корпус из PLA для потенциально влажного помещения?
Он же имеет свойство впитывать влагу, что в свою очередь может неблагоприятно отразиться на электронике.
Да, и не забудьте удостовериться года через 1,5-2, что корпус все еще в рабочем состоянии:
Не задохнетесь. Не стоит придавать этому событию столь большое значение, я сам иногда ловлю себя на мысли, что выдохнул давно. Предположу это что-то из разряда медитативных процессов. Меньше обращайте внимание на этот механизм — дыхание «работает» без Вашего участия, даже если Вы без сознания.
Поводу «избытков» чего-либо — обратитесь лучше к врачу, проведите с ним анализ крови и другие. Пейте раз в год или полгода комплекс витаминов. Гиктаймс, имхо, не совсем корректное место для подобных вопросов.
splav_asv, спасибо, в курсе. Драйвер amdgpu, имхо, хорошо себя показал. Только неприятный отпечаток все равно остался, да и в силу обстоятельств железку уже обновил.
«Забивательство» AMD (да и других больших кампаний) на устаревшие девайсы, скорее всего, идет со стороны биснеса от вопроса «как стимулировать оборот?» и тут уже ничего не поделать, остается только поддержка сообществом.
Bazanra и правильно сделал что пропатчил.
У них явно что-то не так либо с разработкой, либо с тестированием. Год назад фиксил их драйвер для старенькой видяхи HD7770 под Linux (появились мелкие изменения в api ядра) и смотрю ситуация вообще не изменилась. Фикс был отправлен, но до выпуска официального патча прошло еще полгода.
Именно этот текст вставлять не обязательно.
Все же было бы приятно видедь ссылку в конце поста на соответствующий репорт (хотя бы по тому, что уже нашлось среди «мусора»), согласитесь? По крайней мере для меня, статья выглядела бы полностью законченной в плане текущей истории.
Частенько читаю ваши статьи на хабре и порой выношу для себя полезные вещи (спасибо!), но не могу припомнить ответа на вопрос: «Сообщаете ли Вы мэнтейнерам продуктов о найденных ошибках?»
Логично, что пока работает GPU, CPU может подготовить следующую порцию данных. Для такого объема разумно было бы использовать быстрые алгоритмы сжатия после чтения/перед записью на hdd, постраничная обработка данных и прочие трюки.
Думаю эти два терабайта в сжатом виде могут уменьшиться до 500Гб на диске.
Навеяло на мысль: быть программистом, как иметь раритетный автомобиль — когда ценитель, что смотрит не как на очередную игрушку, но на тот путь которым прошел до момента обладания им.
Очень жаль, что много людей идут в разработчики из-за экономической составляющей и затем уходят из профессии, посчитав ее не интересной или сложной.
Ох, стряхнули пыль с древности… Шел 2013 год.
VladikSS, думаю, если глубоко не вдаваться в подробности уязвимости Spectre, данный битый файл получен с помощью этой уязвимости. В кратце про Meltdown и Spectre, при попытке чтения сегментов памяти через кэш cpu, есть некий шанс приближенный к 100% (99.8% например) получить абсолютно идентичный дамп.
Действительно, прирост в производительности небольшой:
filling_lesssort x 100: 552.314313408 1 iter avg 5.523143134
filling_lesssort_precalc x 100: 540.896136543 1 iter avg 5.408961365
filling_lesssort_alloc x 100: 497.780295379 1 iter avg 4.977802953
Я сделал некоторые оптимизации, связанные с пропущенным оператором break для условия (a5+b5<n5), логично предположить, что последующие итерации с увеличением b приведут к аналогичному результату.
Это дало ощутимый прирост:
filling_lesssort_alloc_break x 100: 159.098596131 1 iter avg 1.590985961
Код лежит там же на github`е
repeats: 100
count: 10000
filling_origin x 100: 586.399347237
filling_minopt x 100: 585.032718914
filling_alloc x 100: 533.968311924
filling_lesssort x 100: 0.045311705
filling_lesssort_precalc x 100: 0.054538855
filling_lesssort_alloc x 100: 0.045214453
Я уменьшил количество прогонов для n=10000, но все же это какое-то… «безумие» :)
Насколько я понял, получается, что время заполнения вектора можно не учитывать при больших значениях n и это при одном потоке.
P/S Для сравнения, добавил результаты прогона для n=500 при 100 повторений в список. Так же поправил старые результаты из-за некорректного формата вывода времени.
Все же я провел некоторые тесты. В случае с «вывернутым» заполнением время сортировки уменьшается в разы, поскольку происходит меньше перестановок во время сортировки. Плюс немного уменьшил некоторое количество вычислений. С тестом можно ознакомиться по ссылке и рядом лежит файлик с результатами прогона:
https://github.com/theg4sh/experiments/blob/master/filling_loop_sortless.cpp
В этом можно убедиться на примере однострочника на баше:
Я полагаю это может убавить заметное время выполнения.
Как термокамера для Prusa i3 отлично подошел перевернутый квадратный журнальный столик из Ikea, обернутый упаковочной пленкой. Как вариант, можно кстати сделать стенки из стеклопластика для эстетики, но это уже, как говорится, на вкус и цвет все фломастеры разные :)
Успехов с умным домом!
Все здорово, но почему корпус из PLA для потенциально влажного помещения?
Он же имеет свойство впитывать влагу, что в свою очередь может неблагоприятно отразиться на электронике.
Да, и не забудьте удостовериться года через 1,5-2, что корпус все еще в рабочем состоянии:
Поводу «избытков» чего-либо — обратитесь лучше к врачу, проведите с ним анализ крови и другие. Пейте раз в год или полгода комплекс витаминов. Гиктаймс, имхо, не совсем корректное место для подобных вопросов.
«Забивательство» AMD (да и других больших кампаний) на устаревшие девайсы, скорее всего, идет со стороны биснеса от вопроса «как стимулировать оборот?» и тут уже ничего не поделать, остается только поддержка сообществом.
У них явно что-то не так либо с разработкой, либо с тестированием. Год назад фиксил их драйвер для старенькой видяхи HD7770 под Linux (появились мелкие изменения в api ядра) и смотрю ситуация вообще не изменилась. Фикс был отправлен, но до выпуска официального патча прошло еще полгода.
Все же было бы приятно видедь ссылку в конце поста на соответствующий репорт (хотя бы по тому, что уже нашлось среди «мусора»), согласитесь? По крайней мере для меня, статья выглядела бы полностью законченной в плане текущей истории.
P.S. Да, виноват, под кат не заглянул.
Думаю эти два терабайта в сжатом виде могут уменьшиться до 500Гб на диске.
Очень жаль, что много людей идут в разработчики из-за экономической составляющей и затем уходят из профессии, посчитав ее не интересной или сложной.