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

[zzhou]

И по вашему его невозможно реализовать на С++?

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

Т.е. написать библиотеку умных указателей на С++ можно. Я уверен что многие сишники за неё радостно возьмутся - в рамках разработки рабочего места кассира. И угробят на доводку этого менеджера памяти времени больше чем на само рабочее место кассира.

И их реализация всё равно будет глючить и тормозить по сравнению с реализации в JVM. Которая работает в любой программе на Яве.

[ddv]

Я считаю что юзерспейс менеджер памяти вполне реально реализовать используя к примеру только Posix API, который ничего не знает о том как реализованы треды.

А как же POSIX thread APIs?

А, вот нашел, фейсбук таким занимался: http://www.facebook.com/notes/facebook- ... 0222803919.

Только похоже что даже они сами после их исследований так до конца не поняли помогает это или нет.

[crypto5]

Я считаю что юзерспейс менеджер памяти вполне реально реализовать используя к примеру только Posix API, который ничего не знает о том как реализованы треды.

А как же POSIX thread APIs?

Вы осчусчаете разницу между словами АПИ и детали реализации?

А, вот нашел, фейсбук таким занимался: http://www.facebook.com/notes/facebook- ... 0222803919.
Только похоже что даже они сами после их исследований так до конца не поняли помогает это или нет.

Ну вам виднее конечно, как всегда впрочем,как я вижу.

[ddv]

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

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

[crypto5]

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

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

Ну у вас опять я вижу информация из первых рук

[ddv]

Я считаю что юзерспейс менеджер памяти вполне реально реализовать используя к примеру только Posix API, который ничего не знает о том как реализованы треды.

А как же POSIX thread APIs?

Вы осчусчаете разницу между словами АПИ и детали реализации?

Я вижу что вы сказали о "Posix API, который ничего не знает о том как реализованы треды". А это неправда, потому что "POSIX also defines a standard threading library API". Извините, то не ограничил вашу фантазию упоминанием только нормальных memory manages.. Хорошо что вы не додумались до C++ memory manager который бы вызвал специальный java класс в котором бы небыли реализовани треды...потому что тогда бы он точно ничего о них не знал

[crypto5]

Я считаю что юзерспейс менеджер памяти вполне реально реализовать используя к примеру только Posix API, который ничего не знает о том как реализованы треды.

А как же POSIX thread APIs?

Вы осчусчаете разницу между словами АПИ и детали реализации?

Я вижу что вы сказали о "Posix API, который ничего не знает о том как реализованы треды". А это неправда, потому что "POSIX also defines a standard threading library API". Извините, то не ограничил вашу фантазию упоминанием только нормальных memory manages.. Хорошо что вы не додумались до C++ memory manager который бы вызвал специальный java класс в котором бы небыли реализовани треды...потому что тогда бы он точно ничего о них не знал

В третий раз повторяю, АПИ это АПИ, интерфейс, и он ничего не знает о деталях имплементации.
Вообще, к сожалению вы меня утомили на сегодня, поэтому я со всем согласен, С++ отлично подходит для всех задач, работает в миллион раз быстрее джавы. Желаю вам хорошего викенда.

[ddv]

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

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

Ну у вас опять я вижу информация из первых рук

Ну хорошо..вы сами напросились...выясняется что даже для java такой memory manager не всегда работает хорошо.
http://java.sun.com/docs/hotspot/threads/threads.html

TLEs (in 1.3) or TLABs (in 1.4) are thread local portions of the heap used in the young generation (see the HotSpot Garbage collection Tuning Document). These offer excellent speedups on smaller numbers of threads (100s), but when moving up to larger numbers of threads the thread local heap can consume a significant amount of the total heap, so much so that garbage collection may occur more frequently. You can turn off thread local heaps completely with -XX:-UseTLE in 1.3 and -XX:-UseTLAB in 1.4.

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

[ddv]

Нашел я вам реализацию аналогичного memory manager для С++ http://code.google.com/p/google-perftools/

[zzhou]

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

С каким утверждением вы не согласны (предполагается комманда/один программист одинакового уровня)
1. Рабочее место кассира написанное на Яве будет иметь меньше проблем с утечками памяти, падениями по page fault и т.д.
2. Разработка на Яве займет меньше времени.
3. С точки зрения пользователя это приложение не будет работать медленнее. Может даже и быстрее будет казаться.

Кстати, я все жду когда мне расскажут про утечки ресурсов в ровнонаписанной программе на Яве.

[ddv]

С каким утверждением вы не согласны (предполагается комманда/один программист одинакового уровня)
1. Рабочее место кассира написанное на Яве будет иметь меньше проблем с утечками памяти, падениями по page fault и т.д.
2. Разработка на Яве займет меньше времени.
3. С точки зрения пользователя это приложение не будет работать медленнее. Может даже и быстрее будет казаться.

