Это - не чистая архитектура. Это кто-то раньше писал код на джаве и потом стал писать на Go. А привычки остались.
Если у вас много пакетов с одним-двум файлами, это означает кривую попытку перенести ООП инкапсуляцию в Go. А в Go, оказалось, есть только инкапсуляция на уровне пакетов. Ну вот что было, то и взяли.
Можно было бы подумать, что AMD внезапно решили выпускать ARM чипы, но об этом ни слова нет
Так что нет сомнений, что следующие несколько лет обещают быть захватывающими для индустрии
Последние примерно лет 8 уже нет никаких иллюзий на тему того, что в мире x86 чипов ничего захватывающего или революционного не ожидается в ближайшей перспективе.
Единственное, в чем производители соревнуются - это цифры на бумаге, чтобы стейкхолдерам пыль в глаза пускать. А по факту никаких прорывов нет. Это не плохо и не хорошо, просто вот так.
Когда строки в приложении большие (допустим, от 64кб), 8 байт size_t действительно теряются на фоне строки. В этом случае varint будет кодироваться 3+ байтами.
8 байт size_t для строк длиной 128 байт и меньше - это уже достаточно много. В этом случае только длина - это ~6% размера самой строки. В таком ключе работа с мелкими строками становится дорогой по памяти, если таких строк много.
В 1ГиБ может быть ~8.4млн таких строк, для которых 8 байт размера будут занимать 64МиБ. Или, другими словами, ещё ~500к мелких строк.
А от того, сможет приложение загрузить в память целиком огромный массив данных или нет, может зависеть и производительность приложения в целом, т.к. "лишиние" сотни тысяч-миллионы строк может быть нужно читать уже с диска.
А вы посмотрите на ассемблерный код декодирования base 128 encoding и сравните его с одной командой чтения выравненного в памяти uint32
А зачем? (Мне) очевидно, что работа с varint будет дороже в плане ресурсов CPU чем работа с нативными integer типами.
Но какая разница насколько дорога работа с varint, если речь идёт о работе со строками, длина которых (теоретически) представлена в виде varint?
В контексте работы со строками эта операция будет проводиться один раз для того чтобы преобразовать int в varint и наоборот, чтобы определить границы строки или создать строку. Это побочная операция т.к., в подавляющем большинстве случаев работа со строками на этом не заканчивается. То, что будут сэкономлены пару тактов, большой погоды не сделает, т.к. копирование, парсинг, поиск, сортировка и пр. будут занимать намного больше времени.
Но следует понимать, что кодирование и декодирование такого представления требует дополнительных ресурсов CPU
Да, но:
чем короче строка, тем меньше затраты на работу со значением длины. для коротких строк (до 127) разницы с 1-байтовой длиной не будет
чем длиннее строка, тем для работы с ней в принципе нужно больше ресурсов, и с увеличением длины длины (простите) линейно, "рабочая" длина строки увеличивается нелинейно и уже может не влезать в кеш CPU более низкого уровня. В этом случае преобразование variable-width integer в fixed-width integer может не играть значительной роли
всё это справедливо исключительно для runtime представления строк, компилятору в общем-то итак известны длины констант
компиляторы (LLVM) используют variable-width integer во внутреннем представлении
на современных процессорах кодирование/декодирование такого рода может быть ускорено SIMD операциями
В общем и целом, если ресурсы на "кодирование и декодирование" такого представления оказываются незначительны по сравнению с ресурсами на работу с null-terminated строками, то это не то что бы плохой вариант.
Но это в любом случае невозможно в C, т.к. C - это по большому счету синтаксический сахар для опкодов процессора. И если fixed-width integer - это число с точки зрения процессора, то variable-width integer - это просто бессмысленные байты, которые компилятор сам должен преобразовать в числа. И основная проблема, на мой взгляд, именно в этом, а не в производительности работы со строками.
Это - не чистая архитектура. Это кто-то раньше писал код на джаве и потом стал писать на Go. А привычки остались.
Если у вас много пакетов с одним-двум файлами, это означает кривую попытку перенести ООП инкапсуляцию в Go. А в Go, оказалось, есть только инкапсуляция на уровне пакетов. Ну вот что было, то и взяли.
Из википедии:
Чем он интересный, если про него практически ничего не известно?
del
https://www.nordicsemi.com/Products/nRF51822/GetStarted
Буквально первая ссылка по запросу "NRF51822 programming"
Но:
Там могут не быть разведены JTAG и UART, придется напрямую к ногам паяться
Возможно включен secure boot, тогда неподписанную прошивку нельзя залить в принципе
Зачем тут arduino нужен? В ESP-IDF уже есть BLE стек, а arduino итак работает поверх IDF.
По большому счёту, вся Arduino вообще не используется в этом проекте.
И в чем заключается "метод Apple" из заголовка?
Можно было бы подумать, что AMD внезапно решили выпускать ARM чипы, но об этом ни слова нет
Последние примерно лет 8 уже нет никаких иллюзий на тему того, что в мире x86 чипов ничего захватывающего или революционного не ожидается в ближайшей перспективе.
Единственное, в чем производители соревнуются - это цифры на бумаге, чтобы стейкхолдерам пыль в глаза пускать. А по факту никаких прорывов нет. Это не плохо и не хорошо, просто вот так.
Как извлечь прибыль из прибыльной рекламной кампании на Ютубе, когда Гугл выключил монетизацию для пользователей из РФ?
А вы образчик культуры, как я погляжу:
Раз уж вы опускаетесь до хамства и перехода на личности, то не вижу смысла дальше продолжать.
Смелое утверждение. Это вам так кажется :)
А проблемы-то это какие вызывает? Само вычисление смещения - это не сортировка
В случае с короткими строками разницы нет никакой т.к. varint до значения 128 занимает 1 байт
Смещение вычисляется простым подсчётом байта, у которого первый бит 0
В случае, если длины строк различаются, конвертировать в обычный int их для сравнения может быть даже и не нужно
Когда длины строк равны - вычисление смещения в общем море операций сравнения будет в пределах погрешности
Чтобы сортировать строки, вам их надо будет перемещать. Перемещение строк дороже, чем сравнение заголовка.
RSS
Это зависит от масштабов.
Когда строки в приложении большие (допустим, от 64кб), 8 байт size_t действительно теряются на фоне строки. В этом случае varint будет кодироваться 3+ байтами.
8 байт size_t для строк длиной 128 байт и меньше - это уже достаточно много. В этом случае только длина - это ~6% размера самой строки. В таком ключе работа с мелкими строками становится дорогой по памяти, если таких строк много.
В 1ГиБ может быть ~8.4млн таких строк, для которых 8 байт размера будут занимать 64МиБ. Или, другими словами, ещё ~500к мелких строк.
А от того, сможет приложение загрузить в память целиком огромный массив данных или нет, может зависеть и производительность приложения в целом, т.к. "лишиние" сотни тысяч-миллионы строк может быть нужно читать уже с диска.
А зачем? (Мне) очевидно, что работа с varint будет дороже в плане ресурсов CPU чем работа с нативными integer типами.
Но какая разница насколько дорога работа с varint, если речь идёт о работе со строками, длина которых (теоретически) представлена в виде varint?
В контексте работы со строками эта операция будет проводиться один раз для того чтобы преобразовать int в varint и наоборот, чтобы определить границы строки или создать строку. Это побочная операция т.к., в подавляющем большинстве случаев работа со строками на этом не заканчивается. То, что будут сэкономлены пару тактов, большой погоды не сделает, т.к. копирование, парсинг, поиск, сортировка и пр. будут занимать намного больше времени.
Да, но:
чем короче строка, тем меньше затраты на работу со значением длины. для коротких строк (до 127) разницы с 1-байтовой длиной не будет
чем длиннее строка, тем для работы с ней в принципе нужно больше ресурсов, и с увеличением длины длины (простите) линейно, "рабочая" длина строки увеличивается нелинейно и уже может не влезать в кеш CPU более низкого уровня. В этом случае преобразование variable-width integer в fixed-width integer может не играть значительной роли
всё это справедливо исключительно для runtime представления строк, компилятору в общем-то итак известны длины констант
компиляторы (LLVM) используют variable-width integer во внутреннем представлении
на современных процессорах кодирование/декодирование такого рода может быть ускорено SIMD операциями
В общем и целом, если ресурсы на "кодирование и декодирование" такого представления оказываются незначительны по сравнению с ресурсами на работу с null-terminated строками, то это не то что бы плохой вариант.
Но это в любом случае невозможно в C, т.к. C - это по большому счету синтаксический сахар для опкодов процессора. И если fixed-width integer - это число с точки зрения процессора, то variable-width integer - это просто бессмысленные байты, которые компилятор сам должен преобразовать в числа. И основная проблема, на мой взгляд, именно в этом, а не в производительности работы со строками.
Не variant, а varint. Т.е. VLQ или base 128 encoding, о котором вы и сказали (:
А почему не varint тогда?
Хотите короткую строку - длина 1 байт, хотите длинную - 2 байта и т.д.
Когда в строке уже н-цать тысяч байт, один байт погоды не сделает
С версии 3.0 требуют подключить карту (и обещают не списывать деньги до лимитов, честно-честно).
Скриншот
А заголовки на полэкрана - это по каким гайдлайнам?
А потом он станет таким же монополистом, и делиться будет опять надо? :)
Идея сама по себе ничего не стоит, если хотите - надо делать самому. Сайт с админкой сделать очень просто. Вот сами и посмотрите - взлетит или нет
Так может вы не только брать будете, но и сами что-то взамен дадите?
Если вам пользователи данные отдают бесплатно, дайте и вы бесплатный доступ к API тем, кто ва данные предоставляет.