Я думал над этим, но пока не рискнул. В родных креплениях используются шайбы, которые держатся в соотв пазах, т.е. нагрузка на корпус передается не столько через периметр болта, сколько через периметр шайбы, через большую площадь. На просверленных отверстиях теперь будет сконцентрирована вся нагрузка, как бы не пошли трещины…
Не думаю, что Ваши ноги поднимают в прыжке 14кг колесо на высоту в 5-10см. Вы то подпрыгиваете, но колесо все же взбирается своими силами. И сделать оно это должно за долю секунды. Придать ускорение 14 килограммам за такое короткое время можно, но приложив большую силу, для чего нужно прогнать большой ток.
20кг у V10, где они покупателей на таких монстров находят? )
V8 очень достойное колесо, если бы фонарик перенесли повыше и увеличили зазор между шиной и корпусом (если шину докачать до номинала, то слышно как трутся прилипшие песчинки о корпус) — было бы вообще идеальное )
«маятник» (вперед-назад) не ловил, но пару раз на скорости случалось «биение», когда колесо болтает влево-вправо, два раза даже упал ((
По моим наблюдениям, «биение» более склонно проявляться на полностью накачаной, и особенно на узкой, шинах. А шину пошире поставить никак — нет места ((
В реализации REP MOVSB были проведены улучшения (начиная с Haswell), так что есть смысл его потестировать.
Возможно, стоит весь декодер сделать на асме, максимально просто и дубово. Выравнивание в данном случае практически всегда отсутствует, и пытаться вручную оптимизировать смещения инструкций чтения — гиблое дело, имхо. 256-битные инструкции на таких случайных данных будут проигрывать из-за частого пересечения границы строки кеша.
Ну вот не скажите
Операция копирования используется очень часто, и городить кучу разных реализаций, для SSE1/2/3, AVX и т.д. и т.п., выжимая проценты производительности (и теряя их в других местах), внося потенциальные баги и дырки — разве это лучше, чем иметь пару-тройку специальных инструкций, которые раз и навсегда закроют вопрос максимально эффективного копирования для всех вариантов процессоров?
1/3 и 1/2 — это ответы на разные вопросы, поэтому они и отличаются друг от друга.
1/3 это вероятность выборки одного человека без брата/сестры из всех людей обоих вариантов рождения (без пары и с парой)
1/2 это вероятность выпадения конкретного решения (иметь одного или двух детей) для конкретного моряка (ну и для его ребенка или детей тоже, смотря что там выпадет).
Поэтому, если вы существуете, то существуете в бесконечном количестве копий.
Опровергается очень просто — представим себе бесконечный лист бумаги в клеточку, все клеточки разноцветные, и одна — белая. Ошибочно делать вывод, что белых клеток бесконечное количество, хотя такое и возможно реализовать в принципе для данного листа.
Почти переносимый )
__uint128_t это не стандартный тип — он даже в C/C++ не во всех компиляторах поддерживается (попробуйте clang, например), не говоря о других языках, таких как java, go…
И далеко не во всех процессорах есть инструкции широкого умножения (из двух слов в одно двойное слово), а ведь переносимый хеш должен быстро работать и на таких процессорах, иначе какой же он 'dream fast'
И ни строчки про то, как конкретно, собственно, эта функция устроена (
А вообще скорость хеширования определяется двумя параметрами — скоростью потоковой обработки и задержкой на одну транзакцию (что эквивалентно максимальному кол-ву хешей в секунду). Первая решает при обработки больших кусков данных (контрольные суммы, системы дедупликации...), но при обработке целых чисел фиксированного размера скорость определяется вторым параметром. Скажем, в математическом алгоритме, где используется map[uint32]uint32, лучше использовать тот же mmh3_x64
Причем быстрый алгоритм потоковой обработки (накопления энтропии) зачастую можно адаптировать к другим хешам (с маленькой задержкой транзакции), получив ещё более производительную функцию ). И наоборот — можно к быстро накопленной энтропии применить криптографический алгоритм — и получить ультрабыстрый (в потоковом смысле) но и криптостойкий хеш.
Есть ещё 197 Current_Pending_Sector — сектора которые не получается прочитать (чек-сумма не сходится), но которые ещё не переназначены (а вдруг когда-то прочитается).
Их можно перезаписать поверху, после этого такой сектор может начать работать нормально (или будет переназначен, если ему кранты), а может и дальше заглючить в самый неподходящий момент.
Просто обозначу минусы такого решения
1. Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT, директории…
2. Остается риск работы головки в поврежденном цилиндре, вызывая дальнейшую деградацию диска (расширяя задир, например).
Если уж так сильно охота использовать потенциально дохлый винт — правильно будет определить дефектную зону, покрыть её отдельным дисковым разделом с запасом в несколько десятков ГБ (минимум), который не форматировать и никак не трогать — тогда может быть винт и поживет какое-то время, если повезет.
Столкнулся было с вариантом N2 (Фокстрот, не Moyo) — покупал эпилятор со скидкой, так в чек добавили какой-то сборник рецептов на Android, как раз в цену скидки )
Возврат приняли без пререканий…
Только забыли упомянуть, что это при заряде в 4.5С )
Имхо, работа заслуживает серьезной критики — делать выводы по шести точкам на графике это пальцем в небо.
Более того, есть график, показывающий практически идентичность токов разряда и заряда при 18% начальном расхождении во внутреннем сопротивлении.
Получается, что при параллельном подключении аккумуляторов потребление энергии будет выровнено — каждый отдаст сколько нужно, чтобы его ЭДС сравнялся с ЭДС остальных аккумуляторов. А при параллельной зарядке каждый аккумулятор возьмет свою долю согласно емкости, без всякого рассогласования.
V8 очень достойное колесо, если бы фонарик перенесли повыше и увеличили зазор между шиной и корпусом (если шину докачать до номинала, то слышно как трутся прилипшие песчинки о корпус) — было бы вообще идеальное )
«маятник» (вперед-назад) не ловил, но пару раз на скорости случалось «биение», когда колесо болтает влево-вправо, два раза даже упал ((
По моим наблюдениям, «биение» более склонно проявляться на полностью накачаной, и особенно на узкой, шинах. А шину пошире поставить никак — нет места ((
Раздел 11.16.3 Data Movement Considerations
В реализации REP MOVSB были проведены улучшения (начиная с Haswell), так что есть смысл его потестировать.
Возможно, стоит весь декодер сделать на асме, максимально просто и дубово. Выравнивание в данном случае практически всегда отсутствует, и пытаться вручную оптимизировать смещения инструкций чтения — гиблое дело, имхо. 256-битные инструкции на таких случайных данных будут проигрывать из-за частого пересечения границы строки кеша.
Операция копирования используется очень часто, и городить кучу разных реализаций, для SSE1/2/3, AVX и т.д. и т.п., выжимая проценты производительности (и теряя их в других местах), внося потенциальные баги и дырки — разве это лучше, чем иметь пару-тройку специальных инструкций, которые раз и навсегда закроют вопрос максимально эффективного копирования для всех вариантов процессоров?
1/3 это вероятность выборки одного человека без брата/сестры из всех людей обоих вариантов рождения (без пары и с парой)
1/2 это вероятность выпадения конкретного решения (иметь одного или двух детей) для конкретного моряка (ну и для его ребенка или детей тоже, смотря что там выпадет).
Хотя маркетингом, похоже, все те же люди занимаются )
__uint128_t это не стандартный тип — он даже в C/C++ не во всех компиляторах поддерживается (попробуйте clang, например), не говоря о других языках, таких как java, go…
И далеко не во всех процессорах есть инструкции широкого умножения (из двух слов в одно двойное слово), а ведь переносимый хеш должен быстро работать и на таких процессорах, иначе какой же он 'dream fast'
А вообще скорость хеширования определяется двумя параметрами — скоростью потоковой обработки и задержкой на одну транзакцию (что эквивалентно максимальному кол-ву хешей в секунду). Первая решает при обработки больших кусков данных (контрольные суммы, системы дедупликации...), но при обработке целых чисел фиксированного размера скорость определяется вторым параметром. Скажем, в математическом алгоритме, где используется map[uint32]uint32, лучше использовать тот же mmh3_x64
Причем быстрый алгоритм потоковой обработки (накопления энтропии) зачастую можно адаптировать к другим хешам (с маленькой задержкой транзакции), получив ещё более производительную функцию ). И наоборот — можно к быстро накопленной энтропии применить криптографический алгоритм — и получить ультрабыстрый (в потоковом смысле) но и криптостойкий хеш.
Разумеется, неразмеченное пространство даст точно такой же эффект.
Их можно перезаписать поверху, после этого такой сектор может начать работать нормально (или будет переназначен, если ему кранты), а может и дальше заглючить в самый неподходящий момент.
1. Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT, директории…
2. Остается риск работы головки в поврежденном цилиндре, вызывая дальнейшую деградацию диска (расширяя задир, например).
Если уж так сильно охота использовать потенциально дохлый винт — правильно будет определить дефектную зону, покрыть её отдельным дисковым разделом с запасом в несколько десятков ГБ (минимум), который не форматировать и никак не трогать — тогда может быть винт и поживет какое-то время, если повезет.
Возврат приняли без пререканий…
Имхо, работа заслуживает серьезной критики — делать выводы по шести точкам на графике это пальцем в небо.
Более того, есть график, показывающий практически идентичность токов разряда и заряда при 18% начальном расхождении во внутреннем сопротивлении.