Да никто не собирается писать место кассира на С++. Никто и не спорит что его надо делать на RAD средствах, и это была их ниша, а не С++. Но для Windows Java я бы не выбрал, т.к. мне не нравится то что каждому придется ставить отдельную JVM...а вот .NET/Delphi вполне.

[Abappy]

Нашел я вам реализацию аналогичного memory manager для С++ http://code.google.com/p/google-perftools/

ddv, простите, я тут нить рассуждений потерял в перепалке. Вы этот пример привели как доказательство того, что потребность в memory manager для C++ есть, а значит java работает быстрее?

[ddv]

Нашел я вам реализацию аналогичного memory manager для С++ http://code.google.com/p/google-perftools/

ddv, простите, я тут нить рассуждений потерял в перепалке. Вы этот пример привели как доказательство того, что потребность в memory manager для C++ есть, а значит java работает быстрее?

Началось все с высказывания о том что Java memory manager лучше чем C++ memory manager

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

Я возразил что на С++ можно это сделать, хотя и скорее всего бесполезно. Сомной не согласились, и попросили предоставить такой memory manager. но так как никто не смог толком объяснить чем же так уникален Java memory manager, то мы начали выяснять действительно ли он такой уникальный, если да то нужен ли он С++ и почему его якобы нельзя написать...В результате выяснилось что имеется ввиду java local thread heap и я нашел аналогичный memory manager для С++

[Abappy]

Началось все с высказывания о том что Java memory manager лучше чем C++ memory manager

а можно узнать как вообще сравнивать элементы функциональности разных языков ?

[crypto5]

Я возразил что на С++ можно это сделать, хотя и скорее всего бесполезно. Сомной не согласились, и попросили предоставить такой memory manager.

А можно точную цитату где я вас такое просил? А то мне кажется что вы опять фантазируете.

[ddv]

Я возразил что на С++ можно это сделать, хотя и скорее всего бесполезно. Сомной не согласились, и попросили предоставить такой memory manager.

А можно точную цитату где я вас такое просил? А то мне кажется что вы опять фантазируете.

А если просмотреть ветку? 14 страница топика

Posted: 11 Feb 2011 11:26:
Можно пруфлинк про такой менеджер памяти?

[crypto5]

Я возразил что на С++ можно это сделать, хотя и скорее всего бесполезно. Сомной не согласились, и попросили предоставить такой memory manager.

А можно точную цитату где я вас такое просил? А то мне кажется что вы опять фантазируете.

А если просмотреть ветку? 14 страница топика

Posted: 11 Feb 2011 11:26:
Можно пруфлинк про такой менеджер памяти?

Да, согласен, просил.

[crypto5]

Нашел я вам реализацию аналогичного memory manager для С++ http://code.google.com/p/google-perftools/

ddv, простите, я тут нить рассуждений потерял в перепалке. Вы этот пример привели как доказательство того, что потребность в memory manager для C++ есть, а значит java работает быстрее?

Началось все с высказывания о том что Java memory manager лучше чем C++ memory manager

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

Я возразил что на С++ можно это сделать, хотя и скорее всего бесполезно. Сомной не согласились, и попросили предоставить такой memory manager. но так как никто не смог толком объяснить чем же так уникален Java memory manager, то мы начали выяснять действительно ли он такой уникальный, если да то нужен ли он С++ и почему его якобы нельзя написать...В результате выяснилось что имеется ввиду java local thread heap и я нашел аналогичный memory manager для С++

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

[Kolbasoff]

Только про локальное кеширование

Кстати, о кэшировании... Умные люди говорят, что это очень плохо, когда цена изделия на вашем сайте попадает в кэш Гугла и прочих поисковиков. Потому что потом цену трудно увеличить, если пошел спрос - вылезает старая цена и возникают глупые вопросы, типа: почему вчера были по 3, а сегодня по 5?. Не менее умные люди говорят, что не показывать цену тоже неправильно, покупатель хочет знать цену сразу, а не звонить и писать письма. Вопрос: как бы и на елку залезть, и попку не ободрать? Прилепить цену как image? Или написать хитрый скрипт, который будет рисовать цену только если домен совпадает с вашим? Знаете ли вы какие-нить решения на эту тему?

[crypto5]

Только про локальное кеширование

Кстати, о кэшировании... Умные люди говорят, что это очень плохо, когда цена изделия на вашем сайте попадает в кэш Гугла и прочих поисковиков. Потому что потом цену трудно увеличить, если пошел спрос - вылезает старая цена и возникают глупые вопросы, типа: почему вчера были по 3, а сегодня по 5?. Не менее умные люди говорят, что не показывать цену тоже неправильно, покупатель хочет знать цену сразу, а не звонить и писать письма. Вопрос: как бы и на елку залезть, и попку не ободрать? Прилепить цену как image? Или написать хитрый скрипт, который будет рисовать цену только если домен совпадает с вашим? Знаете ли вы какие-нить решения на эту тему?

