Сообщение Re[7]: Что наиболее быстро развивается? Замедлились ли телеф от 29.02.2024 13:48
Изменено 29.02.2024 13:52 Serginio1
Re[7]: Что наиболее быстро развивается? Замедлились ли телеф
Здравствуйте, vsb, Вы писали:
S>> На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска.
S>> Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.
S>>Our Vision for .NET 9
S>> Делается ставка на Native AOT,ИИ.
vsb>Не знаю, что в .NET, но могу предположить, что это связано скорей с быстрым стартом. В Java есть проблема, что у популярного фреймворка старт даже небольшого приложения занимает секунд 10, а большого — там и несколько минут может быть. В то же время в облаках используется концепция эластичности. Это когда приложения запускаются в нескольких экземплярах и число экземпляров зависит от нагрузки на систему. Если на пальцах — запускаем одно приложение. Когда у него нагрузка на CPU вырастает выше 80%, запускаем второй экземпляр и половину запросов отсылаем на второй экземпляр. Если нагрузка растёт и дальше, то третий и тд. А если нагрузка падает, то останавливаем часть экземпляров. Ну и очевидная проблема — нагрузка выросла, а приложению ещё минуту стартовать. А запущенный инстанс уже не справляется и начинается перегрузка сервиса, которая каскадом может пойти по другим сервисам.
Ну для более быстрого старта есть технология NGEN и Компиляция ReadyToRun
vsb>Также на старт влияет и размер приложения. Прежде чем его запустить, сервер его должен скачать. Конечно можно скачивать заранее, тут есть разные подходы, но в общем и целом — чем меньше приложение, тем меньше проблем.
vsb>Вот на фоне вышеописанной ситуации популярность снискал Go, у которого старт мгновенный, образ занимает считанные мегабайты в сравнение с десятками, а то и сотнями у Java. И для решения этой проблемы в Java потихоньку пилят AOT и подобное.
vsb>Вот в .NET подозреваю, ситуация похожая.
vsb>А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.
Native AOT это и есть высокоуровневая альтернатива Go. Все скомпилировано на С++ со сборщиком мусора.
По памяти нет CLR с Jit ом, по процессору С++ компиляция более долгая и опимизирована в отличие от джита
S>> На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска.
S>> Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.
S>>Our Vision for .NET 9
S>> Делается ставка на Native AOT,ИИ.
vsb>Не знаю, что в .NET, но могу предположить, что это связано скорей с быстрым стартом. В Java есть проблема, что у популярного фреймворка старт даже небольшого приложения занимает секунд 10, а большого — там и несколько минут может быть. В то же время в облаках используется концепция эластичности. Это когда приложения запускаются в нескольких экземплярах и число экземпляров зависит от нагрузки на систему. Если на пальцах — запускаем одно приложение. Когда у него нагрузка на CPU вырастает выше 80%, запускаем второй экземпляр и половину запросов отсылаем на второй экземпляр. Если нагрузка растёт и дальше, то третий и тд. А если нагрузка падает, то останавливаем часть экземпляров. Ну и очевидная проблема — нагрузка выросла, а приложению ещё минуту стартовать. А запущенный инстанс уже не справляется и начинается перегрузка сервиса, которая каскадом может пойти по другим сервисам.
Ну для более быстрого старта есть технология NGEN и Компиляция ReadyToRun
vsb>Также на старт влияет и размер приложения. Прежде чем его запустить, сервер его должен скачать. Конечно можно скачивать заранее, тут есть разные подходы, но в общем и целом — чем меньше приложение, тем меньше проблем.
vsb>Вот на фоне вышеописанной ситуации популярность снискал Go, у которого старт мгновенный, образ занимает считанные мегабайты в сравнение с десятками, а то и сотнями у Java. И для решения этой проблемы в Java потихоньку пилят AOT и подобное.
vsb>Вот в .NET подозреваю, ситуация похожая.
vsb>А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.
Native AOT это и есть высокоуровневая альтернатива Go. Все скомпилировано на С++ со сборщиком мусора.
По памяти нет CLR с Jit ом, по процессору С++ компиляция более долгая и опимизирована в отличие от джита
Re[7]: Что наиболее быстро развивается? Замедлились ли телеф
Здравствуйте, vsb, Вы писали:
S>> На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска.
S>> Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.
S>>Our Vision for .NET 9
S>> Делается ставка на Native AOT,ИИ.
vsb>Не знаю, что в .NET, но могу предположить, что это связано скорей с быстрым стартом. В Java есть проблема, что у популярного фреймворка старт даже небольшого приложения занимает секунд 10, а большого — там и несколько минут может быть. В то же время в облаках используется концепция эластичности. Это когда приложения запускаются в нескольких экземплярах и число экземпляров зависит от нагрузки на систему. Если на пальцах — запускаем одно приложение. Когда у него нагрузка на CPU вырастает выше 80%, запускаем второй экземпляр и половину запросов отсылаем на второй экземпляр. Если нагрузка растёт и дальше, то третий и тд. А если нагрузка падает, то останавливаем часть экземпляров. Ну и очевидная проблема — нагрузка выросла, а приложению ещё минуту стартовать. А запущенный инстанс уже не справляется и начинается перегрузка сервиса, которая каскадом может пойти по другим сервисам.
Ну для более быстрого старта есть технология NGEN и Компиляция ReadyToRun
vsb>Также на старт влияет и размер приложения. Прежде чем его запустить, сервер его должен скачать. Конечно можно скачивать заранее, тут есть разные подходы, но в общем и целом — чем меньше приложение, тем меньше проблем.
vsb>Вот на фоне вышеописанной ситуации популярность снискал Go, у которого старт мгновенный, образ занимает считанные мегабайты в сравнение с десятками, а то и сотнями у Java. И для решения этой проблемы в Java потихоньку пилят AOT и подобное.
vsb>Вот в .NET подозреваю, ситуация похожая.
vsb>А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.
Native AOT это и есть высокоуровневая альтернатива Go. Все скомпилировано на С++ со сборщиком мусора.
По памяти нет CLR с Jit ом, по процессору С++ компиляция более долгая и опимизирована в отличие от джита
https://devblogs.microsoft.com/dotnet/performance-improvements-in-aspnet-core-8/
S>> На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска.
S>> Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.
S>>Our Vision for .NET 9
S>> Делается ставка на Native AOT,ИИ.
vsb>Не знаю, что в .NET, но могу предположить, что это связано скорей с быстрым стартом. В Java есть проблема, что у популярного фреймворка старт даже небольшого приложения занимает секунд 10, а большого — там и несколько минут может быть. В то же время в облаках используется концепция эластичности. Это когда приложения запускаются в нескольких экземплярах и число экземпляров зависит от нагрузки на систему. Если на пальцах — запускаем одно приложение. Когда у него нагрузка на CPU вырастает выше 80%, запускаем второй экземпляр и половину запросов отсылаем на второй экземпляр. Если нагрузка растёт и дальше, то третий и тд. А если нагрузка падает, то останавливаем часть экземпляров. Ну и очевидная проблема — нагрузка выросла, а приложению ещё минуту стартовать. А запущенный инстанс уже не справляется и начинается перегрузка сервиса, которая каскадом может пойти по другим сервисам.
Ну для более быстрого старта есть технология NGEN и Компиляция ReadyToRun
vsb>Также на старт влияет и размер приложения. Прежде чем его запустить, сервер его должен скачать. Конечно можно скачивать заранее, тут есть разные подходы, но в общем и целом — чем меньше приложение, тем меньше проблем.
vsb>Вот на фоне вышеописанной ситуации популярность снискал Go, у которого старт мгновенный, образ занимает считанные мегабайты в сравнение с десятками, а то и сотнями у Java. И для решения этой проблемы в Java потихоньку пилят AOT и подобное.
vsb>Вот в .NET подозреваю, ситуация похожая.
vsb>А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.
Native AOT это и есть высокоуровневая альтернатива Go. Все скомпилировано на С++ со сборщиком мусора.
По памяти нет CLR с Jit ом, по процессору С++ компиляция более долгая и опимизирована в отличие от джита
https://devblogs.microsoft.com/dotnet/performance-improvements-in-aspnet-core-8/