Это так физики в настоящем дискуссию ведут? Забавно.

Ага...

... Весьма потешно. ))) Но что им остаётся делать после выбора Слаки? )))

/* Иэээххх... Шелдона Купера на них нет... ))) */

Нет. В корне не согласен...

... Вопрос «сложности» сводится к наличию поддержки в виде библиотек (ох, пардон, модных нониче «фреймворков») и умения работать с ними. Причём не важно — это самописные либы или какие-то сторонние, писаные другими людьми. В том числе, кстати, и сниппеты, которые просто «скопировал-подтесал».

Например, уж коль скоро мы в теме про Lisp, списки. Неужто думаешь что я буду в 1001 (в почти уже 2013г.) раз ваять себе список? Ну к моим услугам есть реализация списков в GLib, если применение GLib невозможно (на «сервере» это несколько... не физиологично), то есть своя реализация, а есть ещё и http://isis.poly.edu/kulesh/stuff/src/klist/ — описание + пример, http://kernelnewbies.org/FAQ/LinkedLists — описание по-красивее. С остальными ADT (abstract data types) ситуация полностью аналогичная. Есть всё. Просто протяни руку и возьми. С другой стороны, попрошу обратить внимание — я редко выхожу за пределы стандартной системной библиотеки и своего кода, на ней основанного, просто потому, что она, как ни крути, а в системе _должна_ быть. Наличие дополнительных библиотек надо смотреть по возможности их установки и какой оверхед мы можем привнести в систему. Это вопрос. Но, повторюсь, для таких случаев есть собственные реализации.

Открою тебе страшный секрет. С в наши времена это и есть тот самый «портируемый ассембелр», которого все боятся как чёрт ладана. GCC сам по себе достаточно хорош чтобы проводить оптимизации, при которых и оверхед минимален и время, затрачиваемое на программирование задачи не столь велико как на ассемблере. Рекомендую посмотреть на выхлоп компилятора или воспользоваться objdump. Хотя, gas позволяет вытянуть на парочку байт меньше, применять его можно достаточно осторожно — в идеале выводя ассемблерный код в отдельные модули и приглядывать чтобы global register allocation не увалить.

С другой стороны, посмотри на ассемблер для оффтопа от hutch. Там используются инвокабельные функции и структуры данных всё того же WinAPI. И самый короткий ответ на вопрос «why» — «because you can» (http://www.masm32.com/why.htm) А так-то каких-то огромных отличий от С WinAPI, там нет. Кстати, полный апофигей ООП в оффтопе (я так про СОМ-объекты) возможно с 2000г. делать — http://yanaware.com/com4me/createcom.php-author=Ernie MURPHY&mail=ernie@s... В коде на масм можно и сторонние СОМ-объекты использовать. Ну и погляди в поставке M$ Dev(il)Studio (только не в Express) — там где-то должен валяться ml.exe. Я глянуть не могу — у меня этого нет, но я буду удивлён если M$ прекратит поставки masm. ;)

GC как были медленными и неэффективными, так и остались. Уж прости, но это очевидная вещь. Это просто у нас процы подразогнались. ;) GC в Linux относится к run-time user process. Т.е., как ни исхитряйся, а это пользовательский процесс в пределах пользовательского процесса. И системе на него положить с прибором. Потому как менеджер памяти, относящийся к run-time пользовательского процесса и который отвечает за работу пользовательского приложения-системы в части управления памятью (и реализованный в пределах стандартной библиотеки), о нём ни чего не знает. Для менеджера памяти все действия GC выглядят как действия программиста, освободившего какую-то область памяти. Т.е., в данном случае, GC делает за тебя твою работу. Кстати, GC для той же JVM надо бы ещё подтюнить — http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Это, по-моему, несколько сложнее, чем просто использовать приведённый выше Сишный вариант. Я бы согласился с тем, что GC эффективен, если бы он был реализован на уровне стандартной библиотеки и планировщик системы имел бы чёткие инструкции не переключать контекст процесса до тех пор, пока GC не закончит свою работу, чтобы система получила память назад гарантированно. Но пока есть то, что есть — планировщику по-хрен и он переключает контекст, менеджеру памяти по-хрен, он не возражает. А вот сделал GC свою работу или нет, это ни кого не гребёт. Какая тут «эффективность»? Её тут и близко нет. Чудес не бывает. ;)

