>Swing ресует все самостоятельно именно для повышения скорости, AWT использовал контролы ОС и из-за постоянного переключения в режим ядра и обратно работал крайне медленно

AWT работает достаточно быстро. Просто там контролов чуть больше 4 штук и нет нормальных способов их добавить. Поэтому Swing и сделали.

>А, а вот она жаба во всей красе! Расскажи хотя бы, что это за приложение? Автоматизация предпрития, бухгалтерии и универсальная IDE в одном флаконе?

Система мониторинга и управления технологическими процессами - сбор и обработка realtime-данных с сенсоров, рассчет статистики, планирование ресурсов, и т.п. Универсальную IDE мне писать не надо - она уже есть (Eclipse), собственно на Eclipse RCP приложение и построено.

Естественно, считаю только свои строки кода.

>Статический-то он статический, а от динамического жабового рантайма в виде хрен-знает-скольки-метровой библиотеки никуда не деться.

Нехождение по ссылкам - это традиция ЛОРа, я понимаю. Поэтому объясняю - Excelsior может делать абсолютно автономный, статически слинкованый образ.

Приложение с SWT, скомпилированое JET'ом занимает где-то мегабайт (на дискету помещается).

Да, а сам полный JDK6 Update2 от Sun будет иметь размер 3 мегабайта из-за использования крутого алгоритма сжатия pack200, специально заточеного под Java-байткод.

Сейчас размер JRE занимает 8Мб.

>А я-то думал, что там сидит с++, разве не так? Да и "популярность" - не есть объективный критерий ни для чего, кроме статистики.
Не так. После Java идет VB6 и С++ с примерно одинаковой популярностью.

>> Кстати, Java - это компилируемый язык. Есть полностью статические компиляторы, выдающие настоящие честные исполняемые файлы - http://www.excelsior-usa.com/jet.html
>Да ну? А о "gcj" слышали?
А да, про него тоже забыл.

>> Причем "сливание" Java/.NET уже очень заметно сокращается. Скоро станет вообще пренебрежимо малым.
>Никогда не станет, потому как компиляторы точно так же не стоят на месте, да и расцвет виртуализации может тупо сделать "управляемый код" нафиг никому не нужным.
Мда? Мсье писал когда-нибудь серьезные системы на C++ с COM+/CORBA? Нет?

Рекомендую попробовать. Потом сравнить ощущения с Java/.NET.

>> Феномены с тормозным кодом на C/C++, к сожалению, видел не раз. И не раз занимался их оптимизацией.
>Так не феномены с кодом то были, а феномены с глюкавой головой. А лечилось следствие, отсюда и все мои сомнения.

А что делать? Глюкавые головы - это реальность природы, их не изменить. Java позволяет хотя бы локализовать ущерб от всяких идиотов.

>причём тут jsp на c++ ? Поколение пепси говорит о чудесной скорости java. Ну и им отвечают - паситесь дети, как java была тормозом в реальном применении, а не в "теоретической" болтовне, так и остаётся ею.

Кто "отвечает"? Вижу сплошных имбецилов, не имеющих понятия о современном состоянии дел.

Да, и где Java является "тормозом"? На server side? На client side?

мля ... как говорится couldn't resist

>В SUN JVM память выделяется из thread-local арен. Выделение памяти на БУКВАЛЬНО состоит из двух машинных команд (two-instructions allocator на Sparc V8, на x86 еще пара команд требуется) - смещение указателя на конец кучи. Никакой лишней синхронизации. Это НЕВОЗМОЖНО сделать в С++, так как требует уплотняющего garbage collector'а.

3.14здеть изволите г-н "контрибьютор в Boost". tls используют все продвинутые аллокаторы например hoard, nedmalloc, ptmalloc, mtmalloc ... ну а насчет two-instructions - используйте pool allocator-ы... и ненадо ничего "писать" (если неохота) все уже написано - возьмите например heap layers или pool-allocator-ы из тогоже бюста (там правда нужно немного допиливать ну "контрибьюторы в Boost" знают!).

>Кстати, если речь зашла про многопроцессорность - то в Sun JVM 1.6 реализован спекулятивный lock elision, использующий механизм HotSpot. В С++, опять же, невозможно.

