Есть ли будущее у DELPHI?

Цитата korvin @ 12.01.12, 15:49

Гм... А ты свое утверждение чем доказал?

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

Цитата Повстанець @ 12.01.12, 15:46

Цитата korvin @ 12.01.12, 15:41

Только в отличие от коммунизма реализации «good GC» существуют и в статье они указаны

лисп и смаллталк? Ну-ну.

Вот почему всё лучшее сосредоточено в языках, на которых никто не пишет?

«Лучшее - враг хорошего».

Добавлено 12.01.12, 15:58

Цитата D_KEY @ 12.01.12, 15:54

Цитата korvin @ 12.01.12, 15:49

Гм... А ты свое утверждение чем доказал?

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

О да, весомое доказательство. Как будто только от GC и зависит производительность, ага.

Цитата korvin @ 12.01.12, 15:56

О да, весомое доказательство. Как будто только от GC и зависит производительность, ага.

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

Цитата korvin @ 12.01.12, 15:56

О да, весомое доказательство.

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

Цитата

Как будто только от GC и зависит производительность, ага.

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

Сообщение отредактировано: D_KEY - 12.01.12, 16:05

Цитата MyNameIsIgor @ 12.01.12, 16:02

Но GC всё так же недетерминирован, всё так же сам требует памяти для своей работы.

Это, в общем случае, не влияет на производительность.

Цитата korvin @ 12.01.12, 16:05

Цитата MyNameIsIgor @ 12.01.12, 16:02

Но GC всё так же недетерминирован, всё так же сам требует памяти для своей работы.

Это, в общем случае, не влияет на производительность.

Как это может не влиять на производительность? Почему ты так считаешь?

А каким боком это может влиять? Какая разница, когда именно высвобождается память и каким образом память, занятая ГС влияет?

Цитата korvin @ 12.01.12, 16:20

Какая разница, когда именно высвобождается память

Как минимум, на время сборки(или на время работы какой-то ее части) у тебя будет остановлен "мир", чего не требуется в случае "обычного" освобождения. Опять же, поколения(которые используются в том числе для того, чтобы "остановки мира" были короче) требуют отслеживания ссылок между поколениями в рантайме, что может давать оверхед вплоть до оверхеда RC, если не больше.

Цитата

и каким образом память, занятая ГС влияет?

Ну, например, копирующему сборщику нужно вдвое больше памяти, чем ты зарезервируешь у него для объектов. Мало?

Давай так. Чтобы не говорить о сферическом GC в вакууме, ты приведешь пример "good gc" и распишешь алгоритмы его работы. Ну или дашь соответствующие ссылки.

Сообщение отредактировано: D_KEY - 12.01.12, 16:28

1) как будто ручная сборка не может быть вызвана «в неудачный момент», особенно в многопоточном приложении? На высвобождение памяти в любом случае нужно время, не вижу тут разницы;

2) и каким же образом объем влияет на производительность?

3) их уже упоминали в статье.

Цитата korvin @ 12.01.12, 16:38

1) как будто ручная сборка не может быть вызвана «в неудачный момент», особенно в многопоточном приложении? На высвобождение памяти в любом случае нужно время, не вижу тут разницы;

2) и каким же образом объем влияет на производительность?

3) их уже упоминали в статье.

1) "Ручная" сборка конкретного участка памяти обладает гораздо меньшим оверхедом, чем цикл(или его часть) сборки. И остановкой мира тут и не пахнет.
2) Эм... даже не знаю, с чего начать
3) А ссылки на алгоритмы работы там были? Проглядел наверно. Кроме того, у меня мало доверия к столь древним статьям.

Сообщение отредактировано: D_KEY - 12.01.12, 16:45

Цитата D_KEY @ 12.01.12, 16:42

3) А ссылки на алгоритмы работы там были? Проглядел наверно. Кроме того, у меня мало доверия к столь древним статьям.

Т.е. доверия к классической механике ты тоже не испытываешь?
И что же такого изменилось с тех пор в «теории и практике ручного управления памятью»?

Сообщение отредактировано: korvin - 12.01.12, 19:30

Цитата korvin @ 12.01.12, 19:27

Цитата D_KEY @ 12.01.12, 16:42

3) А ссылки на алгоритмы работы там были? Проглядел наверно. Кроме того, у меня мало доверия к столь древним статьям.

Т.е. доверия к классической механике ты тоже не испытываешь?
И что же такого изменилось с тех пор в «теории и практике ручного управления памятью»?

Мда. Ты хоть помнишь о чем речь была? О конкретных реализациях. Или ты считаешь реализации 14 летней давности актуальными? Я тебя просил привести конкретный "good gc", чтобы было о чем говорить и с чем сравнивать.
Ну или давай обсудим какой-нибудь алгоритм сборки, но конкретный. Иначе о чем вообще разговор?

Цитата

Вот почему всё лучшее сосредоточено в языках, на которых никто не пишет?

Я думаю тут дело в другом - его толком никто не тестировал, поэтому сложилось мнение, что он мол де "хороший". Как то так.

а вообще какие ещё есть языки кроме C, C++, паскаля и Delphi которые компилируюся в реальный машинный код? просветите пожалуйста

Цитата Ahilles @ 13.01.12, 07:36

а вообще какие ещё есть языки кроме C, C++, паскаля и Delphi которые компилируюся в реальный машинный код? просветите пожалуйста

Дальнейшие развитие паскаля от Вирта(Модула2, Оберон, etc.), Ada, D, Go, Ocaml, Haskell и даже лиспы. В общем-то, каких-либо ограничений-то нет, другое дело, что у многих из языков тяжелый рантайм. Но наличие нативного компилятора не является свойством языка.
Кстати, вопрос о необходимости нативной компиляции открыт - LLVM же.