Для менеджера памяти все действия GC выглядят как действия программиста, освободившего какую-то область памяти.

Что за чушь ты несешь? Где ты видел GC, которые бы отдавали системе то, что ранее было mmap-нуто? Если GC чего забрал, то это уже навсегда. Для того в JVM всегда стоит ограничение на размер heap.

чёткие инструкции не переключать контекст процесса до тех пор, пока GC не закончит свою работу, чтобы система получила память назад гарантированно

Ты на всю свою тупую голову безнадежно болен. Прошу тебя, никогда, никогда больше не программируй. Не твоё это.

ЛОР - не лучшее место для проведения дискуссий. И не дай бог, вам раскрывать свои мысли. По теме не отвечу. Сейчас много работы. Что касается GC, то теперь уже я не согласен с некоторыми выводами, но оставлю это при себе.

... Да Вы, сударь, нониче просто фееричны.

В Вашем хелоуворлде дело просто не доходит до освобождения ресурсов. Он заканчивает свою работу. ))) Если бы Вы хоть слегка были бы знакомы с приложениями 365*24, то с легкостью бы заметили что GC приходится возвращать память. Иначе Ваше приложение при увеличении нагрузки просто выжрало бы всю доступную память. И да, при продемонстрированном подходе, смысла в GC просто не видно.

Если проще, то не стоило бы Вам советовать что мне делать и я бы не отправил Вас воооон туда ==>

По слухам, «на хуй» именно там. В остальном, я бы на Вашем месте, посмотрел бы на практически любой отладчик и научился бы им пользоваться. А потом бы лез к дяденькам рассказывать сказки. С удовольствием бы послушал про то, как именно система не переключает контексты, про то, как именно GC наглым образом не возвращает память, про то, как это вообще все организовано.

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

Ну да... )))

... В России вообще мало мест для дискуссий. Дума вот не место для дискуссий. ЛОР... )))

Как будет угодно. Мне довелось, к сожалению, поколупаться в поиске «нужных вещей» в бинарях посредством отладчика. В нескольких VM (и не только VM), так что, как угодно. Меня вряд ли удастся переубедить. ))) Тут сын ошибок трудных, ни какой «религии».

Впрочем я, пожалуй, тоже восвояси подамся. Удачи, спасибо за общение.

Ты просто редкостно невменяемое ничтожество.

Повторяю для недоносков: GC системе память не возвращает. Потому что GC - говно.

Иначе Ваше приложение при увеличении нагрузки просто выжрало бы всю доступную память.

Ты хоть понимаешь, что такое GC, недоносок?

Ты в курсе, что большинство GC еще и не компактифицируют кучу, так что память системе они не могли бы отдавать даже если бы захотели?

Так что, школота, вали отсюда. Ты неграмотен и туп.

Придурок, на кой лазить в бинарную VM отладчиком? Скачай исходники HotSpot, мразь, и читай, пока не дойдет.

То есть физика изучает законы изменения различных физических величин во времени.

Ну дык правильно f(t) - же! Лиспы - оне от бога, а ваши эти недо-йезыки ... от мартышек :-р

... «Идите сюда, бандерлоги...» (с) то ли Удав Каа, то ли ВладимирВладимирович, не помню уже... )))

Громко напейсано, громко... Шрифт какой-то пляшущий... Ндассс... Видимо, насчёт баттхёрта я был прав. А теперь продолжим Ваше, господин хороший (или господа, если вас таки двое) образование, которое вы недополучили в своей косячной в духе современности «верхней школе». )))

Итак. Вы изволили рассуждать про GC, к сожалению не уточнив какой именно GC Вы поимели ввиду. Это ошибка, т.к. любому даже полному и конченному Java-программисту по идее должно быть известно что их более чем один. ;) Вот Вам документец — http://www.stefankrause.net/wp/?p=14 Результаты вполне воспроизводимые, класс там приведён. В двух из четырёх случаев там да, память не возвращается. В двух — возвращается.