как Speculative Lock Elision (SLE) так и Transactional Lock Removal (TLE) ( который базируется на SLE ), так и Transactional Memory реализуется АППАРАТНО ( для "контрибьюторофф в BoostЫ" - на уровне процессороа ) и поэтому фиолетово относительно языка (платформы) программирования. в ЖВМ это конечно можно реализвать, но исключительно для интерпретируемого кода - т.е. на уровне интерпретатора.

и еще "контрибьюторам в Boost" (да простят меня контрибьюторы в boost) не мешало бы знать, что память она не только выделяется, но и освобождается и в целом, даже БЕЗ участия хитроумных и продвинутых аллокаторов картина такова:

OOPSLA 2005: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management with Matthew Hertz.

<quote> This paper provides empirical answers to an age-old question: is garbage collection faster/slower/the same speed as malloc/free? We introduce oracular memory management, an approach that lets us measure unaltered Java programs as if they used malloc and free. The result: a good GC can match the performance of a good allocator, but it takes 5X more space. If physical memory is tight, however, conventional garbage collectors suffer an order-of-magnitude performance penalty. </quote>

примите во внимание еще и то,

1) что ситуация, когда physical memory is tight - это нормальная (повседневная) ситуация (памяти всегда мало).

2) прибавьте сюда свопинг

3) прибавьте сюда TLB misses

и только тогда полУчите реальную картину.

>Да, и прежде чем брызгать соплями - я профессиональный программист на С/С++, контрибьютор в Boost

а так же Папа Римский, Президент Соединенных Штатов Америки, России и Кецалькоатль Пернатый Змей в одном лице.

>3.14здеть изволите г-н "контрибьютор в Boost". tls используют все продвинутые аллокаторы например hoard, nedmalloc, ptmalloc, mtmalloc ...
Вот только без атомарных операций/локов не обходится ни один из них. Например, при освобождении объекта из другого потока, или проверки очереди на освобождение.

Да, Hoard у нас купленый. Про него я прекрасно знаю.

>ну а насчет two-instructions - используйте pool allocator-ы... и ненадо ничего "писать" (если неохота) все уже написано - возьмите например heap layers или pool-allocator-ы из тогоже бюста (там правда нужно немного допиливать ну "контрибьюторы в Boost" знают!).

Да, и гвоздями привязать время жизни объектов к времени жизни пулов. Сравни с нормальными аллокатором для ОБЩЕГО случая.

>как Speculative Lock Elision (SLE) так и Transactional Lock Removal (TLE) ( который базируется на SLE ), так и Transactional Memory реализуется АППАРАТНО ( для "контрибьюторофф в BoostЫ" - на уровне процессороа ) и поэтому фиолетово относительно языка (платформы) программирования.
Бред несешь, товарищ. SLE _МОЖЕТ_ быть реализован аппаратно, однако пока что-то его нигде на распространенных платформах не видно. Однако, он точно так же может быть сделан программно.

>в ЖВМ это конечно можно реализвать, но исключительно для интерпретируемого кода - т.е. на уровне интерпретатора.
Мда. Видимо мозги переклинило от избытка слюны. Почитай хоть здесь, что ли: http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html

Если вкратце: HotSpot динамически профилирует код, делая inline и escape analysis. Если он обнаруживает, что объект с локами никак не может выйти за пределы потока - то убирает локи (динамически перекомпилируя байт-код в машинный код).

>а так же Папа Римский, Президент Соединенных Штатов Америки, России и Кецалькоатль Пернатый Змей в одном лице.
Готов предоставить свои credentials под NDA.

> Нехождение по ссылкам - это традиция ЛОРа, я понимаю. Поэтому объясняю - Excelsior может делать абсолютно автономный, статически слинкованый образ.
> Приложение с SWT, скомпилированое JET'ом занимает где-то мегабайт (на дискету помещается).
> Да, а сам полный JDK6 Update2 от Sun будет иметь размер 3 мегабайта из-за использования крутого алгоритма сжатия pack200, специально заточеного под Java-байткод.
> Сейчас размер JRE занимает 8Мб.

Потребление памяти использованием экзе-пакеров не лечится в принципе.

> и ненадо ничего "писать" (если неохота) все уже написано - возьмите например heap layers или pool-allocator-ы из тогоже бюста (там правда нужно немного допиливать ну "контрибьюторы в Boost" знают!).


