Вопросы Теги

Существует ли улучшение пропускной способности от установки 32-разрядной операционной системы на 64-разрядной машине?

Если учетная запись не может быть создана, вы не хотите ничего возвращать.
По крайней мере, вы хотите вернуть ответ об ошибке 400, чтобы сообщить клиенту о проблеме.

Вы можете использовать ResponseEntity в качестве типа возврата вашего метода для сигнализации кода ответа. Это также означает, что вам придется изменить способ возврата объекта и в успешном случае.
Вы можете изменить метод таким образом, если вы не хотите передавать конкретное сообщение об ошибке, а только код ошибки: 

public ResponseEntity<EmployeeBankAccountOutputDto> createBankAccount(@ApiParam("Account data") @RequestBody final EmployeeBankAccountInputDto accountCreationDto) {

    try {
        return  ResponseEntity.ok(service.createBankAccount(accountCreationDto));
    } catch (InvalidAccountDataException ex) {
      log.warn(ex.getMessage());
      return ResponseEntity.badRequest();
    } 
}

Если вы также хотите передать конкретное сообщение об ошибке, вы можете использовать тело Ответ: 

public ResponseEntity<EmployeeBankAccountOutputDto> createBankAccount(@ApiParam("Account data") @RequestBody final EmployeeBankAccountInputDto accountCreationDto) {

    try {
        return  ResponseEntity.ok(service.createBankAccount(accountCreationDto));
    } catch (InvalidAccountDataException ex) {
      log.warn(ex.getMessage());
      return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(ex.getMessage());
    } 
}

Обратите внимание, что если вам нужно выполнить эту обработку в нескольких контроллерах, это, вероятно, означает, что обработчик исключений будет более подходящим подходом.
Например, чтобы обрабатывать InvalidAccountDataException единообразным способом: 

@ControllerAdvice
public class MyExceptionHandler extends ResponseEntityExceptionHandler {

    Logger LOGGER = LoggerFactory.getLogger(MyExceptionHandler.class);

    @ExceptionHandler(value = { InvalidAccountDataException.class })
    protected ResponseEntity<Object> handleGenericExceptions(InvalidAccountDataException ex, WebRequest request) {
        log.warn(ex.getMessage());
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(ex.getMessage());      
    }

}

Вы можете добавить больше методов для обработки большего количества типов исключений, если, конечно, требуется.

5
задан Robert Gamble 12 November 2008 в 02:47
поделиться

4 ответа

Ответ: да это может до некоторой степени, хотя различие в производительности вряд ли будет большим.

Любой сравнительный тест для тестирования этого должен будет сделать большое разрешение указателя, которое будет трудно разделить из шума. Разработка сравнительного теста, который не оптимизирует далеко, является трудной. Эта статья о дефектных сравнительных тестах Java была отправлена кем-то в ответ на другой вопрос, но многие принципы, описанные в нем, будут относиться к этому.

4
ответ дан 18 December 2019 в 10:50
поделиться

Пропускная способность не является действительно правильным термином здесь. То, о чем действительно говорил Knuth, было плотностью данных, поскольку это касается места кэша. Предположите, что у Вас есть 16 КБ кэш данных L1: при чистом хранении указателей можно сохранить 2^14/2^2 = 2^12 = 4 096 32-разрядных указателей, но только 2 048 64-разрядных указателей. Если производительность Вашего приложения зависит от способности отслеживать по 2K различным буферам, можно видеть реальный выигрыш в производительности от 32-разрядного адресного пространства. Однако самый реальный код не является этим путем, и реальные выигрыши в производительности от кэширующейся системы часто прибывают от способности до кэша общие целочисленные и структуры данных с плавающей точкой, не огромные количества указателей. Если Ваш рабочий набор не тяжел указателем, оборотная сторона 64-разрядных становится незначительной, и позитивный аспект становится намного более очевидным при выполнении большого количества 64-разрядной целочисленной арифметики.

6
ответ дан 18 December 2019 в 10:50
поделиться

Я не думаю Knuth, которому возражают против 64-разрядных систем. Он просто сказал, что использование 64-разрядных указателей в системе, которая имеет поршень меньше чем на 4 ГБ, глупо (по крайней мере, если у Вас есть много указателей как те в двойном связанном списке). Я не могу сказать, что соглашаюсь с ним, вот 3 различных пути, которые могут быть взяты. Давайте предположим, что у Вас есть 64-разрядный способный ЦП, который может также работать в 32-разрядном режиме как некоторый Intel Core Duo.

1 - Все является 32-разрядным, ОС, APPZ, все они. Таким образом, у Вас есть 32-разрядные указатели, но Вы не можете использовать дополнительные регистры/инструкции, которые доступны на 64-разрядном режиме.

2 - Все является 64-разрядным, ОС, APPZ, все они. Таким образом, у Вас есть 64-разрядные указатели, и можно использовать дополнительные регистры/инструкции, которые доступны на 64-разрядном режиме. Но поскольку у Вас есть поршень меньше чем на 4 ГБ, использование 64-разрядных указателей походит глупый. Но, не так ли?

3 - ОС является 64-разрядной, и ОС интересно удостоверяется, что все указатели кода/данных находятся в 0x00000000 - 0xFFFFFFFF диапазон (Виртуальная память!!!). ABI работает очень странным способом, которым все указатели кода/данных, сохраненные в памяти/файлах, 32-разрядные широкий, но они загружаются в 64-разрядные регистры, как расширено до нуля. Если существует участок кода для перехода, компилятор/ABI делает необходимые устранять-взлеты и делает фактический 64-разрядный переход. Таким образом, указатели являются 32-разрядными, но APPZ может быть 64-разрядным значением, что они могут использовать 64-разрядные регистры и инструкции. Этот процесс - что-то как преобразование, я думаю;-P

Мое заключение::

3-я опция казалась выполнимой мне, но это не легкая проблема. В теории это может работать, но я не думаю, что это выполнимо. И я также думаю, что его кавычка, "Когда такие значения указателя появляются в структуре, они не только, тратит впустую половину памяти, они эффективно выбрасывают половину кэша". преувеличен...

4
ответ дан 18 December 2019 в 10:50
поделиться

я видел где-нибудь, что лучшее соединение (на x86 центральных процессорах) должно использовать 64-разрядную ОС и 32-разрядные приложения.

с 64-разрядной ОС Вы добираетесь:

  • способность обработать больше чем 4 ГБ адресного пространства
  • больше, большие регистры для помощи в копирующих данные операциях

с 32-разрядным приложением Вы добираетесь:

  • меньшие указатели
  • меньше, меньшие регистры, чтобы экономить на контекстных переключениях

недостатки:

  • все библиотеки должны быть дублированы. крошечный нормами площади HD.
  • все загруженные библиотеки дублированы на RAM. не настолько крошечный...

удивительно, кажется, не существуют любые издержки при переключении режимов. Я предполагаю, что повреждение от пространства пользователя до ядра стоит того же, неважно, разрядность пространства пользователя.

конечно, существуют некоторые приложения, которые извлекают выгоду из большого адресного пространства. но для всего остального, можно получить дополнительную 5%-ю производительность путем пребывания в 32-разрядном.

и не, я не забочусь об этом маленьком ускорении. но это не "оскорбляет" меня для выполнения 32-разрядного FireFox на 64-разрядной машине KUbuntu (как, я видел на некоторых форумах),

2
ответ дан 18 December 2019 в 10:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: