Здравствуйте, A13x, Вы писали:

A>Здравствуйте, StanislavK, Вы писали:

A>Мне кажется не совсем корректно так сравнивать, т.к. задача освободить сразу большое количество памяти не стоит. В С-подобных языках с ручным управлением памятью объекты освобождаются сразу как перестанут быть нужными.
Если на то пошло, то сравнивать вообще не корректно. Сравнения подобные этому, в основном используются для измерения размера инструмента.
Смысл имеет исключтьельно сравнения конкретных случаев. Вот я вам дал конктерный случай, где С++ медленнее. И совершенно нет сомнений в том, что можно придумать "корректный" случай когда С++ быстрее. В этом и есть основная идея того, что я пытаюсь тут сказать — нельзя однозначно говорить, что что-то, в общем, говно, потому что это зависит от контекста использования. Нельзя однозначно сказать, что GC — говно, потому что при некоторых сценариях использования могуть быть большие паузы. Да могут быть, но из можно избежать, что не так сложно. В то же время в C++, при некоторых сценариях использования, гораздо больше CPU тратится на выделение и освободжение пямяти и соответственно, throughput будет меньше. Тоже говно?

A>Если нужно удалить сразу все после большого прогона, то нужно сравнивать так (в вашем варианте):
A>И вот тут вариант на С будет самым быстрым.
Ой да? Мне показалось или вы там сами пытаетесь написать аллокатор? Только он ничего не умеет и потому такой из себя быстрый? Так, что давай-ка не будем забывать изначальное условие, то фунциональность должны быть приблизительно эквивалентна.

A>Хочу заметить, что для С++ автоматом вызываются деструкторы, давайте для сравнения повторим ваш прогон для объектов с finalize, например так:
С чего это он будет вызываться у массивов байтов?

A>PS: К сожалению в последнее время невероятно много работы и не удалось поучаствовать поживее в этом обсуждении.
Ой, да ладно!

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, A13x, Вы писали:

A>>Здравствуйте, StanislavK, Вы писали:

A>>Мне кажется не совсем корректно так сравнивать, т.к. задача освободить сразу большое количество памяти не стоит. В С-подобных языках с ручным управлением памятью объекты освобождаются сразу как перестанут быть нужными.
SK>Если на то пошло, то сравнивать вообще не корректно. Сравнения подобные этому, в основном используются для измерения размера инструмента.
SK>Смысл имеет исключтьельно сравнения конкретных случаев. Вот я вам дал конктерный случай, где С++ медленнее. И совершенно нет сомнений в том, что можно придумать "корректный" случай когда С++ быстрее. В этом и есть основная идея того, что я пытаюсь тут сказать — нельзя однозначно говорить, что что-то, в общем, говно, потому что это зависит от контекста использования. Нельзя однозначно сказать, что GC — говно, потому что при некоторых сценариях использования могуть быть большие паузы. Да могут быть, но из можно избежать, что не так сложно. В то же время в C++, при некоторых сценариях использования, гораздо больше CPU тратится на выделение и освободжение пямяти и соответственно, throughput будет меньше. Тоже говно?

Нет, я согласен с этим утверждением. У меня и в мыслях нет защищать как-то С++. Аллокаторы общего назначения на С++ вовсе не идеал. Я лишь хотел подчеркнуть то, что ручное управление памятью, возможное в языках с ручным управлением памятью может быть намного более эффективным с общего отношения потребляемая память/быстродействие. Может быть в будущем, когда появятся языки с развитым region inference-based resource management это будет и скрыто от программиста и эффективно реализовано. Пока надо выбирать меньшее из двух зол и я для себя выбрал яву, поскольку производительности для решаемых задач пока достаточно, а вручную или через smart pointers управлять памятью я не хочу

A>>Если нужно удалить сразу все после большого прогона, то нужно сравнивать так (в вашем варианте):
A>>И вот тут вариант на С будет самым быстрым.
SK>Ой да? Мне показалось или вы там сами пытаетесь написать аллокатор? Только он ничего не умеет и потому такой из себя быстрый? Так, что давай-ка не будем забывать изначальное условие, то фунциональность должны быть приблизительно эквивалентна.

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