Скажи мне, друх, вот, через неделю придёт на проект три-четыре новых человека - кто будет оплачивать им время которое они потратят разобраться во всей этой мешанине из говноэстеэль, говнобуста, говнокуте, говноэмэфце, говноэйтиэль, говнодабльютиэль, самодельных говноменеджеров памяти и различных ручных говнодопилов всего этого говна? Будем студентов брать, которые по ночам будут в этом ковырять жастфофана или всё-таки лучше сразу возьмём жабодотнет где всё это не просто есть, но ещё и изначально стандартно-однообразно - без полудюжины разных классов для строк, полудюжины разных реализаций контейнеров и всякой прочей хероты типа автопойнтеров, смартпойнтеров, шаредпойнтеров (только перечислять всю эту херь - уже зашибёшься, не говоря о том чтобы ещё разбираться в ней), которую налепили просто из-за изначальной кривости среды?

> Нехождение по ссылкам - это традиция ЛОРа, я понимаю. Поэтому объясняю - Excelsior может делать абсолютно автономный, статически слинкованый образ.

Это неправда, на выходе получается инсталлятор, который всё равно при установке распаковывается в набор файлов. В частности, нативы так и остаются рассыпухой DLL. Впрочем, никто из пользователей не жалуется.

> Приложение с SWT, скомпилированое JET'ом занимает где-то мегабайт (на дискету помещается).

Увы, но так было до версии 3.7 включительно, начиная с 4.0 нам приходится соответствовать лицензии, которая запрещает частичную редистрибуцию стандартной библиотеки Java SE. Нам удалось придумать и в версии 5.0 реализовать "законный" способ это ограничение обойти, но цифры не столь впечатляющие:

http://www.excelsior-usa.com/java-download-size.html

Дмитрий Лесков ООО Эксельсиор

> Либо ты сказал какую-то фантастическую умную вещь, которую я не понял, либо ты бредишь. Опять бум что ли сериализовать объекты машинного кода, задавать внешние интерфейсы на IDL, забъем на рефлекшн в любых проявлениях?

И то и другое ;)

Вот только пиз^Wсвистеть не надо дядя?


Это навижн в девичестве, сейчас называется Microsoft Dynamics.


http://www.microsoft.com/Rus/Dynamics/Clients/ByIndustry.mspx

>OOPSLA 2005: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management with Matthew Hertz.

Кстати, эту статью я читал. Там сравнивается GC с идеализированым new/delete. В реальных программах придется использовать счетчики ссылок, пулы и т.п. Это все увеличивает время работы и расход памяти.

Хотя излишний расход памяти у GC действительно есть, хотя тут тоже прогресс есть.

> Bitter/Better/Beyound Java читал хотя бы?

Ну Bitter Java читал. А зачем мне еще Ruby изучать? Мне, быдлокодеру, и Java (+ местами Obj-C) хватает.

> А не будет, поскольку JPython помер. Должен быть флейм JRuby vs Groovy, вотъ.

Вообще-то на днях релиз новой версии jython'а был. Не в смысле беты или чего еще, а настоящий релиз.

Ну да, питон там 2.2 пока еще. Все равно ведь лучше, чем раби..

дайнэмикса два (на самом деле три=), один был в девичестве Navision http://www.microsoft.com/rus/dynamics/solutions/navision/default.mspx

другой Axapta http://www.microsoft.com/rus/dynamics/solutions/axapta/default.mspx

и отличаются они как небо и земля навижн действительно менее технологичный нежели 1с (местами даже 7.7), но у него всё же есть свои козыри. Axapta очень приятная штука и 1с до неё ещё пилить и пилить...

Проблема 1с (фирмы) в том, что её продукт очень не зрелый и западный рынок его не воспримет именно по этому, на мой взгляд (например, кто станет терпеть такой бардак с совместимостью при переходе от одной версии к другой?).

Внедрение западных продуктов в России та ещё песня по причине незрелости управления бизнесом, особенно в средних и мелких компаниях, здесь 1с тоже внесла свою значительную лепту, а также, в части, из-за не устоявшихся правил ведения оного.

> Bitter/Better/Beyound Java читал хотя бы?

> Ну Bitter Java читал.

Читай дальше в указанном порядке.

> А зачем мне еще Ruby изучать?

Зачем думать? Зачем жить?

> Вообще-то на днях релиз новой версии jython'а был.

