Python: числа хранятся в стеке или в куче?

Всё в куче. Но маленькие целые числа (в какой-то версии было от 0 до 100, емнип), True, False и None — кешируются и не создаются больше одного раза.

В стеке, AFAIK.

В гугле.

Всё в куче

В стеке

В гугле

Вы уж определитесь, пожалуста!

Угу. Желательно пруфлинком

python everyth

Is everything an object in python like ruby? - Stack Overflow
stackoverflow.com/.../is-everything-an-obje... - Перевести эту страницу
Ответов: 6 - 14 май 2009
I did google. I may not have searched right. I read on another Stack ... DiveIntoPython - Everything Is an Object. Everything in Python is an object, ...

2.4. Everything Is an Object - Dive Into Python
http://www.diveintopython.net/...python/everythi... - Перевести эту страницу
Everything Is an Object. 2.4.1. The Import Search Path · 2.4.2. What's an Object? In case you missed it, I just said that Python functions have attributes, and that ...

python number obj

Plain Integer Objects — Python v2.7.3 documentation
docs.python.org/c-api/int.html - Перевести эту страницу
The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back ...

С английским хреново или идиот?

С английским хреново или идиот?

Одно другому не мешает.

маленькие целые числа (в какой-то версии было от 0 до 100, емнип), True, False и None — кешируются и не создаются больше одного раза

Ага. Для повышения производительности при работе с маленькими числами (от 0 до 100) эти числа кешируются в памяти и для доступа к ним используются 64-х битные указатели. Точно-точно, всё так и должно быть.

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

А так, даже питонячий стек хранится в куче О_О.

А так, даже питонячий стек хранится в куче О_О.

Вопрос был в том, придется ли за числами из одной кучи в другую прыгать, и занимается ли ими GC. Но, похоже, «да» в обоих случаях

А что у Вас за две кучи? GC зантмается ес-но.

А что у Вас за две кучи?
А так, даже питонячий стек хранится в куче О_О.

итого сначала смотрим стек(который в куче) а потом идём по ссылке в другое место в куче чтоб получить значение, вместо того чтоб сразу из стека значение взять.

Все еще хуже, поскольку каждый кадр стека это хэш-таблица (если идет обращение к переменной). Хотя что то там питон умеет оптимизировать.

Но я не понимаю, почему Вас это заботит? Питон как бы не для высокопроизводительной математики отнюдь написан, и требования к производительности стоят на самом последнем месте. Если Вы в это уперлись - значит Вы делаете что то не то/не теми средствами. Если уж так хочется скорости - переписываете узкое место на каком нить более производительном языке и вызываете его из питона как библиотечную функцию.

Но я не понимаю, почему Вас это заботит?

чисто академический интерес. В java числа вроде бы в стеке хранятся, вот я и удивился, что в питоне по-другому.

Если говорить про числа в выражении вида а+1, то да - числа на стеке, а стек в куче, под управлением питонячьей машины. Но вообще то с точки зрения ОС что стек что куча один фиг. И то и то обычная память, которая кэшируется и тд и тп.

В яве думаю аналогично (не явист, но по другому это не сделать вроде).

ЗЫ Ява тоже не для высокопроизводительных вычислений.

А так, даже питонячий стек хранится в куче О_О.

Пруфлинк же!

Но вообще то с точки зрения ОС что стек что куча один фиг.

Это понятно, меня смущает «лишний» переход из стека куда-то ещё ради int например

Для повышения производительности при работе с маленькими числами (от 0 до 100) эти числа кешируются в памяти и для доступа к ним используются 64-х битные указатели.

На сколько я понял, речь о том что мелкие числа persistent, т.е. не создаются и не уничтожаются. Экономия на конструкторах/деструкторах и вызове алокатора.

Пруфлинк же!

По логике так и есть: питонячий стэк это набор фреймов каждый из которых это объект. А объекты живут в куче.

По логике так и есть: питонячий стэк это набор фреймов каждый из которых это объект

Stackless Python is a reimplementation of the PythonLanguage that doesn't use the native (or so-called «C») runtime stack to represent the virtual machine stack.

В яве думаю аналогично (не явист, но по другому это не сделать вроде).

В яве целые и вещественные числа хранятся в стеке, потому как язык статически-типизированный. Кстати, вычисления там быстрые , ибо JIT, но все это пока не начинаешь использовать массивы (проверки на границы) и не начинаешь промахиваться по кешу процессора (там ни хрена не поймешь, как расположены могут быть объекты в памяти, ибо автоматическая дефрагментация и прочие вещи, связанные с GC).

Проблема в питоне в его динамической типизации. Аналогичная проблема есть в CL. Только там короткие целые помещаются в стек (оптимизация для типа fixnum), на 64-битных реализациях single float тоже помещается в стек, а вот double float уже на современных интеловских процессорах идет через кучу. Все дело в том, что число должно быть «приведено к указателю», а у последнего всего лишь 32 или 64 бита. Для различения коротких целых их маркируют специальными тегами (сколько-то первых бит, кажется, три). В принципе, так же могли бы сделать в питоне, но тогда бы диапазон целых пришлось уменьшить (занимают теги).

Хз, из этого я понял что стэк таки на heap: http://tech.blog.aknin.name/2010/07/22/pythons-innards-interpreter-stacks/

Логика та же: фреймы это обычные питонячью обьекты.

python virtual machine

тут абберация терминов.

А в другом случае смущало бы то, что в стеке рядом с каждым значением валялся бы признак «int это или объект», и все только ради int'ов на стеке. А так он унифицированно валяется в самом объекте.

Хз, из этого я понял что стэк таки на heap: http://tech.blog.aknin.name/2010/07/22/pythons-innards-interpreter-stacks/

http://zope.stackless.com/spcpaper.htm