Банков, которые открывают счёта без личного присутствия в мире мало
Не знаю как в мире, а в Германии в последние годы очень много банков стали предлагать услугу открытия счёта удалённо (видеоидентификация) — это почти на поток поставлено. В худшем случае можно заполнить бумажки и отправить подписанными, ходить никуда не надо, единственное условие — нужно быть резидентом в Германии.
в рамках ЕС проблем с тем, чтобы лично куда то придти, даже в другой стране, я откровенно говоря не вижу
Это пока вам не заблокируют счёт и не скажут явится лично в офис в этой самой другой стране для "проверки документов и подтверждения легитимности" (и это через почти 10 лет обслуживания) — я уже натыкался на это пару раз, с банками в Голландии и Швейцарии, хорошо хоть в моём случае это не основные счета были, ладно Голландия под боком, а вот со Швейцарией получилось очень печально — и время, и деньги.
"до сих пор" это у тех кто поленился и не отказался от бумажек. Я уже давно их не получаю ни от кого — ни от банков, ни от провайдеров, ни даже от страховок или поставщиков газа и электроэнергии.
Если же человек явно на email не хочет перейти, или не разрешил/указал использование email — они обязаны слать письма, заставить использовать email никто не может (хотя иногда за бумажные письма берут деньги, явно или не очень — это лучше работает).
С точки зрения пользователя (минус время на возврат в обычный режим) — никакой разницы, для него комп "спит", а где он спит — не особо важно (пока можно разбудить, разумеется).
Последний, кстати, основан на UDP, так что не надо про критичные сервисы.
http/3 (если вы про quic) не основан на UDP а использует его в качестве транспорта, в статье же речь шла о "чистом" UDP. Разумеется, если ваше приложение само заботится о гарантиях доставки то хоть голубями можно это делать.
Это не всегда работает. У меня был клиент у которого приложение постоянно убивалось из-за недостатка памяти, в ответ на ествественный совет докупить памяти он упорно отмахивался — "ну рестартанет, не проблема". Приложением было mysqld.
Остаётся надеяться что эта функция (если будет реализована) будет исключительно опциональной и останется возможность явной активации (причём желательно кнопкой).
И ни один из представленных тулзов не показывает достаточно важные метрики — backlog (время ожидания запросов в очереди) или среднее время выполнения операций.
Вообще-то довольно уверен — за всю мою практику (это как минимум 30 лет) порчи корпусов кем-либо не наблюдалось, а вот электроэнергия хоть и очень редко, но всё же довольно регулярно пропадает, и что примечательно, именно тогда когда нужна.
В масштабах офиса я хочу быть уверен что никакя уборщица (или экскаватор) не испортит мне standby, даже если это случается раз в 10 лет.
А миллионы — знаете, если каждый будет думать в масштабах только офиса, то можно вообще не париться экономией — ресурсы планеты ведь неисчерпаемы, правда?
В современных условиях, особенно когда компы не нужны 24/7 — она как раз имеет смысл.
Если речь про офис с кучей компов, которые нужны с 9 до 17 — какой смысл их держать включёнными непрерывно? Это лишние расходы и износ оборудования, причём если оставить их в standby и питание пропадёт — будет неприятно, в отличие от гибернации.
Да и с ноутбуками удобно — если они используются редко, потому что опять-таки standby жрёт батарейку.
Если у вас там открыто куча всего, то не быстрее и уж точно не удобней — а именно этим и удобен спящий режим, по крайней мере в Windows (в Linux постоянно какие-то глюки с гибернацией и спячкой).
Иногда оптимизатор ошибается и результат медленнее чем могло бы быть, или просто не учитывалась архитектура процессора для которого генерился код — это единственное логичное объяснение.
Код который сравним по времени выполнения — ок, ничего удивительного, но вот Java быстрее — это скорее аномалия, вряд-ли могущая проявить себя "в среднем".
Но если вернуться к PHP… боюсь, его JIT ещё предстоит очень долгий путь к тому что достигнуто в Java, так что транскомпиляция в C++ кажется всё же более оптимальным вариантом если нужно здесь и сейчас.
Если вы делегируете кому-то право принимать такие решения, причём этот кто-то не имеет отношения к вашему проекту — вы лишаетесь контроля. В коммерческих проектах это весьма неприемлемо.
В случает, например, Java, производительность кода, порождённого AOT-компиляторами ниже, чем JIT.
Причина этого очень проста — AOT в Java (и ряде других языков, изначально интерпретируемых) не обладает всей "мощью" оптимизаторов которые были созданы для C/C++ (и некоторых других), они были расчитаны просто на ускорение кода, а не глобальную оптимизацию, т.е. внутри это просто аналог JIT, выполняемый до запуска.
Не бывает просто "более быстрого" кода, бывает код, который лучше ведёт себя в тех или иных задачах
Давайте напишем движок для регулярных выражений на C/C++ и Java, а потом посмотрим — кто из них быстрее в итоге. Когда я говорил о "более быстром коде" — речь шла о результате компиляции. Как я уже говорил выше, JIT (и даже AOT) в Java и других подобных языках работает в пределах одной функции (не уверен даже что инлайн умеет) и лишен ряда оптимизаций, тут вы ничего сделаете (пока не напишите хотя бы компилятор Java в LLVM с последующей прогонкой оптимизатором).
бывают случаи, когда Java уделывает C++ (а бывает и обратное)
Можете привести хотя бы один такой случай как пример? Только при условии что код не использует ничего кроме стандартных возможностей языка, т.е. CPU-bound.
Я ещё ни в реальной жизни, ни в бенчмарках не видел чтобы Java/.net побили C/C++ (при адекватной реализации, разумеется, ляпы не в счёт).
C++ уделывает Java только потому, что первый более низкоуровневый
Это одна из причин, не самая главная (и имеет смысл только если человек пишет код с учётом этого, а не "в лоб"). Самая главная всё же наличие очень оптимизирующих компиляторов. Если мы возьмём сложный (и много) CPU-bound код, напишем его одинаково (минус синтаксис) на C++ и Java то Java проиграет GCC/LLVM при любом раскладе — с AOT или JIT.
Что делать если предложенный RFC таки отклонили, а он важен для подающего? Или просто не имеет ценности для большинства? К тому же мало что-то предложить — предложенное и принятое нужно ещё поддерживать, а это уже несколько иной уровень.
И транспиляция в C/C++ всё же гораздо проще чем годный JIT, плюс в том что почти бесплатно получаем все оптимизации компилятора. А если транспилировать во что-то типа D (там исключительно высокая скорость компиляции и сборки) то можно вообще было на лету это делать.
Commerzbank, Deutsche Bank, Sparkasse — очень традиционные, есть возможность "мгновенного" открытия счёта по видео-чату.
Думаю, в связи с короновирусом почти все это будут делать, а сделав один раз — уже вряд-ли перестанут.
Не знаю как в мире, а в Германии в последние годы очень много банков стали предлагать услугу открытия счёта удалённо (видеоидентификация) — это почти на поток поставлено. В худшем случае можно заполнить бумажки и отправить подписанными, ходить никуда не надо, единственное условие — нужно быть резидентом в Германии.
Это пока вам не заблокируют счёт и не скажут явится лично в офис в этой самой другой стране для "проверки документов и подтверждения легитимности" (и это через почти 10 лет обслуживания) — я уже натыкался на это пару раз, с банками в Голландии и Швейцарии, хорошо хоть в моём случае это не основные счета были, ладно Голландия под боком, а вот со Швейцарией получилось очень печально — и время, и деньги.
"до сих пор" это у тех кто поленился и не отказался от бумажек. Я уже давно их не получаю ни от кого — ни от банков, ни от провайдеров, ни даже от страховок или поставщиков газа и электроэнергии.
Если же человек явно на email не хочет перейти, или не разрешил/указал использование email — они обязаны слать письма, заставить использовать email никто не может (хотя иногда за бумажные письма берут деньги, явно или не очень — это лучше работает).
С точки зрения пользователя (минус время на возврат в обычный режим) — никакой разницы, для него комп "спит", а где он спит — не особо важно (пока можно разбудить, разумеется).
http/3 (если вы про quic) не основан на UDP а использует его в качестве транспорта, в статье же речь шла о "чистом" UDP. Разумеется, если ваше приложение само заботится о гарантиях доставки то хоть голубями можно это делать.
Это не всегда работает. У меня был клиент у которого приложение постоянно убивалось из-за недостатка памяти, в ответ на ествественный совет докупить памяти он упорно отмахивался — "ну рестартанет, не проблема". Приложением было mysqld.
Остаётся надеяться что эта функция (если будет реализована) будет исключительно опциональной и останется возможность явной активации (причём желательно кнопкой).
И ни один из представленных тулзов не показывает достаточно важные метрики — backlog (время ожидания запросов в очереди) или среднее время выполнения операций.
Вообще-то довольно уверен — за всю мою практику (это как минимум 30 лет) порчи корпусов кем-либо не наблюдалось, а вот электроэнергия хоть и очень редко, но всё же довольно регулярно пропадает, и что примечательно, именно тогда когда нужна.
В масштабах офиса я хочу быть уверен что никакя уборщица (или экскаватор) не испортит мне standby, даже если это случается раз в 10 лет.
А миллионы — знаете, если каждый будет думать в масштабах только офиса, то можно вообще не париться экономией — ресурсы планеты ведь неисчерпаемы, правда?
Не проще ли использовать сдельную оплату и не париться насчёт трекеров?
Это "почти" (1-2-3 ватта) умножьте на сотни миллионов устройств, и получите интересные результаты.
В современных условиях, особенно когда компы не нужны 24/7 — она как раз имеет смысл.
Если речь про офис с кучей компов, которые нужны с 9 до 17 — какой смысл их держать включёнными непрерывно? Это лишние расходы и износ оборудования, причём если оставить их в standby и питание пропадёт — будет неприятно, в отличие от гибернации.
Да и с ноутбуками удобно — если они используются редко, потому что опять-таки standby жрёт батарейку.
Если у вас там открыто куча всего, то не быстрее и уж точно не удобней — а именно этим и удобен спящий режим, по крайней мере в Windows (в Linux постоянно какие-то глюки с гибернацией и спячкой).
Я говорил про случай когда она не кончается — т.е. когда её заведомо больше чем может быть нужно.
Иногда оптимизатор ошибается и результат медленнее чем могло бы быть, или просто не учитывалась архитектура процессора для которого генерился код — это единственное логичное объяснение.
Код который сравним по времени выполнения — ок, ничего удивительного, но вот Java быстрее — это скорее аномалия, вряд-ли могущая проявить себя "в среднем".
Но если вернуться к PHP… боюсь, его JIT ещё предстоит очень долгий путь к тому что достигнуто в Java, так что транскомпиляция в C++ кажется всё же более оптимальным вариантом если нужно здесь и сейчас.
Если вы делегируете кому-то право принимать такие решения, причём этот кто-то не имеет отношения к вашему проекту — вы лишаетесь контроля. В коммерческих проектах это весьма неприемлемо.
Причина этого очень проста — AOT в Java (и ряде других языков, изначально интерпретируемых) не обладает всей "мощью" оптимизаторов которые были созданы для C/C++ (и некоторых других), они были расчитаны просто на ускорение кода, а не глобальную оптимизацию, т.е. внутри это просто аналог JIT, выполняемый до запуска.
Давайте напишем движок для регулярных выражений на C/C++ и Java, а потом посмотрим — кто из них быстрее в итоге. Когда я говорил о "более быстром коде" — речь шла о результате компиляции. Как я уже говорил выше, JIT (и даже AOT) в Java и других подобных языках работает в пределах одной функции (не уверен даже что инлайн умеет) и лишен ряда оптимизаций, тут вы ничего сделаете (пока не напишите хотя бы компилятор Java в LLVM с последующей прогонкой оптимизатором).
Можете привести хотя бы один такой случай как пример? Только при условии что код не использует ничего кроме стандартных возможностей языка, т.е. CPU-bound.
Я ещё ни в реальной жизни, ни в бенчмарках не видел чтобы Java/.net побили C/C++ (при адекватной реализации, разумеется, ляпы не в счёт).
Это одна из причин, не самая главная (и имеет смысл только если человек пишет код с учётом этого, а не "в лоб"). Самая главная всё же наличие очень оптимизирующих компиляторов. Если мы возьмём сложный (и много) CPU-bound код, напишем его одинаково (минус синтаксис) на C++ и Java то Java проиграет GCC/LLVM при любом раскладе — с AOT или JIT.
В общем-то от конкретного BIOS зависит. На парочке миникомпов он в упор не видит MBR, увы.
Что делать если предложенный RFC таки отклонили, а он важен для подающего? Или просто не имеет ценности для большинства? К тому же мало что-то предложить — предложенное и принятое нужно ещё поддерживать, а это уже несколько иной уровень.
И транспиляция в C/C++ всё же гораздо проще чем годный JIT, плюс в том что почти бесплатно получаем все оптимизации компилятора. А если транспилировать во что-то типа D (там исключительно высокая скорость компиляции и сборки) то можно вообще было на лету это делать.