Как я понимаю, в байт-код оно не компилит или я не прав?

> всё-таки лучше сразу возьмём жабодотнет где всё это не просто есть, но ещё и изначально стандартно-однообразно - без полудюжины разных классов для строк, полудюжины разных реализаций контейнеров

Вылазь из танка - в жабадотнете уже контейнеров тоже навалом теперь. Qt как бы не выиграло еще по этому параметру.

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

ага, а жабий copy + mark + sweep + compact исключительно lock & wait free!

>Да, и гвоздями привязать время жизни объектов к времени жизни пулов.

да. в с++ нужно планировать время жизни объектов. для вас это новость?

>Сравни с нормальными аллокатором для ОБЩЕГО случая.

и получи очередной FireFox.

>Бред несешь, товарищ. SLE _МОЖЕТ_ быть реализован аппаратно, однако пока что-то его нигде на распространенных платформах не видно. Однако, он точно так же может быть сделан программно.

мля.... возьмите вот это http://pages.cs.wisc.edu/~rajwar/papers/micro01.pdf и узнайте что такое SLE и почему его нельзя реализовать программно. (к стати Ravi Rajwar - это один из авторов автор SLE.)

м.... это вы тот человек, которому за 40 и который в одиноску сляпал прогу в 10M SLOC?

>Кстати, эту статью я читал. Там сравнивается GC с идеализированым new/delete

там сравнивается гц и dlmalloc. а .... так это вы в бюст контрибьютили?

> без полудюжины разных классов для строк, полудюжины разных реализаций контейнеров и всякой прочей хероты типа автопойнтеров, смартпойнтеров, шаредпойнтеров (только перечислять всю эту херь - уже зашибёшься, не говоря о том чтобы ещё разбираться в ней), которую налепили просто из-за изначальной кривости среды?

Нда-а-а... Началось... Вы тот самый контрибьютор в бууст или уже другой анонимус?

P.S. И не сказать, чтобы я был каким-то особенным любителем C++, скорее, наоборот, я его гневно ругал последние две-три недели, как снова начал писать на нём. Но должен заметить, что смартпойнтеры, за исключением некоторых досадных, на мой взгляд, особенностей дизайна - образец простоты и точного решения точно сформулированных задач.

> Еще одно замечение, теоретик. В SUN JVM память выделяется из thread-local арен. Выделение памяти на БУКВАЛЬНО состоит из двух машинных команд (two-instructions allocator на Sparc V8, на x86 еще пара команд требуется) - смещение указателя на конец кучи. Никакой лишней синхронизации.

> Это НЕВОЗМОЖНО сделать в С++, так как требует уплотняющего garbage collector'а.

OMG. Каким образом выделение объектов на TLS (точнее, _учет_ выделений на TLS) связано с компактифицирующим GC? (кстати, мне всегда казалось, что в Java его тоже нет)?

> Кстати, если речь зашла про многопроцессорность - то в Sun JVM 1.6 реализован спекулятивный lock elision, использующий механизм HotSpot. В С++, опять же, невозможно.

double-checked на определенных архитектурах (x86 SMP/NUMA в их число входит) вполне себе работает. И spinlock-и тоже никто не отменял. Ну и вообще, если ваше приложение тормозит на синхронизации - у вас что-то не так с дизайном.

Но, да, прозрачный lock elision на плюсах сделать трудно - только если скрестить компилятор с мультитредным профилировщиком.

> Да, и прежде чем брызгать соплями - я профессиональный программист на С/С++, контрибьютор в Boost, у меня на моем счету три встроенных девайса с Линуксом на борту. А еще я знаю детали функционирования JVM в мельчайших подробностях.

Ой, верится с трудом.

> Да, а по поводу тормозных GUI - есть SWT, который используется в Eclipse. Там все контролы - нативные, тормозить нечему.

Бугога. Тем не менее, Eclipse работает несравнимо медленнее VS под виндой, и какого-нибудь KDevelop под линукс. Причем он не на "умных" фичах тормозит, а банально медленно окошки прорисовывает. По крайней мере, так было с 3.2 на 1.5. Лучше с тех пор, наверное, стало - но навряд ли кардинально.

