Такое обычно происходит если вычисления выполняются во float/double (и отдаются на откуп железу). А если использовать decimal-типы, то вам гарантируется одинаковый результат на любом вменяемом железе.
«Java JIT» — встроенный Just In Time компилятор вирутальной машины Java. Преобразует Java-байткод в высокопроизводительный native-код, в том числе выполяет инлайниг, разворачивание циклов, векторизацию и много других оптимизаций. Именно он позволяет Java держать лидирующие позиции в тестах на производительность. И повторюсь, это не что-то отдельное от Java — это часть стандартной JVM.
Так что вы своим комментарием подтвердили, что вы совершенно не компетентны для обсуждения того, что Java может, а что нет.
Джавовый JIT (Hotspot C2) вполне способен на такие оптимизации.
Не способен. Причина проста — жава просто неспособна на подобные абстракции.
WAT? Вы либо лежали в криогенной камере последние лет 10 и не в курсе, что Java-вский JIT сейчас умеет, а что нет. Либо просто болтаете о том, что чего в принципе не знаете. Не изволите ли уточнить, что из двух?
Немножко побрюзжу. Посмотрел код 1-го проекта, в частности этот файл.
В одном файле не 6к строк смешалось всё: IO, парсинг, генерация отчета, структуры данных, алгоритмы (разные) — неужели ни разу не возникло желания разбить это по отдельным файлам?
Такое ощущение, что код даже не думали особо оптимизировать под производительность. Например много циклов, где на каждой итерации создаётся новый ArrayList (а ведь можно было бы переиспользовать); коллекции из примитивов (ArrayList, Set); сами цепочки хранятся просто как String (хотя это, вероятно, вынужденно, так как поиск реализован через регекспы, а не через специализированные алгоритмы).
Отмечу, что проблему для одного теста можно решить используя assertTimeoutPreemptively. Но это не подходит, если вы хотите задать таймаут по-умолчанию — ведь придётся завернуть в лямбду тело каждого теста, что "совсем не круто".
Замечу, что в JUnit 5 пока еще не нет эквивалентов для некоторых вещей из JUnit 4.
Например нет timeout для тестов (есть только возможность проверить, выполнился ли блок кода за указанное время) — это пока только в планах. Нет эквивалента @Rule Timeout (возможность задать дэфолтный timeout для тестов) и текущее API для extensions не позволяет сделать его аналог (а в JUnit 4 — такое можно было сделать руками).
Так что если у вас в тестах используются timeout-ы или @Rule хоть в каком-то виде, то есть вероятность, что смигрировать на JUnit 5 без потерь не получится.
Именно. Даже если владелец пула захочет максимизировать прибыль и выключит пул, то все майнеры из пула просто начнут работать на другой пул. Может и не через 60 секунд (зависит от клиента), но в течение суток — наверняка.
Тот редкий случай, когда "Трагедия общин" в некотором смысле работает на пользу общества.
Небось и остальными числами обман :)
Так что вы своим комментарием подтвердили, что вы совершенно не компетентны для обсуждения того, что Java может, а что нет.
Неужели вы хотите сказать, что SLY_G как раз такой журналист, о которых упоминается в статье?
</sarcasm>Немножко побрюзжу. Посмотрел код 1-го проекта, в частности этот файл.
В одном файле не 6к строк смешалось всё: IO, парсинг, генерация отчета, структуры данных, алгоритмы (разные) — неужели ни разу не возникло желания разбить это по отдельным файлам?
Отмечу, что проблему для одного теста можно решить используя
assertTimeoutPreemptively. Но это не подходит, если вы хотите задать таймаут по-умолчанию — ведь придётся завернуть в лямбду тело каждого теста, что "совсем не круто".Нет, совсем не то же самое. Допустим у вас блок кода по факту работает 5 минут, а на тесте вы выставили таймаут в 10 секунд.
В JUnit 4 вы через 10 секунд получите таймаут, а thread с тестом будет остановлен. Полное время выполнения теста — около 10 секунд.
В JUnit 5 тест отработает все 5 минут и уже после этого будет отмечен как неудачный. Полное время работы теста — 5 минут.
Еще хуже, если у вас тест иногда виснет (и как раз по этой причине вы выставили таймаут) — в JUnit 5 такой тест никогда не остановится.
Замечу, что в JUnit 5 пока еще не нет эквивалентов для некоторых вещей из JUnit 4.
Например нет timeout для тестов (есть только возможность проверить, выполнился ли блок кода за указанное время) — это пока только в планах. Нет эквивалента
@Rule Timeout(возможность задать дэфолтный timeout для тестов) и текущее API для extensions не позволяет сделать его аналог (а в JUnit 4 — такое можно было сделать руками).Так что если у вас в тестах используются timeout-ы или
@Ruleхоть в каком-то виде, то есть вероятность, что смигрировать на JUnit 5 без потерь не получится.Я прекрасно понимаю, что ситуация, в целом, нормальная. Но "триумф"?...
По поводу оптимальных стратегий — посмотрите http://ncase.me/trust/ (очень рекомендую). Либо русскую версию.
Т.е. то, что будет в Java 9 и делается для Java 10 — не считается? Или, быть может, вы считаете, что в OpenJDK Оракл почти не контрибьютит?
Странно говорить про "триумфальное возвращение" с учетом проблем с segfault под нагрузкой на процах вышедших весной.
Насколько результаты распознавания через https://tech.yandex.ru/speechkit/ могут отличаться от распознования приложениями Яндекса?
Какой сейчас лучший WER у open source библиотек? Просто интересно, насколько Яндекс лучше?
Именно. Даже если владелец пула захочет максимизировать прибыль и выключит пул, то все майнеры из пула просто начнут работать на другой пул. Может и не через 60 секунд (зависит от клиента), но в течение суток — наверняка.
Тот редкий случай, когда "Трагедия общин" в некотором смысле работает на пользу общества.
Почему вы не оформили статью как перевод?
Как обрабатывается ситуация с компрометацией приватного ключа агента (участника)?