Если ключи числовые (int32) и имеют ярко выраженную последовательность, то хеш-мапу
можно свести к массиву с дырками. Но это надо исследовать саму природу ключей.
Как они генерируются. Как идет ротация.
значение - вектор указателей
Еще наблюдение. Работа с хеш-мапой - это работа не только к ключами но и с value.
Надо в реальном времени посмотреть как часто читается value или насколько удачно
оно заполняет например L1/L2. При неудачных раскладах у нас будет рециркуляция
значений в кешах и алгоритм хеширования будет здесь вообще не причем. А будет
идти работа с медленной памятью. Тоесть векторов оптимизации у нас много
и алгоритм хеширования здесь просто - один из факторов.
TheAthlete, это очень консервативный стандарт. Кажется для LTO ширина ленты совпадает с VHS видеокассетой.
По поводу услуг восстановления данных. Вопрос звучит немного по другому. У тебя на ленте
есть обычно последовательность backups за какие-то года и месяцы. Лента обычно не переписывается
а дописывается в хвост. Тоесть у тебя на кассете полюбому несколько backups.
И такое чтоб все из них были испорчены - маловероятно.
@SunTechnik
По поводу фактов. Сейчас на дворе стоит 2024 год. И если у вас на производтсве были кассеты
2004 года - то берите и просто проверяйте их содержимое. Вот это и будет факт. Это будет
лучшая реклама чем какие-то там заявления от производителя.
Политика QNA это - ответы на вопросы. Автор спрашивает вопрос. Мы отвечаем ответ.
Очень верно задан вопрос - зачем 200 тыс. Я не знаю зачем. Если печатать это на принтере
то понадобиться 4000 листов бумаги А4.
Ясное дело что автор никогда это глазами не осилит посмотреть. И я надеюсь что он
это быстро поймет. Нужно будет добавить ограничитель чтоб while покзывал хотя-бы
первые 100 строк к сведенью.
В любом топике должен быть дискурс. В данном случае новичек услышал про регулярки.
Вот он услышал и дальше пойдет, как утёнок фабриковать регулярку на любой пустяк.
Получится эдакое regexp-ориентированное программирование. Поэтому
пускай посмотрит и подумает что есть 2 варианта. И есть встроенная функция isDigit
которая почти решает задачу и осталось только добавить точку с сравнению.
А что касается всего диапазона Unicode символов. Ну тут главное чтоб тесты зашли
в зеленый сегмент. Позитивный сценарий есть - оно и ладненько.
Не очень понятно зачем ты втащил сюда С-программирование.
int num_bytes = atoi(content_length);
здесь ты пропустил проверку на 0. atoi в случае неуспеха конвертации возвращает ноль. fread(data, 1, num_bytes, stdin);
здесь тоже нет проверки на ноль.
malloc(num_bytes + 1)
если ты в коде где-то использовал malloc то в конце надо память удалить. Критично
для джобов. Но и для таких коротких функций - правила хорошего тона. Чтоб под контролем было.
и эта штука не обязана никакие файлы писать. Она пишет в файл STDOUT. Чтоб перенаправить
ее принт в файл надо сделать что-то вроде ./http_handler >> file.txt
Maksim Herasim, с точки зрения надежности у тебя с большей вероятностью упадет MySQL
чем брокер. У БД - больше слабых мест и больше причин падать.
Ну впрочем как будет угодно. И тут вобщем
нет какого-то математического доказательства что один метод лучше а другой хуже.
Это только твой личный опыт покажет.
d-stream, я не знаю как работает Крипто-ПРо. Но чтобы механизмы начали
работать - нужна безопасная среда. И если среда опасная (Windows 95 например)
то и для Крипто-Про будет скорее всего недостаточно каких-то гарантий.
Яркий пример. Есть Linux. Вроде-бы безопасный. А есть еще и SE-Linux
- почти тот-же линукс но чуть больше гарантий.
Alex, обрати внимание. Там не просто уменьшение и черно белая квантизация.
Там еще идет одна операция которая делает хеш толерантным к операциям линейных
коррекций RGB. Типа если пользователь покрутил яркость-контраст - то phash все равно
должен сохранятся.