Безотносительно глючности GCC - ты не поверишь, но программы под линукс вполне можно компилировать визуально студией. Всего-то нужен конвертер PE->ELF, который я лично видел (наколенная поделка для внутреннего использования, но работает), а потом линкуется оно "на общих основаниях" редактором связей для целевой платформы.

>Бугога. Тем не менее, Eclipse работает несравнимо медленнее VS под виндой, и какого-нибудь KDevelop под линукс. Причем он не на "умных" фичах тормозит, а банально медленно окошки прорисовывает. По крайней мере, так было с 3.2 на 1.5. Лучше с тех пор, наверное, стало - но навряд ли кардинально.

На самом деле ничего удивительного. Eclipse написан сам на джаве. Запускал Eclipse под linux'ом. Да, тормознутый слегка. Под линь есть motif и gtk версии.

Но если сравнивать с vs.net под винду, то примерно одинаково, что и должно быть.

А Eclipse еще может использовать в качестве компилятора и sdk собственный линуксовский gcj. Под дебиан есть версия, называется Eclipse Native. gcj, кстати, заметно быстрее компилит, чем сановский javac.

KDevelop gcc использует.

>Феномены с тормозным кодом на C/C++, к сожалению, видел не раз. И не раз занимался их оптимизацией.

Посмотри МинГовно. Там цикл гармонического ряда выполняется в 1,5 раза медленнее, чем в .NET. .NET рулит, все остальное говно!

>> Да, а по поводу тормозных GUI - есть SWT, который используется в Eclipse. Там все контролы - нативные, тормозить нечему.

> Бугога. Тем не менее, Eclipse работает несравнимо медленнее VS под виндой, и какого-нибудь KDevelop под линукс

Ну дык KDeveklop на супер-быстром QT, а SWT - это супер-тормозной GTK, ничего удивительного. Если серьезно, то на момем ноуте как-то не вижу что-то я разницы (под линуксом)

> Swing ресует все самостоятельно именно для повышения скорости,

Ох! Правильный ответ: для гибкости. Swing слишком ограничен по изобразительным возможностям, поэтому, чтобы хоть как-то его использовать, надо его классы брать за основу, перегружать отдельные места и делать как тебе надо. Без этого Swing-ом просто невозможно пользоваться.

> AWT использовал контролы ОС и из-за постоянного переключения в режим ядра и обратно работал крайне медленно

Перл!

Ну и не надо мне про Swing, я как вспомню инсталятор оракла запущенный на удалённом сервере, как по полчаса жду пока он всё прорисует...

И не рассказывайте мне как Swing всё круто рисует, я устал его переделывать под себя...

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


Образец костылей и хака. Пока программист на дотнетожабе решает саму задачу, ради которой приложение и пишется, программист на С++ тратит время на раздумья какую бы ему ещё "идиому" применить, чтобы не отстрелить себе яйцо лишний раз.

но ход ваших мыслей мне нравится :)

2 анонимный контрибьютор boost.

А можешь ссылку на сайт своей конторы прислать на vkorenev на gmail? Интересуют профиль и вакансии. Вряд ли прямо сейчас, но мало ли. :)

>> Swing ресует все самостоятельно именно для повышения скорости, >Ох! Правильный ответ: для гибкости. Swing слишком ограничен по изобразительным возможностям, поэтому, чтобы хоть как-то его использовать, надо его классы брать за основу, перегружать отдельные места и делать как тебе надо. Без этого Swing-ом просто невозможно пользоваться.

Правильный ответ: для скорости. Фреймбуфер в видеокарте для него специально подвели, чтобы Java2D использовала Direct Rendering БЕЗ_ТОРМОЗОВ. Аналогичная технология используется в GDI+ (но не в просто-GDI)

>> AWT использовал контролы ОС и из-за постоянного переключения в режим ядра и обратно работал крайне медленно >Перл!

На Windows это, к сожалению, так.

>Ну и не надо мне про Swing, я как вспомню инсталятор оракла запущенный на удалённом сервере, как по полчаса жду пока он всё прорисует...

В каком году? На каком железе? С какой JRE?

>И не рассказывайте мне как Swing всё круто рисует, я устал его переделывать под себя...

Специфическую парадигму "MVC" в Swing ниасилили?

> Правильный ответ: для скорости.

Шутку понял. Смешно. Я бы сам не пробовал, может и посчитал бы не шуткой.

> На Windows это, к сожалению, так.

