Как технарю из России стать программером в США за 150К

[crypto5]

Я нигде не писал про "memory manager более продвинутый", я дискутировал на тему одной фичи: реализации отдельных куч для каждого потока, которая судя по графикам tcmalloc и jemalloc дает хорошие бенефиты в многопоточных нагруженных приложениях, поэтому все тирады по поводу андроида, умных указателей, сборщика мусора и т.д. тут не причем.

[Boriskin]

Поэтому учите основы, ребята...

Шшшшшшш, не надо им ничего учить.
Пусть и дальше с индусами конкурируют.

[mr. Hide]

Только про локальное кеширование памяти потоками говорилось с самого начала а не "в результате выяснилось", ссылку на "аналогичный memory manager для С++" привел я значительно раньше вас в этом топике, ну и ссылка на мой взгляд доказывает что джава как раз двигается в правильном направлении, и С++ тут в роли догоняющего.

Просто забавное утверждение. У языков разные ниши, и они друг за другом не гоняются, совсем. Реализация memory manager и вовсе перпендикулярна языку.

[crypto5]

Только про локальное кеширование памяти потоками говорилось с самого начала а не "в результате выяснилось", ссылку на "аналогичный memory manager для С++" привел я значительно раньше вас в этом топике, ну и ссылка на мой взгляд доказывает что джава как раз двигается в правильном направлении, и С++ тут в роли догоняющего.

Просто забавное утверждение. У языков разные ниши, и они друг за другом не гоняются, совсем. Реализация memory manager и вовсе перпендикулярна языку.

Ниши очевидно пересекаются, и очевидно некоторые фичи мемори менеджера очень завязаны на особенности языка(Garbage Collector), ну и все это не отменяет тот факт что при реализации компиляторов и виртуальных машин могли и использовались разные подходы, которые имеет смысл сравнивать.

[mr. Hide]

Ниши очевидно пересекаются, и очевидно некоторые фичи мемори менеджера очень завязаны на особенности языка(Garbage Collector), ну и все это не отменяет тот факт что при реализации компиляторов и виртуальных машин могли и использовались разные подходы, которые имеет смысл сравнивать.

А как-то через стандарт языка видны накладки от конкретной реализации memory manager? IMHO, это язык накладывает на эти подсистемы отпечаток, а не наоборот.

У одного garbage collector, у другого heap manager(ы) (которые ещё и разные от опций компиляции-линковки).

[crypto5]

Ниши очевидно пересекаются, и очевидно некоторые фичи мемори менеджера очень завязаны на особенности языка(Garbage Collector), ну и все это не отменяет тот факт что при реализации компиляторов и виртуальных машин могли и использовались разные подходы, которые имеет смысл сравнивать.

А как-то через стандарт языка видны накладки от конкретной реализации memory manager? IMHO, это язык накладывает на эти подсистемы отпечаток, а не наоборот.

У одного garbage collector, у другого heap manager(ы) (которые ещё и разные от опций компиляции-линковки).

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

[mr. Hide]

Ну никак C++ с Java на перегонки бегать не могут, и сравнивать garbage collector с memory heap мы не можем. Они в разных направлениях двигаются, если на то пошло.

[crypto5]

И так, ну никак C++ с Java на перегонки бегать не могут, и сравнивать garbage collector с memory heap, не могут. Они в разных направлениях двигаются, если на то пошло.

А можете озвучить эти направления, ну что бы мы об одном и том же говорили?

[mr. Hide]

И так, ну никак C++ с Java на перегонки бегать не могут, и сравнивать garbage collector с memory heap, не могут. Они в разных направлениях двигаются, если на то пошло.

А можете озвучить эти направления, ну что бы мы об одном и том же говорили?

Первое - там смайлик.

Таки направление движения для C++: http://www2.research.att.com/~bs/C++0xFAQ.html

Я хотя и пишу кое-что на Джаве для Андроида, но не могу отослать на серьёзный источник по Джаве. Ибо не люблю Жабу, просто признаю удобство для своих задач.

[crypto5]

И так, ну никак C++ с Java на перегонки бегать не могут, и сравнивать garbage collector с memory heap, не могут. Они в разных направлениях двигаются, если на то пошло.

А можете озвучить эти направления, ну что бы мы об одном и том же говорили?

Первое - там смайлик.

Таки направление движения для C++: http://www2.research.att.com/~bs/C++0xFAQ.html

Я хотя и пишу кое-что на Джаве для Андроида, но не могу отослать на серьёзный источник по Джаве. Ибо не люблю Жабу, просто признаю удобство для своих задач.

Я думал вы про области применения говорите..

[Abappy]

Язык требует больше дисциплины и понимания основ. Поэтому учите основы, ребята...

Да! (Засучивая рукава) Кто-то тут ещё не согласен с тем, что самые эффективные программы можно написать ТОЛЬКО в машинных кодах (ну в крайнем случае на ассемблере, хотя и это уже профанация) ... а ?

[hogzie]

Я нигде не писал про "memory manager более продвинутый", я дискутировал на тему одной фичи: реализации отдельных куч для каждого потока, которая судя по графикам tcmalloc и jemalloc дает хорошие бенефиты в многопоточных нагруженных приложениях, поэтому все тирады по поводу андроида, умных указателей, сборщика мусора и т.д. тут не причем.

Все при том. Суть одна. По определению сделать что-то более эффективным на уровне выше невозможно. В лучшем (и частном) случае можно сделать одинаково эффективно. Но не более того. Ходить по кругу не буду.

[hogzie]

Язык требует больше дисциплины и понимания основ. Поэтому учите основы, ребята...

Да! (Засучивая рукава) Кто-то тут ещё не согласен с тем, что самые эффективные программы можно написать ТОЛЬКО в машинных кодах (ну в крайнем случае на ассемблере, хотя и это уже профанация) ... а ?

Никто не против. И основы в виде архикектуры CPU и GPU (желательно) тоже никто не отменял. Если уж взялся за ремесло, копай до конца. За ассемблер можно в лоб получить. Это святое.

[crypto5]

Я нигде не писал про "memory manager более продвинутый", я дискутировал на тему одной фичи: реализации отдельных куч для каждого потока, которая судя по графикам tcmalloc и jemalloc дает хорошие бенефиты в многопоточных нагруженных приложениях, поэтому все тирады по поводу андроида, умных указателей, сборщика мусора и т.д. тут не причем.

Все при том. Суть одна. По определению сделать что-то более эффективным на уровне выше невозможно. В лучшем (и частном) случае можно сделать одинаково эффективно. Но не более того. Ходить по кругу не буду.

Какой уровень выше? Или Вы считаете что менеджер памяти в JRE имплементирован на джава?

[Abappy]

По определению сделать что-то более эффективным на уровне выше невозможно. В лучшем (и частном) случае можно сделать одинаково эффективно. Но не более того. Ходить по кругу не буду.

Со всем уважением - это именно в частном случае - "абсолютно эффективной" реализации сделать на уровне выше ЛУЧШЕ чем на уровне ниже - невозможно. А в нашем несовершенном мире заполненном людьми с разной степенью искривления конечностей, используемых ими для написания кода - на ура (готов спорить на любые деньги, что самый совершенный на сегодняшний момент мемори менеджер ни разу не интегрирован в чипсет и даже не написан на ассемблере )