Но только полный, хронический долб... эээ... «российский программист» не понимает что поведение системы, при котором она статична в части использования ресурсов это смерть для такой системы. Причина очевидна, я даже уже написал выше, не будем на ней останавливаться (хелоуворлдов это не касается — там потребляемые ресурсы ничтожны, так что их тематику можно просто пропустить). Но странно то, что Вы даже не помянули про различные варианты GC в пределах одной Java. Вы... о них не знали?

Ну и до кучи я хочу обратить Ваше внимание на поведение похапе. Оно очень сильно Вас может разочаровать. Мне было не сложно найти свои же постинги. Вот тема — Как считается память, используемая php-скриптом?

Не соблаговолите ли объяснить что это там за munmap'ы в выводе strace болтаются? И к чему они здесь, ведь по Вашим же словам, «то, что раз mmap'нуто, то больше не unmap'ается» (или как-то так, не хочу дословно цитировать этот бред)?

Если ещё вспомнить о не упоминавшемся здесь mono, так там прямо в 2006г. было заявлено (цитирую по http://comments.gmane.org/gmane.comp.gnome.mono.devel/17271):

The new GC engine is a precise, generational, compacting collector. This means that the Mono GC will be able to return memory to the operating system when it no longer needs it.

При всём моём неуважении к C#, mono и прочей подобной хрени, их писали люди, отчётливо понимающие что не только чей-то говнокод будет крутиться на хосте. Ещё там же будут задачи. И, если отдать фиксированно и «на всегда» память, то её в какой-то момент может просто не хватить для чего-то более важного (сюрприз, да?) чем Ваше быдлоподелие.

В сухом остатке по данному пункту. Похапе — возвращает память, mono — возвращает, в Java из четырёх случаев, только два не возвращают. Итого 4 к 2. 4.2, милейший, 4.2... Вам это ни чего не напоминает? Нет? Ну тогда я прямо скажу — ваши усилия по газификации луж (не знаю где Вы их сейчас нашли), увенчались 4.2. Впрочем, это и ожидаемо. Уж больно баттхёрт велик был... Глаза застит. )))

=========

Касаемо «скачать HotSpot и вкурить сырцы»... Бедный Вы бедный... Да как же Вас, без знания того, что существует два подхода к анализу кода/системы из этой вашей бурсы-то выпустили (в таком случае — почему на Вас намордник не надели)? И Вам не объяснили что сырцы конкретной прикладной части в случае анализа поведения связки прикладная часть <-> системная Вам нужны весьма относительно?

Уважаемый баклан, специально Вам объясняю. Есть два подхода к анализу кода. Первый — статический анализ (splint/rats/...) и второй — динамический анализ (valgrind/gdb/strace/...). Есть дополнение ко второму — использование фаззеров (spike/pearch fuxzing toolkit/...). Вас, умишком скорбного, не научили ими пользоваться и по этой причине Вы не понимаете простой вещи — всем по-хрену что Вы там напейсали и что там у Вас на localhost творится. Важно то, что произойдёт когда кто-то возжелает стрельнуть по-боевому. По этой причине Вы не понимаете что произойдёт в случае, если _до_ Вас кто-то найдёт уязвимость в Вашем драгоценном коде, который Вы столь трудно изволили напейсать (скодерасилось Вам не в добрый час). ;)

... В качестве дополнения, пожалуй. По mono. Как-то не хорошо на 2006г. ссылаться. Сейчас там вроде некий SGen используют? Так вот тут — http://mono-project.com/Compacting_GC прямо сказано:

When an object has been determined to be unused, the memory is returned to the operating system immediately (this is possible because the memory is allocated using get_os_memory as opposed to the regular malloc from the C runtime).

Всё верно. С runtime, и как можно быстрее отдать неиспользуемые области памяти. Видимо только в России, в силу ея духовности, распределение памяти в системе Святым Духом, самолично производится. У всех нормальных людей для этого задействуется С runtime.

Продолжать будем? Если «да», то запасайтесь вазелином, теффочки... )))

up! Интересно же!