Здравствуйте, Lonely Dog, Вы писали:
LD>Привет!
LD>Сразу же хочу сказать, что я свои выводы я сделал на основании просмотра одной open-source программы под названием PuTTY.
Здравствуйте, Sheridan, Вы писали:
S>Добрался до книжки.
Ну и? Как ни странно, но виртуальные вызовы идут через таблицу виртуальных вызовов. Следующая новость: вода — мокрая, небо — голубое, трава — зелёная.
Как ни странно, но в С++ прекрасно можно жить без виртуальных вызовов (например, их почти нет в STL). Точно так же как и в С можно использовать вызовы через vtbl.
А теперь посчитай, сколько здесь виртуальных вызовов, и нужно ли их все делать через vtbl, или компилятор может принять решение на этапе компиляции (и принимает, если нормальный компилятор)?
Здравствуйте, Sheridan, Вы писали:
S>Добрался до книжки.
Нда. Шеридан, очень смешно видеть человека, который оценивает производительность программы по книге, посвященной языку.
Ты не обратил внимание, что Бьярни везде пишет "вот как могла бы выглядеть..."? Это потому, что он пишет про синтаксис и семантику, а не про использование регистров и такты процессора.
Он даже не пишет про возможные оптимизации — надо полагать потому, что даже без их упоминания плюсы достаточно тяжелы для изучения.
Для того, чтобы хоть как-то рассуждать о производительности и ресурсопотреблении, нужно читать не "Язык С++", а "Разработка оптимизирующего компилятора для С++".
Ну или регулярно пользоваться реальным компилятором, профайлером и дизассемблером.
В целом, язык С++ допускает более широкий класс оптимизаций, чем С — благодаря более выразительной семантике. Специальные усилия были потрачены на то, чтобы обеспечить возможности по инлайнингу, иначе, к примеру, перегруженные операторы работали бы существенно хуже встроенных.
Кроме того, есть масса техник по устранению виртуальности. Один пример уже привели. Более хитрые компиляторы даже умеют выполнять спекулятивный инлайнинг.
Вот, почитай доклад парней, которые ближе к мартену, чем Мастер Цеха Страуструп: http://blogs.msdn.com/apardoe/attachment/1685578.ashx
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I> Я перешел на дотнет.
Я тоже дотнет очень уважаю, но там платят хуже чем c++, а это ключевой момент.
I>Программа кушает около полуторагигабайт памяти. лишние lpVtbl дают и вовсе выход за границы процесса, в виндовсе это 2гб и планками памяти это не лечится.
Если программа нуждается около полуторагигабайт оперативной памяти, то возможно ей на X86 уже делать нечего, нужно 64 бита внедрять. Пытаться оптимизировать путем перехода на С, это только отягивать себе конец, в любой момент нужно будет масштабировать и тут все упрется в ограничения процессора. А для x64 проблем с адресации в данную эру еще не существует.
Здравствуйте, Ikemefula, Вы писали: I>Программа кушает около полуторагигабайт памяти. лишние lpVtbl дают и вовсе выход за границы процесса, в виндовсе это 2гб и планками памяти это не лечится.
Кстати, около полуторагигабайт памяти вероятнее всего занимают данные. А они будут везде едины, что на С, что на С++ или C#. lpVtbl возможно и прибавит насколько мегабайт к исполняемому коду, но на размер данных это не скажется.
shrecher пишет:
> Если программа нуждается около полуторагигабайт *оперативной* памяти, то > возможно ей на X86 уже делать нечего, нужно 64 бита внедрять. Пытаться > оптимизировать путем перехода на С, это только отягивать себе конец, в > любой момент нужно будет масштабировать и тут все упрется в ограничения > процессора. А для x64 проблем с адресации в данную эру еще не существует.
Для x64 к сожалению существует проблема с корпоративными клиентами,
которые не хотят менять операционку.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, shrecher, Вы писали:
S>Если программа нуждается около полуторагигабайт оперативной памяти, то возможно ей на X86 уже делать нечего, нужно 64 бита внедрять.
Это не я решаю, а корпоративные клиенты.
>Пытаться оптимизировать путем перехода на С, это только отягивать себе конец, в любой момент нужно будет масштабировать и тут все упрется в ограничения процессора. А для x64 проблем с адресации в данную эру еще не существует.
Никто и не пытается переходить на С. Вместо этого перешли на дотнет.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали: I>>Программа кушает около полуторагигабайт памяти. лишние lpVtbl дают и вовсе выход за границы процесса, в виндовсе это 2гб и планками памяти это не лечится.
S>Кстати, около полуторагигабайт памяти вероятнее всего занимают данные. А они будут везде едины, что на С, что на С++ или C#. lpVtbl возможно и прибавит насколько мегабайт к исполняемому коду, но на размер данных это не скажется.
Так да не так. lpvtbl при множественном наследовании не один на объект, а несколько штук.
для этого, кстати, придумана оптимизация если дерево наследования огромное, __declspec(novtable)
Основная проблема, когда объекты мелкие и их очень много.
Здравствуйте, Ikemefula, Вы писали:
S>>Здравствуйте, Ikemefula, Вы писали: I>>>Программа кушает около полуторагигабайт памяти. лишние lpVtbl дают и вовсе выход за границы процесса, в виндовсе это 2гб и планками памяти это не лечится.
S>>Кстати, около полуторагигабайт памяти вероятнее всего занимают данные. А они будут везде едины, что на С, что на С++ или C#. lpVtbl возможно и прибавит насколько мегабайт к исполняемому коду, но на размер данных это не скажется.
I>Так да не так. lpvtbl при множественном наследовании не один на объект, а несколько штук.
I>для этого, кстати, придумана оптимизация если дерево наследования огромное, __declspec(novtable)
I>Основная проблема, когда объекты мелкие и их очень много.
И основная проблема кстати говоря, не размер, а управление памятью. На дотнете памяти стало расходоваться немного больше, но пропала необходимость искать утечки памяти, утечки интерфейсов и тд.
Здравствуйте, Sergey, Вы писали:
S>shrecher пишет:
>> Если программа нуждается около полуторагигабайт *оперативной* памяти,
S>Для x64 к сожалению существует проблема с корпоративными клиентами, S>которые не хотят менять операционку.
Понимаешь, тут либо 1.5 Gb либо лицензия на 64-bit. Можно ESX поставить и как к терминалу коннектится если что-то жутко большое.
Да, отвлеклись от темы. Язык программированния тут имеет малое значение. Использование чистого С проблему не решит, а сделает только хуже — будет больше security проблем, всякие strcpy вылезут.
Синклер, я тоже говорил о том, что "не всегда, но бывает".
В целом же я за с++, он дает нааамного больше свободы чем С, и возможные затраты времени исполнения — ничто по сравнению с удобством.
А затраты времени на компилирование — это фигня. Компилируется 1 раз.
Здравствуйте, Sheridan, Вы писали:
S>Sinclair однажды (18 июня 2008 08:16) писал:
S>А затраты времени на компилирование — это фигня. Компилируется 1 раз.
Здравствуйте, Sheridan, Вы писали:
S>Синклер, я тоже говорил о том, что "не всегда, но бывает".
"Но бывает" нужно в тех случаях, где потребуется аналог vtbl и в чистом C.
Константин Б. однажды (19 июня 2008 [Четверг] 05:09) писал:
> S>А затраты времени на компилирование — это фигня. Компилируется 1 раз. > http://xkcd.com/303/
Видел, ага. В таких случаях имхо лучше купить многопроцессорный комп и компилировать в несколько потоков.
Здравствуйте, Cyberax, Вы писали:
LD>>3. Мой любимый пример. Функция term_out из файла terminal.c. Она занимает 1830 строк. Там реализован какой-то офигенный конечный автомат. С какими-то вложенными состояниями и метками case вида: C>Используется подход с С coroutines, описаный вот здесь: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Fibers в WinAPI уже лет 15 — появились в Windows NT Workstation 3.51 и Win98: в отличие от этих.. хмм.. макросов , код остаётся весьма читабельным.
Лишний раз убеждаюсь, шо без Windows жизни нет
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Cyberax, Вы писали:
C>>А что за патч? J>Сейчас он пэйстит при нажатии средней кнопки мыши. J>А должен пэйстить при ее отпускании, иначе оно нифига не работает с Exceed, который копирует иксовое содержимое в буфер при потере фокуса, которое как раз при нажатии и происходит. J>Т.е. PuTTY в результате вставляет предыдущее содержимое, а если кликнуть еще раз, то уже вставит новое. J>Выглядит это феерически.
J>В этом патч и состоит.
В общем, год с лишним прошел, эффекта нет.
На всякий случай, чтоб не затерялось, и если вдруг кому еще пригодится, выкладываю решение здесь:
файл terminal.c, строка 5800, выглядит так:
} else if (bcooked == MBT_PASTE
&& (a == MA_CLICK // <-- this is the line 5800#if MULTICLICK_ONLY_EVENT
|| a == MA_2CLK || a == MA_3CLK
#endif
)) {
request_paste(term->frontend);
}
надо заменить этот код на
} else if (bcooked == MBT_PASTE && a == MA_RELEASE) {
request_paste(term->frontend);
}
тестировал под виндой, с одиночными и мультикликами — никаких проблем.
Если у кого есть энергия общаться с разработчиками — велкам.
Мне моего локального билда с патчем хватает.
Здравствуйте, max779, Вы писали:
M>вот ты пишешь программу и пользуешься этими магическими YIELD и т.д. Потом ты увольняешься, на твое место приходит другой кодер и он не знаком с этим делом...
Если не индус, то либо будет иметь представление об этом, либо разберётся. Иначе — зачем вам ещё одна обезьянка?
LD>Мне интересно, весь open-source написан так же или это мне так повезло? LD>Как при таком качестве кода они умудряются что-то разумное делать?
Вот [url=http://savesources.com/index.html]тут[url] можно увидеть, что количество например использования strlen в условии циклов в опен соурс проектах около 50 000, что тоже говорит об низком качестве. Но это средняя тепмература по палате у популярных проектов думаю все ок с понятностью кода.
Да и потом, в закрытом коде можно такое увидеть ....
Здравствуйте, Ikemefula, Вы писали:
> I>А вот в более серьезных проектах обычно есть контроль за качеством кода. И здесь девелоперы приучаются писать не для себя одного.
Позвольте поинтересоваться вашим серьезным проектом. Название, заказчика, подрядчика ну хоть что-то что не секретно. Ну и желательно расскажите как вы работаете с данными.
