• Уменьшение времени отклика при передаче данных по UDP
    0
    Думаю, да, опрелённое ускорение можно получить за счёт raw-сокетов. Но тут нужно было обрабатывать именно UDP-пакеты из пользовательского приложения, т.е. у нас не было цели оптимизировать само приложение.
  • Уменьшение времени отклика при передаче данных по UDP
    0
    На хосте — обычный арч, на плате — тюнили заказчики, подробностей не знаю.

    Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?
  • Портирование ОС на Aarch64
    0
    Насколько я понимаю, на железке u-boot запускается уже после Arm Trusted Firmware, так что и Embox — тоже.

    В QEMU, как я понял, можно подсунуть ATF, но мы этого не делаем :)
  • Портирование Quake3
    0
    Да, дело действительно в этом, как-то не пришло в голову. Спасибо! Добавил замечание в статью об этом косяке.

    На ARM для NEON у нас такое есть, а на x86 — нет.
  • Портирование Quake3
    0

    В Mesa действительно есть хорошая поддержка аппаратного ускорения, но она не работает с аппаратурой напрямую, для её использования нужен слой DRM, который и взаимодействует с GPU (и которого у нас пока что нет). Если сконфигурить Mesa с драйвером swrast, она будет, грубо говоря, рисовать картинку в оперативной памяти, без задействования DRM, этот вариант и используется на данный момент.


    Реализовать аналог DRM из Linux достаточно сложно, работаем над этим. В данный момент делается драйвер для Vivante GPU на i.MX6. Получить простую анимацию уже получилось, а вот "подружить" драйвер с Mesa не выходит. Там достаточно много подводных камней, когда закончим м.б. накатаю статью по этой теме.

  • Портирование Quake3
    0
    если его нельзя

    Можно, это видно на скринах в статье. Графика отрисовывается с помощью Mesa, Mesa реализует OpenGL API.


    так сложно использовать

    Так же, как и обычно — пишете программу, используя OpenGL API, и компилируете.


    Станет понятнее, если прочитать статью чуть дальше первого предложения. Непосредственному использованию самого OpenGL тут посвящено несколько предложений и два листинга кода по 20 строк.

  • Портирование Quake3
    0

    Странно, но KVM тут не помогает. Ещё страннее, что в исходниках qemu сама инструкция (stmxcsr) упоминается и кажется, что и программно всё должно работать. Но что-то идёт не так. Проверил только что — на хосте инструкция исполняется без проблем.


    Затрудняюсь сказать, что именно идёт не так.

  • Указатели в C абстрактнее, чем может показаться
    0

    Дело не в третьей переменной, а именно в -O0. С -O1 будет как в примере в статье.


    Если посмотреть дизассемблер, с оптимизацией p == q предподсчитывается как 0.


        printf("%p %p %d\n", (void *)p, (void *)q, p == q);
     6b4:   48 8d 54 24 0c          lea    0xc(%rsp),%rdx
     6b9:   48 89 d6                mov    %rdx,%rsi
     6bc:   b9 00 00 00 00          mov    $0x0,%ecx # Вот здесь просто пишется 0 в ecx
     6c1:   48 8d 3d 9c 00 00 00    lea    0x9c(%rip),%rdi 
     6c8:   b8 00 00 00 00          mov    $0x0,%eax
     6cd:   e8 8e fe ff ff          callq  560 <printf@plt>

    Без оптимизации делается честный cmp.


        printf("%p %p %d\n", (void *)p, (void *)q, p == q);
     6cc:   48 8b 45 f8             mov    -0x8(%rbp),%rax
     6d0:   48 3b 45 f0             cmp    -0x10(%rbp),%rax # Тот самый cmp
     6d4:   0f 94 c0                sete   %al
     6d7:   0f b6 c8                movzbl %al,%ecx
     6da:   48 8b 55 f0             mov    -0x10(%rbp),%rdx
     6de:   48 8b 45 f8             mov    -0x8(%rbp),%rax
     6e2:   48 89 c6                mov    %rax,%rsi
     6e5:   48 8d 3d 98 00 00 00    lea    0x98(%rip),%rdi  
     6ec:   b8 00 00 00 00          mov    $0x0,%eax
     6f1:   e8 6a fe ff ff          callq  560 <printf@plt>
  • Указатели в C абстрактнее, чем может показаться
    +6
    В переводе с первым примером упущена существенная деталь.

    If compiled with and optimization level 1, then a run of the program on a x86-64 Linux system prints:

    Без оптимизации результат другой.

    > gcc main.c
    > ./a.out
    0x7ffd9dad19fc 0x7ffd9dad19fc 1
    > gcc main.c -O1
    > ./a.out
    0x7ffe4b876ebc 0x7ffe4b876ebc 0

    gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
  • Существует ли отечественный процессор Мультиклет?
    +1
    Чтобы избегать ситуаций, подобных следующей:
    min(foo++, bar)
    С дополнительными переменными foo будет инкрементирована один раз, а без них — дважды.

    Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
  • Существует ли отечественный процессор Мультиклет?
    +4
    Спасибо за замечание!
    В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить.
    Ссылка на коммит
    Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)