Действительно ли стоит изучить определенные для AMD API?
Task реализует интерфейс Worker , который имеет свойство state . Вы можете слушать это свойство и реагировать, когда Worker.State изменяется на SUCCEEDED, CANCELLED или FAILED.
Task task = ...;
task.stateProperty().addListener((obs, oldVal, newVal) -> {
// Test newVal and do something as needed...
});
Или вы можете прослушать свойство running .
task.runningProperty().addListener((obs, oldVal, newVal) -> {
if (!newVal) {
// Do something...
}
});
Вы также можете прослушать WorkerStateEvent с на Task.
task.setOnSucceeded(event -> {});
task.setOnCancelled(event -> {});
task.setOnFailed(event -> {});
// or even something like
task.addEventHandler(WorkerStateEvent.ANY, event -> {
// Test event type and do something as needed...
});
Тогда есть также защищенные «методы состояния».
Task task = new Task<>() {
@Override
protected Boolean call() throws Exception {
return false;
}
@Override protected void succeeded() {}
@Override protected void cancelled() {}
@Override protected void failed() {}
});
Все эти опции будут уведомлять вас в Потоке приложений JavaFX .
3 ответа
Библиотеки MKL и IPP будут работать (почти) также на машинах AMD. Мое предположение - то, что TBB будет также работать очень хорошо на полях AMD. Если бы я должен был предложить технологию, которая была бы выгодна и полезна для обоих, то она должна будет освоить библиотеки OpenMP. Компилятор Intel с расширениями OpenMP потрясающе быстр и работает с микропроцессорами AMD также.
Только стоящий того, если Вы конкретно интересуетесь созданием чего-то как Видеоигры, Операционные системы, серверы баз данных или программное обеспечение виртуализации. Другими словами: если у Вас есть сегмент, где Вы заботитесь достаточно о производительности для занимания время, чтобы сделать это (и сделать его правильно) в ассемблере. То же верно для Intel.
Если Ваша компания продает пакеты просто Intel Servers с Вашим программным обеспечением, то Вы не должны потрудиться изучать подход AMD. Но если Вы оказываетесь перед необходимостью предлагать программное обеспечение для обоих (или многие) различные платформы, затем могло бы стоить изучить различные технологии. Будет очень трудно создать обертки для определенных для аппаратных средств библиотек. (Тем более, что поточная обработка включена.)
И Вы определенно не хотите писать абсолютно отдельную реализацию для каждой аппаратной конфигурации. На самом деле, если Ваше программное обеспечение должно быть использовано основным пользователем, то можно хотеть отказаться от технологии Intel и использовать стандартные методы поточной обработки. Я не означаю быть обескураживающим, но я полагаю, что библиотеки поточной обработки Intel немного впереди своего времени, во всех отношениях.