Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель. "Нормальные" замыкания, судя по твоему высказыванию — это только ссылка, контролируемая GC.
Нет, это "только ссылка". Потому что семантика передачи ссылки принципиально отличается от передачи по значению, и именно она нужна. GC — второстепенная деталь реализации, без которой всё вместе трудно заставить работать. ГВ> Я не хочу сказать, что такая точка зрения не имеет права на существование, но это никак не противоречит копированиям и прочим тра-ля-ля.
Геннадий, не надо придуриваться. Есть общепринятая трактовка замыкания, в которой замыкается полный лексический контекст. И плюсы не в состоянии обеспечить реализацию этой трактовки. А говорить "вот мы изобрели некоторое малополезное подмножество вашей функциональности, и назвали его точно так же, как полное — вот вам и замыкания" — это нечестно.
ГВ>Ну, я имел в виду, что с бустом сие сложновато будет реализовать. В смысле, именно такую конструкцию — со ссылкой на неконстантную переменную. Но и то, из-за design goals самой BLL (boost lambda library). А так, вроде, C++0x должен содержать такую возможность.
Да, мы в курсе, что C++0x должен содержать все нужные возможности по определению.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, criosray, Вы писали:
COF>>Хорошо, что это за приложения? Я их поставлю и если они действительно летают, то я признаю свою неправоту :) C>ThrottleLauncher, Twittula и самописное бизнес-приложение.
Поставил ThrottleLauncher и поигрался с ним пару дней. Такое впечатление, что у тебя либо быстрое устройство с маленьким экраном, либо у тебя извращенное представление о том, что значит "программа летает". Если ThrottleLauncher и летает на моем HTC HD, то низко-низко :) С аналогичными программами, написанными на C++, просто не сравнить. В общем, я еще более укрепился в своем мнении, хотя после столь массированной пропаганды со стороны сторонников управляемых языков уже был даже готов поверить.
Но прикольно другое. Поставив сие чудо софтостроения и нарвавшись на нехилые тормоза, я начал рыть в сети на предмет возможных настроек и т.п. Вот на что я наткнулся и что меня буквально потрясло:
В процессе тестирования проги обнаружил большую утечку памяти. За 15 минут переключения вкладок прога полностью съела 18 свободных мег. Это напоминает утечку памяти PointUI 2. Методов борьбы не обнаружил. Если буфферизацию ставить в 0 — прога тормозит, а утечка памяти происходит медленно, но верно. В общем не рекомендую владельцам медленных процессоров и малой оперативки.
Это проблема программы — не высвобождается полностью память при перерисовке, решить ее самостоятельно не удастся.
Здравствуйте, Sinclair, Вы писали:
ГВ>> Я не хочу сказать, что такая точка зрения не имеет права на существование, но это никак не противоречит копированиям и прочим тра-ля-ля. S>Геннадий, не надо придуриваться. Есть общепринятая трактовка замыкания, в которой замыкается полный лексический контекст. И плюсы не в состоянии обеспечить реализацию этой трактовки. А говорить "вот мы изобрели некоторое малополезное подмножество вашей функциональности, и назвали его точно так же, как полное — вот вам и замыкания" — это нечестно.
Ясно, терминологически мы разошлись, поскольку я называл "замыканием", по сути, передачу параметров лямбда-выражению, а не операцию, подразумевающую эээ... Совмещение пространства имён лямбды с пространством имён функции, где эта лямбда создаётся, и сопутствующим неявным порожденем связей, переменных и т.п.
Короче говоря, я понял, о каком различии ты говоришь, но тут сейчас сам точно не знаю, что именно будет реализовано в C++0x.
ГВ>>Ну, я имел в виду, что с бустом сие сложновато будет реализовать. В смысле, именно такую конструкцию — со ссылкой на неконстантную переменную. Но и то, из-за design goals самой BLL (boost lambda library). А так, вроде, C++0x должен содержать такую возможность. S>Да, мы в курсе, что C++0x должен содержать все нужные возможности по определению.
А я вот ещё не в курсе, будет ли в нём именно лексическое замыкание в "общепринятой трактовке" (с неявной модификацией жизненного цикла замкнутых переменных). Скорее всего — нет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mamut, Вы писали:
ГВ>> C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель. M>Учитывая, что два последних — это, по сути, одно и то же...
Все они одно и то же — значение чего-то.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Короче говоря, я понял, о каком различии ты говоришь, но тут сейчас сам точно не знаю, что именно будет реализовано в C++0x.
Пойми меня правильно: я не думаю, что в C++0x появится вездесущий GC и возможность менять время существования переменной без явного указания этого программистом. Я просто не в курсе деталей стандарта и уж тем более — особенностей реализации C++0x разными компиляторами. Поэтому не могу уверенно что-то говорить.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, COFF, Вы писали:
COF>Я просто стараюсь избегать преждевременной пессимизации кода. В итоге, наши программы работают лучше программ конкурентов, что приносит вполне ощутимое конкурентное преимущество.
Это полнейший лам. Ты ни грамма не ускоришь программу этими глупостями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, criosray, Вы писали:
C>Так это и есть пессимизация кода, если Вы во время написания кода стараетесь экономить на количестве тактов процессора и байтов памяти, там, где это абсолютно не принципиально и только отвлекает Вас от, собственно, решения поставленной задачи.
Все еще смешнее. Большая часть из перечисленного ровным счетом не влияет на производительность. Скажем выбор префикской и постфиксной записи мог влиять на что-то во времена Страуструпа, но современные компиляторы оптимизируют генерируемый код и в случае если просто поменять форму инкремента в цикле, ничего не изменится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> ГВ>> C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель.
ГВ> M>Учитывая, что два последних — это, по сути, одно и то же...
ГВ> Все они одно и то же — значение чего-то.
Я имею в виду — что ссылка _ это адрес чего-то, что указатель — это адрес чего-то
Здравствуйте, VladD2, Вы писали:
COF>>Я просто стараюсь избегать преждевременной пессимизации кода. В итоге, наши программы работают лучше программ конкурентов, что приносит вполне ощутимое конкурентное преимущество.
VD>Это полнейший лам. Ты ни грамма не ускоришь программу этими глупостями.
Это культура. Если одинаково просто написать ++j и j++, for( int j = count; j-- > 0; ) и for( int j = 0; j < count; j++ ), то при прочих равных надо выбирать оптимальный вариант — это и называется избегать пессимизации кода. Лам — это, с одной стороны, делать такие микрооптимизации в ущерб чему-то более важному, с другой стороны — осознанно на них забивать, типа и так сойдет.
Вдогонку,
У меня был знакомый, который на C++ осознанно писал вот так — for( int i = 0; i < array.GetCount(); i++ ), типа компилятор должен сам такие ситуации разруливать. Ну и в других местах он поступал аналогично. Потом он уволился и мне пришлось в его коде разбираться и оптимизировать. Так вот без всяких алгоритмических штучек, просто вычищением лишних уровней косвенности и выпрямления интерфейсов, мне удалось ускорить его код в несколько раз.
Так что пессимизация кода в малом скорее всего значит и пессимизацию в большом. Это мое твердое убеждение.
Здравствуйте, COFF, Вы писали:
COF>Вдогонку, COF>У меня был знакомый, который на C++ осознанно писал вот так — for( int i = 0; i < array.GetCount(); i++ ), типа компилятор должен сам такие ситуации разруливать. Ну и в других местах он поступал аналогично. Потом он уволился и мне пришлось в его коде разбираться и оптимизировать. Так вот без всяких алгоритмических штучек, просто вычищением лишних уровней косвенности и выпрямления интерфейсов, мне удалось ускорить его код в несколько раз.
Если array.GetCount() нормально инлайнится, то разницы в релизе не будет.
А если нет, то это уже проблемы в ДНК, а не в уровнях косвенности.
Кстати, что профайлер сказал на такой код?
COF>Так что пессимизация кода в малом скорее всего значит и пессимизацию в большом. Это мое твердое убеждение.
Это ты полнейший бред говоришь от непонимания того как заниматься оптимизацией.
Вполне возможно что вместо прохода по массиву каждый раз надо было результаты вычислений закешировать или, например, использовать другие структуры данных для улучшения ассимптотики вычислений.
Кстати. Твой знакомый работал и никого не беспокоило быстродействие кода, а ты в первую очередь занялся "выпрямлением интерфейсов", что сократило простор для алгоритмической или архитектурной оптимизации.
Здравствуйте, gandjustas, Вы писали:
G>Вполне возможно что вместо прохода по массиву каждый раз надо было результаты вычислений закешировать или, например, использовать другие структуры данных для улучшения ассимптотики вычислений.
G>Кстати. Твой знакомый работал и никого не беспокоило быстродействие кода, а ты в первую очередь занялся "выпрямлением интерфейсов", что сократило простор для алгоритмической или архитектурной оптимизации.
Нет, мне надо было реализовать некую новую функциональность, в процессе выяснилось, что существующая реализация недостаточно для этого гибка. Поэтому пришлось сделать рефакторинг определенных интерфейсов и модулей. Как побочный эффект выросла и скорость. На ровном по сути месте. Вообще, я не верю в подход — сделай как-нибудь, потом запустим профайлер и посмотрим где тормозит. Скорее всего, окажется, что тормоза равномерно распределены по всей программе. Часто говорят, что о безопасности надо думать с самого начала и всегда, невозможно небезопасную программу сделать безопасной. Вот то же самое, я уверен, можно сказать и о производительности — о ней надо думать всегда.
Здравствуйте, COFF, Вы писали:
COF>Здравствуйте, gandjustas, Вы писали:
G>>Вполне возможно что вместо прохода по массиву каждый раз надо было результаты вычислений закешировать или, например, использовать другие структуры данных для улучшения ассимптотики вычислений.
G>>Кстати. Твой знакомый работал и никого не беспокоило быстродействие кода, а ты в первую очередь занялся "выпрямлением интерфейсов", что сократило простор для алгоритмической или архитектурной оптимизации.
COF>Вообще, я не верю в подход — сделай как-нибудь, потом запустим профайлер и посмотрим где тормозит.
Зря. Это единственный возможный подход. В люом нетривиальном случае только профайлер может сказать где тормозит.
COF>Скорее всего, окажется, что тормоза равномерно распределены по всей программе.
Ты ни разу профайлером не пользовался? Почти всегда тормоза сосредоточены в 10% кода. Только без профайлера не узнаешь что это за 10%.
COF>Часто говорят, что о безопасности надо думать с самого начала и всегда, невозможно небезопасную программу сделать безопасной.
В большенстве случаев это верно. Вопрсы безопасности влияют на архитектуру.
COF>Вот то же самое, я уверен, можно сказать и о производительности — о ней надо думать всегда.
В большенстве случаев это неверно. Вопросы производительности, касающиеся вычислений, рекдо влияют на архитектуру.
Вопросы производительности, связанные с IO и многопоточностью, которые как раз влияют на архитектуру, "выпрямлением интерфейсов" не решаются.
Здравствуйте, COFF, Вы писали:
COF>Это культура. Если одинаково просто написать ++j и j++, for( int j = count; j-- > 0; ) и for( int j = 0; j < count; j++ ), то при прочих равных надо выбирать оптимальный вариант — это и называется избегать пессимизации кода.
Это махровое ламерство. Собственно данная беседа для меня потеряла всяческий интерес.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, COFF, Вы писали:
COF>Хорошо, тут я был не прав. Привел неудачный пример. Но я действительно неоднократно видел подобные рекомендации — ссылок к сожалению не сохранил, поэтому пытался найти в гугле что есть Да и ты сам ниже подтверждаешь мои слова.
Нет таких ссылок и быть не может. Потому как это бред. Стоимость вызова микроспопически мала. Ее можно заметить на вызове методов-пустышек в цикле. А их то как раз отлично оптимизирует (инлайнит) JIT.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это махровое ламерство. Собственно данная беседа для меня потеряла всяческий интерес.
Для меня эта беседа потеряла интерес когда я покрутил приложение, которое (по словам одного из обвинителей меня в ламерстве) якобы летает. Оказалось, что мало того, что оно тормозит, так еще и память утекает, причем со свистом — так, что средней C++-ной программе надо постараться такую утечку организовать. В общем, гладко было на бумаге, да забыли про овраги — практика пока теорию не подтверждает. Лепите уважаемые свои лямбды дальше :)
Вообще, все это я могу объяснить только профессиональной абберацией у дот-нетчиков, которые настолько привыкли, что все тормозит, что просто перестают тормоза эти замечать. На данный эффект в будущем буду делать поправку, а может вообще спорить на эти темы не буду — бессмысленно :)
Здравствуйте, VladD2, Вы писали:
VD>Нет таких ссылок и быть не может. Потому как это бред. Стоимость вызова микроспопически мала. Ее можно заметить на вызове методов-пустышек в цикле. А их то как раз отлично оптимизирует (инлайнит) JIT.
Ссылка старовата, зато от производителя. Интересны советы касательно использования virtual и упрощения графа вызовов. Например, вот это:
Copy Frequently Called Code into the Loop
If you repeatedly call methods from inside a loop, consider changing the loop to reduce the number of calls made. The JIT compiler usually inlines any called code if it is simple, but in most complex scenarios it is your responsibility to optimize the code. The costs of the call increase as you cross process or computer boundaries with remoting or Web services. The following code shows a method being called repeatedly inside a loop.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ссылка старовата, зато от производителя. Интересны советы касательно использования virtual и упрощения графа вызовов. Например, вот это:
ГВ>
ГВ>Copy Frequently Called Code into the Loop
ГВ>If you repeatedly call methods from inside a loop, consider changing the loop to reduce the number of calls made. The JIT compiler usually inlines any called code if it is simple, but in most complex scenarios it is your responsibility to optimize the code. The costs of the call increase as you cross process or computer boundaries with remoting or Web services. The following code shows a method being called repeatedly inside a loop.
Что тебя тут удивило или заинтересовало?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что тебя тут удивило или заинтересовало?
Очень созвучно тому, о чём говорил COFF — про объединение мелких методов в один. Ты, вроде, утверждал, что таких рекомендаций не может быть вообще. Как видишь — бывают.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель. "Нормальные" замыкания, судя по твоему высказыванию — это только ссылка, контролируемая GC.
