EG
Только компиляторы натасканы именно на x86_64
Size: a a a
2020 August 19
A
Кому нужны другие архитектуры и ОС? /s
Apple со следующего года, например.
s
У армов энергопотребление пониже, да сами они проще и дешевле
И тормознее
EG
И тормознее
Сами армы не тормознее, просто под них оптимизировать не умеют
A
А, т.е. получается вопрос сводится к тому, что стек это динамическое алоцирование и деалоцирование данных, но если грубо говоря там будет на стеке 100 чисел, и во время выполнения программы эти 100 чисел будут только изменяться, но не удаляться создаваться, то по сути алокация произойдет только один раз, так же, как если бы выделили любым другим алокатором память и работали бы с памятью дальше?)
EG
Adv0cat
А, т.е. получается вопрос сводится к тому, что стек это динамическое алоцирование и деалоцирование данных, но если грубо говоря там будет на стеке 100 чисел, и во время выполнения программы эти 100 чисел будут только изменяться, но не удаляться создаваться, то по сути алокация произойдет только один раз, так же, как если бы выделили любым другим алокатором память и работали бы с памятью дальше?)
Нет
EG
На стеке можно аллоцировать объекты
Но вот деаллоцировать на стеке можно только N последних аллоцированных объектов одновременно
Но вот деаллоцировать на стеке можно только N последних аллоцированных объектов одновременно
EG
Ты не можешь деаллоцировать отдельно предпоследний
EG
В нормальных языках, типа Rust, место на стеке распределяется статически во время компиляции, но, в целом, это не обязательно
s
В нормальных языках, типа Rust, место на стеке распределяется статически во время компиляции, но, в целом, это не обязательно
Почти во всех языках я бы сказал.
s
Но да, необязательно. В теории.
Э
Почти во всех языках я бы сказал.
>В нормальных
Он же сказал.
Он же сказал.
EG
Почти во всех языках я бы сказал.
C позволяет VLA, и в Asm можно вообще что хочешь творить.
EG
Наверное, C++ тоже можно заставить проглотить, но стандарт, технически, запрещает.
A
Т.е. если аллоцировать на стеке 3 гб, и аллоцировать в куче 3 гб, а потом юзать только изменение этих даных без деалокации, то разницы не будет?
EG
Adv0cat
Т.е. если аллоцировать на стеке 3 гб, и аллоцировать в куче 3 гб, а потом юзать только изменение этих даных без деалокации, то разницы не будет?
Не вижу причины, почему должна быть.
EG
Наверное, C++ тоже можно заставить проглотить, но стандарт, технически, запрещает.
Любой язык, который разрешает вставки на асме, естественно, можно заставить аллоцировать вещи на стеке динамически. Но будет больно.
A
Не вижу причины, почему должна быть.
Всё, понял... А куча и маппед файлы имеют различие какое-то в скорости обработки данных, ну кроме того, что маппед файлы в памяти сразу и на диск пишут значения кроме памяти)))
EG
Adv0cat
Всё, понял... А куча и маппед файлы имеют различие какое-то в скорости обработки данных, ну кроме того, что маппед файлы в памяти сразу и на диск пишут значения кроме памяти)))
В зависимости от того, где находится этот файл
EG
Если файл находится в ramfs, то разница по производительности будет минимальна