Это оффтопик тут. Мне не интересно как оно в странных системах.

> В каком году? На каком железе? С какой JRE?

Да буквально в том, в котором 11-й оракл ещё не вышел. 10-й ставил. 9-й так же. 11-й пока не ставил. 5 часов установки оракла по сетке только из-за тормозного жаба-интерфейса. Да, я в курсе про "безинтерфейсные инсталяции", но раз уж разговор не про них, то и не будем.

> Специфическую парадигму "MVC" в Swing ниасилили?

Ничего особо специфичного. Сам всегда делаю "котлеты и мухи отдельно", проблема возникает, когда вкус котлет не нравится. Ну, например, надо сделать кнопку с градиентной заливкой фона. Без чтения исходников JRE не так просто проделать такую, казалось бы, простую операцию. Ну, или, сменить цвет Thumb в JSlider. Решение я нашёл, но с радостью приму линк на документацию, где об этом рассказывается. Хочу увидеть, как можно управлять цветом и прочими элементами скроллбара (дизайн задан в картинках) в таблице, которая рисуется на неподвижном фоне.

Ну и так далее, вопросов на самом деле много. Как оно рисуется внутри я как бы знаю. Как это всё отражается на скорости, я вижу. Пара собственных потомков JLabel на полупрозрачном фоне, и загрузка процессора под 100%, при ненормальной загрузке иксов под 30%. При этом информации на экране даже обновляться не надо, как оно работает так -- для меня загадка.

time=0.0

даже при private final static int size = 10000000;

java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b05) Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

Так что такой бенчмарк просто не катит

>> А зачем мне еще Ruby изучать?

> Зачем думать? Зачем жить?

АПВОВНВ? (А почему Вы отвечаете вопросом на вопрос?)

Бредовые идеи господина Тейта здесь уже обсуждали полтора года назад. Новые аргументы по существу у Вас появились? :))

>Говнище, не говнище, а только пока основная масса приложений написана или на Си или на Си++

Давно уже нет, даже если их просуммировать: http://www.tiobe.com/tpci.htm

>Мне уже скоро 40. И стаж работы программистом больше 10 лет.

А не поздно было в 30 лет начинать программировать? А то я как-то со своими 33-мя годами и 19-летним стажем программирования не чувствую чем-то исключительным.

>Такое приложение, если писать по 200 строк в день

По статистике, средний программист за всё время работы (включая выходные, отпуска и пинание балды) пишет около 8 строк кода в день. Так что 200 строк в день в течении многих лет - такие люди, ИМХО, на ЛОРе бы не сидели :D

> Бредовые идеи господина Тейта здесь уже обсуждали полтора года назад.

Не чтобы я считал Тейта безусловно верным, но по каким словам искать флейм?

> Пока программист на дотнетожабе решает саму задачу, ради которой приложение и пишется, программист на С++ тратит время на раздумья какую бы ему ещё "идиому" применить, чтобы не отстрелить себе яйцо лишний раз.

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

>ага, а жабий copy + mark + sweep + compact исключительно lock & wait free!

Кстати, есть почти полностью конкуррентный GC (т.е., работающий параллельно с мутатором). Его очень любят на крупных SMP запускать - выделяют ему пару ядер, и он там спокойно работает.

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

>>Да, и гвоздями привязать время жизни объектов к времени жизни пулов.
>да. в с++ нужно планировать время жизни объектов. для вас это новость?
Я к тому, что пулы не подходят для многих стратегий работы с памятью.

>мля.... возьмите вот это http://pages.cs.wisc.edu/~rajwar/papers/micro01.pdf и узнайте что такое SLE и почему его нельзя реализовать программно. (к стати Ravi Rajwar - это один из авторов автор SLE.)

Для тормозов еще раз: в твоей статье описывается другой вариант спекулятивного обхода локов. В JVM реализован софтварный вариант, использующий escape analysis.

>А не поздно было в 30 лет начинать программировать? А то я как-то со своими 33-мя годами и 19-летним стажем программирования не чувствую чем-то исключительным

