Ну чем лучше то? Дополнительный корпус, дополнительная обвязка, под это надо разводить дополнительно плату, потом дополнительно монтировать и все это будет дополнительно кушать батарейку.
Для поточного производства калибровка каждого устройство конечно накладывает возможно даже большие затраты. Но дома для DIY, померить в комнате, сравнить с градусником, померить в холодильнике, сравнить, вычислить коэффициенты, залить прошивку и готово, делов минут на пять.
Датчик точный, шкала не откалибрована. Калибруйте по двум точкам и будет все хорошо. Так с любыми измерительными приборами, нормальная практика, а то как в магазине будет, из пяти термометров четыре разное показывают.
Вы можете ускорить альгоритм РЭ но это будет уже другой алгоритм. Да и вообще для чего? Он хорош для демострации школьникам, а на практике на столько дорог что скорее бесполезен. На практике встречаестся задача проверки некоего числа на простоту. Для этого есть другие алгоритмы, например Конягина-Померанса, Миллера и куча более дешевых вероятностных оценок. Задача изобрести большое простое число решается примено так, генерируем случайное число большой размерности, проверяем его простоту, повторяем.
А потом железа становилось все больше и линий прерываний они стали просить все больше. Каскад из 8259 стал рудиментом который нужен первые миллисекунды, на смену ему пришел APIC а описание что и куда лежит в ACPI ни то ни другое простотой как в старину не отличается.
Ничего они не скрывают, просто дополнительно монетизируют. За цену меньше пачки сигарет они отдают все что знают и оригинальные фото. Нет тут Робин Гудов, только бизнес.
Читатели популярных изданий не факт что знают что такое корреляция, а если и знаю то скорее на уровне «графики похожи». А вообще подгонкой шкал можно многое друг к другу подогнать, где то была статья с хорошими примерами.
Имелось ввиду что скорость битовых операции в разных компилируемых языках мало отличимы по скорости. И отдельно операции с памятью в разынх компилируемых языках мало отличимы по скорости. А не то что битовые не отличимы от памяти. Это все было к тому что:
Да, разумеется, если взять язык, в котором битовые операции медленные, а обращение к памяти — быстрое, то можно ещё и не таких вещей наизобретать.
без разницы на каком языке писать такой тест, пропорции будут примерно одинаковые, а абсолютные значения будут отличаться в зависимости от компилятора.
Антон, можно на ты, почти вместе учились. При добавлении больших букв, все опять же зависит от входных данных, в этом тесте буквы выбираются ПСП с нормальным распределением, в реальном тексте распределение будет совсем другим как и результат по времени. Ниже описал что для таблиц результат зависит от производительности памяти а для бит от производителности процессора. Итого для таблицы производительность завит от входных данных и памяти а для битовых операций только от скорости считалки, ну а тест показывает что возможны условия когда таблица быстрее.
Да, в общем случае для данных с мощьностью алфавита 256 с нормальным распределением бинарный способ будет быстрее.
1. Если говорить про компилируемые языки, то скорось битовых операций и обращений к памяти едвали можно считать различными, конечно будут нюансы зависящие от реализации компилатора но в целом разницы нет.
2. Пока что примеры были на компилируемых языках, возьмите интерпретируемые, вы будете уверены что там биты будут быстрее?
3. Запустил ваш же пример на процессоре с чуть меньшей частотой $ ./test
Prepare table
Text source data:f axhtg6xr1grgiwotdn0kuvufyo36
Run bitwise
4.12588s
Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2
Run tabular
4.69363s
Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2
$ grep model /proc/cpuinfo | sort -u
model : 79
model name : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Разница уже не 120% а всего 14%, подозреваю что с той же памятью но меньшей частотой CPU результат будет ещё интереснее. Потому что с битами мы упираемся в частоту, а с таблицей в память.
4. Посмотрел godbolt, убедился что при O2
PoC pastebin.com/MwHy4cF1
на чем было под рукой, размер исходных данных только кратный трем, в примере 30Mb
Random source data: []byte{0x52, 0xfd, 0xfc, 0x7, 0x21, 0x82, 0x65, 0x4f, 0x16, 0x3f}...
Run bitwise 0.053900 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Run tabular 0.128237 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Text source data: :d9d fxqpe 0bq9}{mbx3kdadbqf8 ...
Run bitwise 0.042929 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Run tabular 0.024196 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Результат не стабильный, но для текста табличный метод всегда быстрее.
Для общего случая да, будет в несколько раз хуже, но напрмиер если на входе в основном будут строчные латинские буквы/цифры/пробел/скобки (читай обычный текст) то нужные куски таблицы попадают в кеш и этот способ уже работает быстрее битовых операций.
Никто не заметил что задача была сериализовать массив строк?
Решение:
1. придумать разделитель
2. экранировать в строках этот разделитель и возможно спец символы (если есть)
3. склеить строки с этим разделителем
Использование base64 для строк даст только экранирование спец симвлов (если они вообще есть) и увеличение размера на треть. Дальше интервьюер пытается направить на правильный путь, зная как работает предложенный вариант можно было бы понять что это так себе решение, но и тут пустота. Два вопроса — два не правильных ответа, есть смысл продолжать?
Програмирование и есть математика.
И кстати, ваша формулировка «c помощью битовых манипуляций» (и картинка с битами в голове) мешает вам же искать другие решения, почему не использовать таблицу? Надо всего то 64Mb памяти, это может внезапно оказаться быстрее плохой реализации с битами.
Потому что: для преобразования одного блока из 3 байт нужна будет только одна операция хоть и дорогая по тактам (примерно mov eax, [tbl + esi]), а для «битовых манипуляций» операций будет на порядок больше, пусть и дешевых.
Суть задачи именно такая, а вот на способ релизации, будете ли вы использовать длинную арифметику или догадаетесь что при таких основаниях можно оптимизировать до битовых операций и будет смотреть интервьюер.
Для поточного производства калибровка каждого устройство конечно накладывает возможно даже большие затраты. Но дома для DIY, померить в комнате, сравнить с градусником, померить в холодильнике, сравнить, вычислить коэффициенты, залить прошивку и готово, делов минут на пять.
без разницы на каком языке писать такой тест, пропорции будут примерно одинаковые, а абсолютные значения будут отличаться в зависимости от компилятора.
Да, в общем случае для данных с мощьностью алфавита 256 с нормальным распределением бинарный способ будет быстрее.
2. Пока что примеры были на компилируемых языках, возьмите интерпретируемые, вы будете уверены что там биты будут быстрее?
3. Запустил ваш же пример на процессоре с чуть меньшей частотой
$ ./test
Prepare table
Text source data:f axhtg6xr1grgiwotdn0kuvufyo36
Run bitwise
4.12588s
Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2
Run tabular
4.69363s
Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2
$ grep model /proc/cpuinfo | sort -u
model : 79
model name : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Разница уже не 120% а всего 14%, подозреваю что с той же памятью но меньшей частотой CPU результат будет ещё интереснее. Потому что с битами мы упираемся в частоту, а с таблицей в память.
4. Посмотрел godbolt, убедился что при O2
лучше
не все ещё забыто, успокоился.
на чем было под рукой, размер исходных данных только кратный трем, в примере 30Mb
Random source data: []byte{0x52, 0xfd, 0xfc, 0x7, 0x21, 0x82, 0x65, 0x4f, 0x16, 0x3f}...
Run bitwise 0.053900 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Run tabular 0.128237 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Text source data: :d9d fxqpe 0bq9}{mbx3kdadbqf8 ...
Run bitwise 0.042929 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Run tabular 0.024196 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Результат не стабильный, но для текста табличный метод всегда быстрее.
Решение:
1. придумать разделитель
2. экранировать в строках этот разделитель и возможно спец символы (если есть)
3. склеить строки с этим разделителем
Использование base64 для строк даст только экранирование спец симвлов (если они вообще есть) и увеличение размера на треть. Дальше интервьюер пытается направить на правильный путь, зная как работает предложенный вариант можно было бы понять что это так себе решение, но и тут пустота. Два вопроса — два не правильных ответа, есть смысл продолжать?
И кстати, ваша формулировка «c помощью битовых манипуляций» (и картинка с битами в голове) мешает вам же искать другие решения, почему не использовать таблицу? Надо всего то 64Mb памяти, это может внезапно оказаться быстрее плохой реализации с битами.
Потому что: для преобразования одного блока из 3 байт нужна будет только одна операция хоть и дорогая по тактам (примерно mov eax, [tbl + esi]), а для «битовых манипуляций» операций будет на порядок больше, пусть и дешевых.