A>>Хочу заметить, что для С++ автоматом вызываются деструкторы, давайте для сравнения повторим ваш прогон для объектов с finalize, например так:
SK>С чего это он будет вызываться у массивов байтов?

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

A>>PS: К сожалению в последнее время невероятно много работы и не удалось поучаствовать поживее в этом обсуждении.
SK>Ой, да ладно!

Честно

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, A13x, Вы писали:

A>>Здравствуйте, StanislavK, Вы писали:

A>>Мне кажется не совсем корректно так сравнивать, т.к. задача освободить сразу большое количество памяти не стоит. В С-подобных языках с ручным управлением памятью объекты освобождаются сразу как перестанут быть нужными.
SK>Если на то пошло, то сравнивать вообще не корректно. Сравнения подобные этому, в основном используются для измерения размера инструмента.
SK>Смысл имеет исключтьельно сравнения конкретных случаев. Вот я вам дал конктерный случай, где С++ медленнее. И совершенно нет сомнений в том, что можно придумать "корректный" случай когда С++ быстрее. В этом и есть основная идея того, что я пытаюсь тут сказать — нельзя однозначно говорить, что что-то, в общем, говно, потому что это зависит от контекста использования. Нельзя однозначно сказать, что GC — говно, потому что при некоторых сценариях использования могуть быть большие паузы. Да могут быть, но из можно избежать, что не так сложно. В то же время в C++, при некоторых сценариях использования, гораздо больше CPU тратится на выделение и освободжение пямяти и соответственно, throughput будет меньше. Тоже говно?

Вы пытаетесь переложить свой стиль написания на Java к программам на C++. Но на плюсах так никто не пишет, по крайней мере в частях, где важна скорость (а она здесь важна, раз уж взялись меряться). Все короткоживущие объекты создаются на стеке, скорость выделения и освобождения памяти в котором намного выше, чем в Java. Не тратится время на ненужную инициализацию памяти нулями. И даже стандартные контейнеры зачастую не используются.
Вы пишите, что на Java можно избежать пауз и это не сложно. Но всё это достигается косвенными методами и явным образом не контролируется программистом. А в общем случае вообще не гарантируется.
Паузы в 10-20 мс может и не важны в серверных приложениях. Но если речь идет о программах с пользовательским интерфейсом, то это приводит к тому, что программа начинает "дергаться" и периодически "подвисать", а это жутко бесит пользователей. Возможно, это одна из причин, из-за которых программ с GUI на яве не так много, как ожидалось.

Здравствуйте, Аноним, Вы писали:

А>Возможно, это одна из причин, из-за которых программ с GUI на яве не так много, как ожидалось.
Да. Это одна из основных. Вторая, по-моему, шрифты, в которых до Java 6 небыло нормального сглаживания.

Здравствуйте, Аноним, Вы писали:

SK>>Смысл имеет исключтьельно сравнения конкретных случаев. Вот я вам дал конктерный случай, где С++ медленнее. И совершенно нет сомнений в том, что можно придумать "корректный" случай когда С++ быстрее. В этом и есть основная идея того, что я пытаюсь тут сказать — нельзя однозначно говорить, что что-то, в общем, говно, потому что это зависит от контекста использования. Нельзя однозначно сказать, что GC — говно, потому что при некоторых сценариях использования могуть быть большие паузы. Да могут быть, но из можно избежать, что не так сложно. В то же время в C++, при некоторых сценариях использования, гораздо больше CPU тратится на выделение и освободжение пямяти и соответственно, throughput будет меньше. Тоже говно?
А>Вы пытаетесь переложить свой стиль написания на Java к программам на C++. Но на плюсах так никто не пишет, по крайней мере в частях, где важна скорость (а она здесь важна, раз уж взялись меряться). Все короткоживущие объекты создаются на стеке, скорость выделения и освобождения памяти в котором намного выше, чем в Java. Не тратится время на ненужную инициализацию памяти нулями. И даже стандартные контейнеры зачастую не используются.
Понятия не имею как пишут на плюсах. Только догадываюсь. Но речь шла именно о выделении пятими из кучи и освобожденни и о том какие варианты доступны.