Я выше писал, если быть точным 14 лет стажа программистом. И сорок мне будет болше чем через год, я округлял. А то что поздно это да. Я универ закончил в 31 и до универа работал программистом два года. А сейчас директор по IT на производственном предприятии с сетью более 40 компов. Раньше было больше, около 70. А 19 лет назад я был в армии, в советской, и о компьютерах только слышал. Я, тоже, не чувствую чем-то исключительным, просто парень откровенную пургу писал, вот я и ответил, чтоб он врал более правдоподобно. А все, что я выше написал, это даже не бравада так просто чтоб понимали, что здесь не только пионеры, но и есть взрослые люди, и наверное стоит подбирать слова при общении.

http://www.linux.org.ru/view-message.jsp?msgid=1204215

Да С++ породил кучу dynamic-cast-быдлокодеров, которые прочитав книжку Строуструпа, начинают совать все быдло-извращения языка куда не попадя, потом писдят, что они крутые хацкеры. А какие там придурки размусоливают множественное наследование, какие там возникают конфликты и прочую дребедень. Вместо того чтобы сказать, что наследовать реализацию нужно только от одного класса, все остальное - это интерфейсы.

Тогда сорри :)

> А сейчас директор по IT на производственном предприятии с сетью более 40 компов. Раньше было больше, около 70.

Я сейчас в обморок упаду, какие тут серьёзные люди среди нас, шпаны.

>Я сейчас в обморок упаду, какие тут серьёзные люди среди нас, шпаны.

Тебя то кто трогал? Или, тебе нравится читать ... у меня 5 000 000 строк кода ... это-ж бред полный, поверить в это может только человек не написавший ни одной программы вообще. А в обморок падай ни падай тут и депутаты постили, и ниче.

> Я сейчас в обморок упаду, какие тут серьёзные люди среди нас, шпаны.

У человека спросили "а ты хто такой", он поясняет. Идите выпейте чайку с конфеткой, успокойтесь.

Я сегодня такой нервный, такой беспокойный. Мне срочно нужна чья-то рекомендация, чтобы я успокоился. :)

>Кстати, есть почти полностью конкуррентный GC (т.е., работающий параллельно с мутатором). Его очень любят на крупных SMP запускать - выделяют ему пару ядер, и он там спокойно работает.

ну и ? паралельный гц работает без блокировок?

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

ох уж эти сказочники .... про "время работы пропорционально..." - верю, но только для копирующего гц ( для young generation ) и только для фазы сборки - копирования. однако есть еще и trace - а это уже не так красиво. это красиво только для чисто функциональных языков типа haskell,где точно известно, что в принципе не может быть ссылок из old generation в young one. в жаба - тебе нужно либо трейсить весь old generation, либо делать (программно эмулировать) write barrier, что значительно утяжеляет (по времени) изменение (запись) объекта (требуется все время чекать, а не завел ли он у себя ссылку на объект из young? ). cборка в old generation это песня, а уж компактизация хипа - вообще сказка. известны случаи (в IBM), когда на компактизацию хипа ~1.5G гц тратил > 5 минут.

>твоей статье описывается другой вариант спекулятивного обхода локов. В JVM реализован софтварный вариант, использующий escape analysis.

не тупите "контрибьютор" - я ведь не зря подчеркнул <quote>(к стати Ravi Rajwar - это один из авторов автор SLE.)</quote> то что вы имеете ввиду это НЕ SLE это "lock elision by escape analisys". что такое SLE надеюсь ты прочитал в статье, ссылку на которую я вам привел. хотя не уверен что вы поняли. объяснить?

ну а то, о чем вы говорите:

>Кстати, если речь зашла про многопроцессорность - то в Sun JVM 1.6 реализован спекулятивный lock elision, использующий механизм HotSpot. В С++, опять же, невозможно.

тоже неверно. вот например http://www.cag.lcs.mit.edu/~rinard/paper/ppopp01.pdf это тот самый "lock elision by escape analisys"

<quote> This paper presents a new combined pointer and escape analysis for multithreaded programs. The algorithm uses a new abstraction called parallel interaction graphs to an- alyze the interactions between threads and extract precise points-to, escape, and action ordering information for ob- jects accessed by multiple threads. The analysis is compo- sitional, analyzing each method or thread once to extract a parameterized analysis result that can be specialized for use in any context. It is also capable of analyzing programs that use the unstructured form of multithreading present in languages such as Java and standard threads packages such as POSIX threads. </quote>

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

> что такое SLE надеюсь ты прочитал в статье, ссылку на которую я вам привел. хотя не уверен что вы поняли. объяснить?

Да