retry и jz retry нужны из-за того, что обращение к началу массива даёт слишком много шума и, таким образом, извлечение нулевых байтов достаточно проблематично. Честно говоря, я не особо понял, зачем так делать — я бы просто к rax прибавил единичку сразу после чтения, да и всё.
Судя по всему в некоторых случаях "подсмотренный" байт может занулиться до выполния shl. jz retry нужен для того чтобы ингорировать неудачные для нас исходы race condition
Использовать стандартный протокол WebSocket (или даже WAMP) и стандартную сериализацию json/msgpack/protobuf по вкусу.
Это упростит «добавление серверных библиотек для других языков программирования» и с авторизацией и шифрованием сразу понятно будет что делать.
Про HTML уже написали (можно генерировать HTML код если так хочется писать только на c++)
$ file */data | grep gzip
5745740063905b3a11d97bd5/data: gzip compressed data, was "data", last modified: Wed May 25 09:24:43 2016, from NTFS filesystem (NT)
57466eb863905b3a11d97bed/data: gzip compressed data, was "data", last modified: Wed May 25 14:58:12 2016, max compression, from NTFS filesystem (NT)
57469a9263905b3a11d97bf0/data: gzip compressed data, was "temp.json", last modified: Tue May 24 19:37:25 2016, max compression, from FAT filesystem (MS-DOS, OS/2, NT)
57487c4363905b3a11d97c72/data: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
5748ab4963905b3a11d97caa/data: gzip compressed data, last modified: Fri May 27 20:00:37 2016, max compression, from Unix
5748dda963905b3a11d97d06/data: gzip compressed data, from Unix
В новых конкурсах можно применить краудсорсинг:
Прописать в условиях, что в течении какого-то срока (скажем первая неделя из 4х) условия могут уточняться.
За неделю силами самих участников какая-то часть неоднозначностей будет устранена.
1) От слов отрезаются префиксы и суффиксы.
2) Несколькими эвристиками отрезаются «неслова» (больше 14 букв, много гласных/согасных подряд/в_конце_слова, апостроф в слове)
3) Немного модифицированный bloom: вместо добавления в фильтр битов hash1(word) и hash2(word) добавляются hash1(word.substring(0,6)) и hash2(word.substring(0,9)), что дало сокращение false positives и примерно +1% к результату
4) За полчаса до дедлайна осознал, что bloom filter тоже можно «обучать» удаляя из него биты с false_positives больше positives. «В полубессознательном состоянии» до дедлайна удалось выжать из этой идеи +0.5%. Уже после дедлайна это обучение дало почти 83%
Тоже уверенно преодолел 80% на официальном тестовом скрипте, но до 81 ещё далеко.
Вообще удивлён тем, что так мало заявок >=80% — все необходимые для 80% идеи написаны на этой странице по много раз.
85% в топовых местах уже не кажутся нереальными.
На политзанятиях на заводе токарь задает вопрос:
— Вот вы говорите, что все так хорошо, а куда пропало масло?
— Я подумаю и отвечу в следующий раз, — говорит агитатор.
В следующий раз агитатору хочет задать вопрос другой рабочий.
— Вы, вероятно, хотите спросить, куда девалось масло? — обращается к нему агитатор.
— Нет, я хочу спросить, куда девался токарь?
Протекция это критическая секция? То есть системный код bitcloud запрещает хардварные прерываний на время значительно превосходящее озвученные 50us?
Ваше прерывание по переходу через ноль никуда не должно пропадать и должно вызываться при выходе из критической секции.
Timer Input capture не пробовали? При его использовании вы сможете узнать точное время перехода через ноль, даже если во время перехода выполнялась критическая секция.
Вы упёрлись в ограничение на 50us в коде «своего/не_системного» прерывания перехода через ноль? (в остальных местах вполне достаточные ограничения на 10ms/50ms).
Вроде кроме этого прерывания и импульса включения по таймеру для диммера ничего больше и не нужно…
1) Вы не рассматривали вариант использования NRF51822?
+++ arm (есть нормальный gcc, а не какой-то sdcc)
+ BT LE (можно управлять напрямую с телефона)
+ поддерживает протокол nrf24l*1 (если будут проблемы с BT)
— возможно будут те же проблемы что и с BitCloud (стек BT и код приложения крутится одном контроллере)
2) Контроль ноля не на прерываниях? Что там так долго выполняется?
А почему место в tmpfs кончалось? INSERT FROM SELECT использовали?
Вручную 1 -> SELECT без лимита -> читаем 1000 строк -> INSERT -> 1 не пробовали?
Для INNODB ещё можно было бы в вашем случае заменить OFFSET на id>last_processed_id + ORDER BY id если id-первичный ключ сортировка по которому бесплатна
Судя по всему в некоторых случаях "подсмотренный" байт может занулиться до выполния shl.
jz retryнужен для того чтобы ингорировать неудачные для нас исходы race conditionЭто упростит «добавление серверных библиотек для других языков программирования» и с авторизацией и шифрованием сразу понятно будет что делать.
Про HTML уже написали (можно генерировать HTML код если так хочется писать только на c++)
Tested 10000 of 10000 blocks Total W NW NW[0] NW[1] NW[2] NW[3] NW[4] NW[5] NW[6] NW[7] NW[8] 1000k 500672 499328 92206 69134 74631 78793 75506 56814 30604 14427 7213 Correct F- F+ F+[0] F+[1] F+[2] F+[3] F+[4] F+[5] F+[6] F+[7] F+[8] ms/100w submissions/5748dda963905b3a11d97d06/ 81.44% 3.78% 33.38% 4.72% 21.86% 29.06% 33.77% 41.36% 54.37% 67.08% 74.49% 76.54% 9Чорд, галку gzip в форме не проставил.
Судя по всему не я один
Прописать в условиях, что в течении какого-то срока (скажем первая неделя из 4х) условия могут уточняться.
За неделю силами самих участников какая-то часть неоднозначностей будет устранена.
На учебных выборках было под 84%.
1) От слов отрезаются префиксы и суффиксы.
2) Несколькими эвристиками отрезаются «неслова» (больше 14 букв, много гласных/согасных подряд/в_конце_слова, апостроф в слове)
3) Немного модифицированный bloom: вместо добавления в фильтр битов hash1(word) и hash2(word) добавляются hash1(word.substring(0,6)) и hash2(word.substring(0,9)), что дало сокращение false positives и примерно +1% к результату
4) За полчаса до дедлайна осознал, что bloom filter тоже можно «обучать» удаляя из него биты с false_positives больше positives. «В полубессознательном состоянии» до дедлайна удалось выжать из этой идеи +0.5%. Уже после дедлайна это обучение дало почти 83%
На большом числе слов безусловно победят самообучающиеся или гибридные варианты.
Тоже уверенно преодолел 80% на официальном тестовом скрипте, но до 81 ещё далеко.
Вообще удивлён тем, что так мало заявок >=80% — все необходимые для 80% идеи написаны на этой странице по много раз.
85% в топовых местах уже не кажутся нереальными.
— Вот вы говорите, что все так хорошо, а куда пропало масло?
— Я подумаю и отвечу в следующий раз, — говорит агитатор.
В следующий раз агитатору хочет задать вопрос другой рабочий.
— Вы, вероятно, хотите спросить, куда девалось масло? — обращается к нему агитатор.
— Нет, я хочу спросить, куда девался токарь?
Ваше прерывание по переходу через ноль никуда не должно пропадать и должно вызываться при выходе из критической секции.
Timer Input capture не пробовали? При его использовании вы сможете узнать точное время перехода через ноль, даже если во время перехода выполнялась критическая секция.
Вроде кроме этого прерывания и импульса включения по таймеру для диммера ничего больше и не нужно…
Когда диммер зарелизите таких телефонов будет уже много.
+++ arm (есть нормальный gcc, а не какой-то sdcc)
+ BT LE (можно управлять напрямую с телефона)
+ поддерживает протокол nrf24l*1 (если будут проблемы с BT)
— возможно будут те же проблемы что и с BitCloud (стек BT и код приложения крутится одном контроллере)
2) Контроль ноля не на прерываниях? Что там так долго выполняется?
Вручную 1 -> SELECT без лимита -> читаем 1000 строк -> INSERT -> 1 не пробовали?
Для INNODB ещё можно было бы в вашем случае заменить OFFSET на id>last_processed_id + ORDER BY id если id-первичный ключ сортировка по которому бесплатна
Но лучше всё-таки использовать bindValue.
QString не знает о том, что иногда нужно экранировать параметры SQL запроса