Свежие комментарии
| Title | Comment |
|---|---|
| надо еще помнить что у DxO |
надо еще помнить что у DxO графики по Ssat ISO, a у клаффа по номинальному... и он упорно отказывается уравнятъ... так что сравнивая разных производителей у клаффа (да и мб разные модели одного и того же в некоторых случаях) надо помнить что по горизонтали там не одно и тоже... |
| Кадрирование гуляет конечно |
Кадрирование гуляет конечно от кадра к кадру, но реально проблем не создает. Чисто визуально, на уровне исходников, больше напрягает изменения масштаба на разных дистанциях фокусировки, а заодно и экспозиция скачет (ближние кадры в серии темнее). Наличие макрорельс спасло бы, но в принципе и так обхожусь. Но при сращивании всё это правится программой и так на автомате, пользуюсь Zerene Stacker, там несколько алгоритмов сшивки, один прям хорош и без ручной ретуши. Сшивка в фотошопе в этом плане очень примитивна, косяк на косяке, существует для галочки наверно. Сам фоткаю для стоков (единичные объекты типоразмера фруктов-ягод), полноразмеры вполне неплохо выглядят. |
| По моему вот опыту, сбить при |
По моему вот опыту, сбить при этом ("на пиксель-другой") даже с жесткого штатива - ну совсем легко. Я вот приспособился по шкале у Batis - там DOF динамически пересчитывается от диафрагмы, но сбивается временами. |
| А я всё по старинке снимаю на |
А я всё по старинке снимаю на 5dm2 крутя фокус на глаз через лайввью, в общем не жалуюсь) |
| Ну таки да. С одной стороны. |
Ну таки да. С одной стороны. |
| Вообще это какой-то рак мозга |
Вообще это какой-то рак мозга производителей. |
| Вот по первой ссылке пишут: |
Вот по первой ссылке пишут: We added linker checks, so that mismatching VS 2010+ major versions will trigger hard errors at link time, Вот что я могу сказать: v120_xp + v100 (смешаны именно "библиотеки", т.е. .obj) - полет нормальный. |
| Рантайм определяется списком |
Рантайм определяется списком библиотек, с которыми мы линкуемся (а они, в свою очередь, определяются ключами командной строки, использованными при компиляции: /MT или /MD). Если линковаться с msvcrt.lib/msvcprt.lib, то результат потребует того рантайма, который прописан в этих библиотеках. Если линковаться с libcmt.lib/libcpmt.lib, то рантайм вообще не потребуется. В обоих случаях успешность линковки и работоспособность результата не гарантированы, особенно если используется C++ (см. https://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_libsdlls_be_li...). Да, в MSVC2015 названия библиотек изменились, а 2017 вроде бы совместим по ABI с 2015. Что касается clang'а - см. https://clang.llvm.org/docs/MSVCCompatibility.html: "First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code should be able to link against MSVC-compiled code successfully. However, ...". |
| Но и с чисто сишным |
Но и с чисто сишным интерфейсом снаружи (но ++ внутри) вот я бы боялся, что clang-овский тулсет захочет clang-овского же рантайма для всех этих std:: (и аналогично v120_xp не совместим в этом месте v100) |
| Плюсовый интерфейс. Включая |
Плюсовый интерфейс. Включая std::*stream, то есть в ваших терминах "STL" |
| А интерфейс у библиотек при |
А интерфейс у библиотек при этом - C++ с использованием STL, или чистый C? Во втором случае - чего бы ему не работать? А вот в первом - вроде бы не должно быть совместимости. |
| А не знаю. |
А не знаю. |
| autoconf, пожалуй, еще похуже |
autoconf, пожалуй, еще похуже будет. Я использую qmake как мета-описатель процесса сборки, но |
| cmake сотоваришчи |
"а про то мы не знаем // и не жаждем узнать" (c) на самом деле, очень понимаю, и как и что выбирать нонеча для кросс-компиляции в не самых прямолинейных случаях -- вот аааще непонятно, ОБА ХУЖЕ!!! |
| Ну решили что оверхед меньше |
Ну решили что оверхед меньше 50% - не оверхед :) |
| А если primarycache=all, то |
А если primarycache=all, то тогда точно нет никакого смысла в recordsize=64k (особенно для бекапов). Кстати, недавно узнал, что если размер файла меньше recordsize, то размер записи добивается до ближайшего кратного ashift. А вот если больше recordsize, то последняя recordsize уже не обрезается. Для меня пока не понятна сия логика :-). |
| Спасибо. Я пока оставил в |
Спасибо. Я пока оставил в претендентах 950-960 самсунг и M8PeY :-) (правда ещё соблазняет по сходной цене почти новый Intel 750). После чтения обзоров беспокоит нагрев и возможный троттлинг, особенно у M8PeY. У меня пока главные критерии выбора - скорость записи на уже заполненном ssd и производительность при смешанной нагрузке. Хочу ещё посмотреть как, L2ARC освобождает место под новые записи после полного заполнения. Заметил у тебя пишет и читает в среднем почти по 128kB, значит пишет в основном данные. А у меня слабое место промахи метадаты. Вот и родилась идея загнать всю её L2ARC :-). Получается если будет сжатие, то средний размер записи может быть сильно меньше. |
| Я сейчас и не вспомню почему |
Я сейчас и не вспомню почему поменял, но кажется совсем уж без кэша получается совсем уж медленно (не столько акронисом, там ок, сколько тайм-машинами маковскими, хотя они ходят всего-то по гигабиту) |
| Не было проблем. Но эта штука |
Не было проблем. Но эта штука покупалась ровно под L2ARC, никаких других файловых систем там нет и не планировалось. Загрузка тоже не с нее. "на что обратить внимание" я, честно говоря, не знаю, потому что у меня это вот единственный nvme под FreeBSD, он сразу завелся и стало хорошо. Эксплуатация - ну скажем месяца три активных (минус лето, когда на эти тома никто не писал), за это время записано - 10Tb (т.е. 20 раз перезаписан). Заявленный ресурс - кажется 400Tb, то есть даже формального ресурса хватит, при таком же использовании, на ~10 лет. |
| Разумно :-). |
Разумно :-). |
| Новые файлы. |
Новые файлы. Вот надо таки прочитать исходники zfs-mon, тогда будет понятно какие переменные оно так обзывает |
| primarycache=all |
Сегодня обратил внимание. Ты же вроде боролся с вымыванием кеша? И ещё - если затем следует верификация, то часть данных может быть прочитана из кеша. Тогда какой смысл в верификации? |
| Если честно, то я не совсем |
Если честно, то я не совсем понимаю что такое ZFETCH (только догадываюсь :-)). miss может быть только у чтения. А запись новых файлов или поверх старых? |
| Меня вот больше интересует, |
Меня вот больше интересует, что такое ZFETCH miss при записи. |
| Неправильная интерпретация |
Сегодня на свежую голову ещё раз глянул и понял, что моя интерпретация статистики префетча была неверна. Для понимания прочитал файл в 262144 рекордсайз (файл точно читался первый раз) и вычленил статистику: CACHE MISSES BY DATA TYPE: Получается CACHE MISSES чесно показал, что данных в кеше не было (170 + 261974=262144) и префетч послал 99,9% запросов. А вот с CACHE HITS поинтереснее :-). Получается, если запрос от приложения пришёл в ARC, когда ещё выполнялся запрос префетча, то хит не начисляется, а если рекордсайз уже была к этому времени прочитана, то начисляется. Prefetch Data: 2 - списываю на то, что на пуле в это время был ещё один не очень активный пользователь. В итоге получается, что первое чтение файла дало в статистику (только по данным) 100% MISSES и 75% HITS от размера файла :-). По метаданным понятно, что хитов было значительно больше. И кстати, у меня Data Prefetch Efficiency ещё меньше, чем у тебя :-), что теперь тоже вполне объяснимо. |
| Тогда всё попадает в ARC и до |
Тогда всё попадает в ARC и до выталкивания просто не используется. Нет, наверно нужно всё таки проверить, по какому алгоритму работают счётчики предвыборки. |
| У меня тоже есть датасет |
У меня тоже есть датасет /backup c primarycache=metadata. На машине только ARC ограниченный 14GB. Файловая упреждающая выборка включена (правда я туда только каждый час сбрасываю), но подобной картинки не наблюдаю. ZFS Subsystem Report Tue Aug 15 17:03:09 2017 ------------------------------------------------------------------------ ARC Efficiency: 232.33m Data Demand Efficiency: 97.05% 28.92m CACHE HITS BY CACHE LIST: CACHE HITS BY DATA TYPE: CACHE MISSES BY DATA TYPE: (лучше конечно моноширинным) |
| primarycache=all |
primarycache=all |
| ZFETCH hits: 0 0 0 0 |
Я не пользуюсь zfs-mon и сразу не соображу, что это значит. Нужно будет посмотреть. Но если при primarycache=metadata происходит файловая упреждающая выборка (интересно куда и зачем?), а затем её результат сразу выбрасывается, то это похоже на баг :-). Вечером постараюсь проверить. |
| А вот верификация для бэкапа, |
А вот верификация для бэкапа, который сделали на recordsize=64k (отчего скорость верификации упала и верну я обратно 1m): ZFS real-time cache activity monitor
Seconds elapsed: 155
Cache hits and misses:
1s 10s 60s tot
ARC hits: 2491 2696 2772 2706
ARC misses: 2283 2595 2643 2573
ARC demand data hits: 2224 2549 2613 2542
ARC demand data misses: 21 19 19 19
ARC demand metadata hits: 17 18 17 16
ARC demand metadata misses: 0 0 0 0
ARC prefetch data hits: 246 125 138 145
ARC prefetch data misses: 2262 2576 2623 2554
ARC prefetch metadata hits: 4 4 4 4
ARC prefetch metadata misses: 0 0 0 0
L2ARC hits: 0 0 0 0
L2ARC misses: 2283 2595 2643 2573
ZFETCH hits: 1295 1536 1561 1524
ZFETCH misses: 1190 1313 1348 1314
VDEV prefetch hits: 0 0 0 0
VDEV prefetch misses: 0 0 0 0
Cache efficiency percentage:
10s 60s tot
ARC: 50.95 51.19 51.26
ARC demand data: 99.26 99.28 99.26
ARC demand metadata: 100.00 100.00 100.00
ARC prefetch data: 4.63 5.00 5.37
ARC prefetch metadata: 100.00 100.00 100.00
L2ARC: 0.00 0.00 0.00
ZFETCH: 53.91 53.66 53.70
VDEV prefetch: 0.00 0.00 0.00
на этом разделе - secondarycache=metadata. |
Pages