google for robots.txt

[mitnlag]

robots.txt не может банить часть страницы от индекса.

Мало ли, что вчера так, сегодня так. Пусть не парится, ящщетаю. С такими проблемами и в живом магазине сталкиваешься - приходят со вчерашним прайс-листом, и начинается. Но это не фатально и краткие объяснения всегда спасают. Причем дежурными фразами.

[Kolbasoff]

robots.txt не может банить часть страницы от индекса.

Мало ли, что вчера так, сегодня так. Пусть не парится, ящщетаю. С такими проблемами и в живом магазине сталкиваешься - приходят со вчерашним прайс-листом, и начинается. Но это не фатально и краткие объяснения всегда спасают. Причем дежурными фразами.

Как мне объяснили, дежурными фразами можно объяснять пока не вышел на продажи через дилеров, а без продаж через дилеров любой бизнес - это просто вышивание крестиком, хобби. Дилер накручивает процентов 50, а то и 100 от цены изготовителя, ему иначе не интересно. Перед тем, как взять на себя продажи, дилер, в том числе, гуглит историю продаж этого продукта и если видит, что это кто-то продавал за меньшую цену, чем та, которая интересна ему, он не поставит продукт к себе на полку. Мне это рассказал чувак, который в прошлом году вышел на $10М оборота (электроника). Он также сказал, что поставить сначала завышенную цену гораздо правильнее, чем заниженную, как это не пародоксально звучит. Потому что можно потом потихоньку снижать цену, и покупатель будет думать, что имеет дил. А вот повышать цену у того же продукта гораздо труднее, практически невозможно. С другой стороны, если поставить слишком большую первоначальную цену, то никто не купит, и дилер, не найдя отзывов и обсуждений продукта, тоже не поставит к себе на полку. Вот такое вот Си-Плас-Плас, понимаешь...

[crypto5]

robots.txt не может банить часть страницы от индекса.

Ну да, пусть банят всю страницу с ценами.

[agrippina]

robots.txt не может банить часть страницы от индекса.

А если часть страницы заключена в iframe?

[hogzie]

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

Интересно, а в гугле только Вы или другие в вашей команде тоже считают, что в Java "memory manager более продвинутый" безотносительно к применению языка? Сдается мне, что что-то в консерватории надо менять. Это я не исходя из топика, а по мотивам борьбы с андроидным NDK. Особенно в разрезе истории Андроида, когда в начале все считали, что dalvik - это наше все, и чуть не были кастрированы разработчиками игр и мультимедийных приложений. Мы, кстати, уже полгода кастрируем в изварщенной форме вашего главаря по Multimedia Framework Дейва Спаркса. Спасибо, что начиная с 2.2 хотя бы они перешли на полусвой stagefright, сильно недоделанный, но все-таки. Но глюки у него реально анекдотичные. Например, в симуляторе можно запускать сколько угодно меди плееров. Естественно, на железе это не поддерживается (пока), причем ограничение энфорсится в высокоуровневом коде, который написан каким-то студентом на Жабе. Рекомендую попробовать и посмотреть на ошибку, которую этот код выкидывает.
Топик мне нравится. Правильный топик. Наверное уже 100-й холивар Си++ vs Java за историю привета. Причем ярые противники Си++ язык опонента знают только по беглому чтению книг и рассказам в курилках. Где-то слышали про страшный memory management, но не знают, как он работает. Ребята, вы поймите, что smart pointer'ы - это еще не memory manager. Писать с нуля reference counting при наличии готовых mature библиотек никому не придет в голову, если только на то не будет большой необходимости. Скажем, если вам нужен эффективный менджер для маленьких объектов, то сделать на Жабе его практически невоможно. Точнее, нельзя сделать универсальный менеджер. Точка. На Си++ вы можете реализовать свой аллокатор, и он будет работать одинаково эффективно везде. Это один частный пример. Про сборщик мусора мы как-то уже говорили тут несколько месяцев назад.
Сказки про страшных бородатых программистов, пишущих frameworks на Си, сильно преувеличены. Любая "продвинутость" memory manager'а Жабы определяется не удачной архитектурой языка, а наоборот, - это средство борьбы с его deficiencies. Пока memory manager не начнет понимать исходные тексты на уровне человека, никакая автоматика не будет на столько же эффективна и гранулярна, как низкоровневая имплементация того же самого человеком. Любую дурь можно придумать безотносительно к языку. Отстрелить ногу действительно проще на Си++, никто не спорит. Язык требует больше дисциплины и понимания основ. Поэтому учите основы, ребята...