«Чтение volatile поля в Java на x86 архитектуре ничем не отличается от чтения обычного поля.» — а это всегда так, гарантируется ли, может ли случится что в следующем релизе java всё изменится? И почему только на x86?

Википедия со ссылкой на Joshua Bloch «Effective Java, Second Edition», p. 283-284 предлагает избегать лишних чтений volatile полей, якобы это вредит перформансу:

en.wikipedia.org/wiki/Double-checked_locking

// Works with acquire/release semantics for volatile in Java 1.5 and later
// Broken under Java 1.4 and earlier semantics for volatile
class Foo {
    private volatile Helper helper;
    public Helper getHelper() {
        Helper localRef = helper;
        if (localRef == null) {
            synchronized (this) {
                localRef = helper;
                if (localRef == null) {
                    helper = localRef = new Helper();
                }
            }
        }
        return localRef;
    }

    // other functions and members...
}

«Note the local variable „localRef“, which seems unnecessary. The effect of this is that in cases where helper is already initialized (i.e., most of the time), the volatile field is only accessed once (due to „return localRef;“ instead of „return helper;“), which can improve the method's overall performance by as much as 25 percent.[7]»

Противоречий нет конечно, возможно они имели ввиду как раз таки общий случай, а не x86, но тогда вопрос, если на x86 мы гарантировано не получаем прироста производительности, то откуда они взяли цифру 25% и на какой платформе они получили такой прирост, и хорошо бы им это упомянуть, в силу того, что x86 всё таки значительно популярнее всего остального.

А подскажите как проверяется что у вас есть предыдущий сертификат?
У меня вот есть SCJP 1.4 и SCJP 1.6.
От 1.4 храниться пластиковая карточка и листочек с результатом даже где-то был.
От 1.6 ничего нет.
Кому-то карточку нужно показать? Или в каком-либо аккаунте всё есть?
Хочу получить OCPJP 8

На текущий день это возможно и так. Но видно (медленное) стремление биржи к решению этой проблемы. Думаю постепенно FAST и TWIME будут улучшаться, а с каждым улучшением актуальность FPGA возрастает. Сделаю смелое предположение что доходы биржи от логинов очень не велики, по сравнению с другими статьями доходов.

«Мы получили положительные отзывы от производителей решений для торговли на основе FPGA.»

Если это не коммерческая тайна, то интересно от каких именно производителей? Может сразу плату FPGA сможете посоветовать, которая подходит для TWIME? Давно хочу что-нибудь такое потрогать.

Понятно, ну если не просто поменять то действительно лучше не трогать то что работает. Разница там по замерам совсем не большая.

хм. да там буквально одни файлы в /etc/sysconfig/network-scripts заменить на другие, и всё должно заработать.
OpenOnload только в последнем релизе начал поддерживать teaming.
в VMA по идее тоже либо уже добавили либо вот вот добавят.

вроде даже тулза есть для конвертирования, но я не пробовал access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Converting_a_Bond_to_a_Team.html

А подскажите как использовать set_irq_affinity.sh
Я при старте программы например использую пару ядер (скажем номер 3 и номер 4) для spinning. Там мне прерывания не нужны. Я хочу перенести прерывания с этих ядер на ядро 0. Могу я как-то для этой задачи этот скрипт приспособить?

И ещё стоит ли полностью отключать ipv6 если ipv6 не используется? Так как здесь написано access.redhat.com/solutions/8709

по поводу «OpenOnload только с Solarflare, которого у нас нет». Так а Mellanox VMA то используете?

Основной конкурент Mellanox — Solarflare вполне себе поддерживает Accelerated RFS. Причём помоему давно.
Так и называется Solarflare Accelerated RFS.

Implement SARFS; Solarflare Accelerated Receive Flow Steering
(disabled by default) This inserts hardware RX filters in order to direct
flows back to the same CPU where the user-land process is transmitted. This
should help cache locality.
This feature can be used when Accelerated RFS is not available in the
currently running kernel, and if ARFS is in use will be disabled.
To enable SARFS, set the «sarfs_sample_rate module» parameter to non-zero.
20 is recommended.
In addition, some form of XPS is needed for SARFS to function correctly. The
easiest way to do this is to enable Solarflare XPS by setting the module
parmaeter «sxps_enabled=1»
Alternatively if your kernel supports it you can enable XPS by following the
instructions at:
www.kernel.org/doc/Documentation/networking/scaling.txt

Спасибо. По пункту 2 ещё было бы интересно знать в граммах в микросекундах насколько биржа дольше обрабатывает FIX постановку заявку, чем cgate. Ведь клиент имеет возможность по фиксу транзакции ставить ощутимо быстрее (поскольку нет надобности запускать роутер) и возможно планомерное ускорние fix на стороне бирже приведёт к суммарной задержке «клиент + сервер» для фикса меньшей, чем для cgate.

«Одним сетевым интерфейсом сервер смотрит на специально выделенный для скоростных роботов пул наших серверов доступа, а вторым интерфейсом – в Интернет – это так называемый управляющий канал, предназначенный для обслуживания робота» — под интерфейсом подразумеваются VLAN? в общем случае сейчас ведь задействованно 2 сетевых интерфейса для LACP поверх которых идёт всё — и интернет и торговля. конечно можно брать 4 интерфейса — 2 для торговли, и для для интернет, но это будет немножко дороже по деньгам, да и в сервере не всякий раз имеется 4 порта.

Когда можно ожидать что FIX на срочке по скорости сравняется с cgate?

Через 2 года какой способ подключения планируется быть более быстрым, бинарный протокол или cgate? Кстати про бинарный протокол расскажите тоже :)