А>Вы пишите, что на Java можно избежать пауз и это не сложно. Но всё это достигается косвенными методами и явным образом не контролируется программистом. А в общем случае вообще не гарантируется.
В общем случае вообще ничего не гарантируется, пока вы не работает с real-time системами. Посмотрите на jHiccup, как раз утилита для тех, кто думает, что есть какие-то гарантии.

А>Паузы в 10-20 мс может и не важны в серверных приложениях. Но если речь идет о программах с пользовательским интерфейсом, то это приводит к тому, что программа начинает "дергаться" и периодически "подвисать", а это жутко бесит пользователей. Возможно, это одна из причин, из-за которых программ с GUI на яве не так много, как ожидалось.
Не смешите мою бабушку. 10-20мс для гуя никого не трогают, у вас просто задержки в самой OC где-то такие же будут (см. JHiccup). Думаю, что где-то начиная со 75-100ms это будет иметь значение для эстетов в игрях, но не раньше. Еще не стоит забывать, что эта пауза раз в несколько секунд.
Начет GUI и java — оно просто не пошло и все. Дофига, например, GUI на C#, хотя там тот же GC. Потом есть отличные примеры GUI на java, которые замечательно работают и прекрасно выглядят, например IntelliJ Idea.

Здравствуйте, StanislavK, Вы писали:


SK>Начет GUI и java — оно просто не пошло и все. Дофига, например, GUI на C#, хотя там тот же GC.
Зато там и контролы нативные обертки над WinAPI как, например SWT.

SK>Потом есть отличные примеры GUI на java, которые замечательно работают и прекрасно выглядят, например IntelliJ Idea.
В IntelliJ Idea очень сильно допилен GUI. Т.е. это совсем не тривиально на Swing соорудить такое же. Ну, и если вспомнить IntelliJ Idea лет 10 назад, то даже на средних проектах оно очень бодро уходило в немаленькие GC паузы.

Здравствуйте, A13x, Вы писали:

A>Здравствуйте, StanislavK, Вы писали:

A>Нет, я согласен с этим утверждением. У меня и в мыслях нет защищать как-то С++. Аллокаторы общего назначения на С++ вовсе не идеал. Я лишь хотел подчеркнуть то, что ручное управление памятью, возможное в языках с ручным управлением памятью может быть намного более эффективным с общего отношения потребляемая память/быстродействие.
Что-то сделанное специально для чего-то всегда лучше. Но GC не об этом и ARC и что-то там еще, типа подсчета ссылок, тоже не об этом. Речь идет именно об общих, более-менее универсальных решениях.

SK>>Ой да? Мне показалось или вы там сами пытаетесь написать аллокатор? Только он ничего не умеет и потому такой из себя быстрый? Так, что давай-ка не будем забывать изначальное условие, то фунциональность должны быть приблизительно эквивалентна.
A>Но "обернуть" этот аллокатор в удобную для использования обертку не так сложно, я лишь продемонстрировал идею. Другое дело, что да, он будет сильно заточен под конкретный сценарий использования, естественно это не для аллокатор общего назначения.
Ну вот и не надо сравнивать его с чем-то, что общего назначения. В яве тоже можно пулы объктов сделать и выделение/удаление не будет вообще трогать GC, но так можно сравнивать варианты до бесконечности...

A>>>Хочу заметить, что для С++ автоматом вызываются деструкторы, давайте для сравнения повторим ваш прогон для объектов с finalize, например так:
SK>>С чего это он будет вызываться у массивов байтов?
A>А я сейчас не про массив байт, не про свой вариант на С, а про сравнение варианта на С++ с loki и варианта на яве.
В варианты с C++ и loki был только массив. Посмотрите внимательно исходник.

Здравствуйте, Blazkowicz, Вы писали:

SK>>Потом есть отличные примеры GUI на java, которые замечательно работают и прекрасно выглядят, например IntelliJ Idea.
B>В IntelliJ Idea очень сильно допилен GUI. Т.е. это совсем не тривиально на Swing соорудить такое же. Ну, и если вспомнить IntelliJ Idea лет 10 назад, то даже на средних проектах оно очень бодро уходило в немаленькие GC паузы.
Ну это как раз подтверждает то, что все дело в ручках Да и ява 10 лет назад была не та...