g++

[Max Khon]

hi, there!

03 Nov 03 19:06, you wrote to Victor Wagner:

>> И понятие "аналогичности" в случае ObjectPascal, который исходно, на
>> уровне дизайна языка, заточен под быструю однопроходную компиляцию
>> versus C++ с ее двухэтажным препроцессором (сначала обычным C-шным,
>> а потом template всякими) это вопрос достаточно дискуссионный.

EL> Глупый вопрос: а зачем С++ компилеры так работают, в чем тут дело?

в недоделанности и в особенностях языка. в g++, например, понятие precompiled
headers отсутствует, а на win32 без специальных телодвижений (простых, но
их делать приходится) они тоже не включаются.

/fjoe

[Anton Petrusevich]

Victor Wagner wrote:

> Затем, что если это не будут делать они, это придется делать в том или
> ином виде либо программисту руками (например, реализовывать аналог
> темплейтов) либо рантайм-системе. И то и другое - дороже.

Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
темплейтов мне очень сомнительна. Я понимаю, что от этого механизма реально
тащицца Александр Степанов, но вот лично я например, как-то не очень. Вещи
типа:
struct ltstr {
bool operator()(const std::string &s1, const std::string &s1) {
return s1 < s2;
}
};
typedef std::map<std::string key, std::string value, ltstr> std_string_hash;
typedef std::map<std::string key, std::string value, ltstr>::iterator
i_std_string_hash;

Hа мой взгляд, ugly. По такому хешу в gdb _очень_ сложно посмотреть
содержимое. И я понимаю его трудности. А когда мне нужен хеш хешей... А как
это всё "приятно" в использовании...
--
Anton Petrusevich

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
> темплейтов мне очень сомнительна. Я понимаю, что от этого механизма реально
> тащицца Александр Степанов, но вот лично я например, как-то не очень.
Для разнообразия почитай Александреску. Он тоже "тащится" ;-)
и понапридумывал там всякого разного...
Кое-что даже полезно. Но, по-моему, немногое.

> Вещи
> типа:
> struct ltstr {
> bool operator()(const std::string &s1, const std::string &s1) {
> return s1 < s2;
> }
> };
> typedef std::map<std::string key, std::string value, ltstr> std_string_hash;
> typedef std::map<std::string key, std::string value, ltstr>::iterator
> i_std_string_hash;
>
> Hа мой взгляд, ugly. По такому хешу в gdb _очень_ сложно посмотреть
> содержимое.
Само по себе это еще не повод. Всего-дишь проблемы gdb.

> И я понимаю его трудности. А когда мне нужен хеш хешей... А как
> это всё "приятно" в использовании...
Лично я использую абстрактные классы в перемешку в темплейтами.
Вторых на порядок меньше, но иногда без них никуда. Скорость, знаешь ли.

--
Best regards, Aleksey Cheusov.

[Victor Wagner]

Anton Petrusevich <***@att-ltd.biz> wrote:
AP> Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
AP> темплейтов мне очень сомнительна. Я понимаю, что от этого механизма реально
AP> тащицца Александр Степанов, но вот лично я например, как-то не очень. Вещи
AP> типа:
AP> struct ltstr {
AP> bool operator()(const std::string &s1, const std::string &s1) {
AP> return s1 < s2;
AP> }
AP> };
AP> typedef std::map<std::string key, std::string value, ltstr> std_string_hash;
AP> typedef std::map<std::string key, std::string value, ltstr>::iterator
AP> i_std_string_hash;

AP> Hа мой взгляд, ugly.

ugly, конечно. Но хоть какие-то, и на том спасибо. Если ты хочешь красивое
generic
programming, то нужно брать язык, который для этого изначально заточен.
Lisp там, Haskell, Ocaml или Erlang.

Несколько более корявыми, хотя намного прямее чем в C++, эти конструкции
будут в Perl, Python и Tcl.

Но есть ситуации когда C++ необходим по каким-то другим причинам, а от
мощных структур данных отказываться не хочется. Тогда и приходится
мириться с уродливым синтаксисом STL.

AP> По такому хешу в gdb _очень_ сложно посмотреть

Ну так gdb это the last resort. Это инструмент не для лечения, а для
паталогоанатомии. Когда программа уже упала в кору, и эту кору надо
проанализировать.

Когда ты пишешь высокоуровневый код (а код, использующий STL -
высокоуровневый), таких ситуаций не должно быть, потому что не должно
быть никогда. Вся мелочевка, где SIGSEGV возможен - нетривиальные
аллокаторы, низкоуровневая работа с данными, возвращаемыми внешними
функциями и т.д. должна быть уже отлажена и покрыта всеобъемлющим
набором unit-тестов.


--
Sapienti sat, как сказал дракон Мрак, выпив 24-ю бутылку вина.

[Aleksey Cheusov]

***@45.free.net (Victor Wagner) writes:

> Anton Petrusevich <***@att-ltd.biz> wrote:
> AP> Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
> AP> темплейтов мне очень сомнительна. Я понимаю, что от этого механизма реально
> AP> тащицца Александр Степанов, но вот лично я например, как-то не очень. Вещи
> AP> типа:
> AP> struct ltstr {
> AP> bool operator()(const std::string &s1, const std::string &s1) {
> AP> return s1 < s2;
> AP> }
> AP> };
> AP> typedef std::map<std::string key, std::string value, ltstr> std_string_hash;
> AP> typedef std::map<std::string key, std::string value, ltstr>::iterator
> AP> i_std_string_hash;
>
> AP> Hа мой взгляд, ugly.
>
> ugly, конечно. Но хоть какие-то, и на том спасибо. Если ты хочешь красивое
> generic
> programming, то нужно брать язык, который для этого изначально заточен.
> Lisp там, Haskell, Ocaml или Erlang.
>
> Несколько более корявыми, хотя намного прямее чем в C++, эти конструкции
> будут в Perl, Python и Tcl.

generic programming сам по себе никому не нужен. Он нужен для получения
хорошего быстродействия. Ни python, ни perl ни тем более lisp и tcl
тебе этого не дадут.
Про остальных не знаю.

--
Best regards, Aleksey Cheusov.

[Victor Wagner]

Aleksey Cheusov <***@scnsoft.com> wrote:

AC> generic programming сам по себе никому не нужен. Он нужен для получения
AC> хорошего быстродействия. Ни python, ни perl ни тем более lisp и tcl
AC> тебе этого не дадут.
AC> Про остальных не знаю.

Ну насчет "тем более лисп" это ты в корне неправ. Franz Lisp до сих пор
остается непревзойденным по скорости работы скомпилированного кода
компилятором среди всех языков программирования.

Еще на тему того, что могут или не могут дать языки, подобные Lisp и
Refal рекомендую взглянуть на www.supercompilers.com.

А вообще-то в 99% задач замедлением быстродействия на порядок можно
пожертвовать ради ускорения сроков разработки на порядок. И именно для
этого нужны разнообразные высокоуровневые конструкции. А уж то, что они
к тому же хорошо поддаются оптимизации (именно за счет своей
высокоуровневости) - это приятный побочный эффект.
--

[Aleksey Cheusov]

***@45.free.net (Victor Wagner) writes:

> Aleksey Cheusov <***@scnsoft.com> wrote:
>
> AC> generic programming сам по себе никому не нужен. Он нужен для
> AC> получения хорошего быстродействия. Ни python, ни perl ни тем
> AC> более lisp и tcl тебе этого не дадут. Про остальных не знаю.
>
> Ну насчет "тем более лисп" это ты в корне неправ. Franz Lisp до сих
> пор остается непревзойденным по скорости работы скомпилированного
> кода компилятором среди всех языков программирования.
>
> Еще на тему того, что могут или не могут дать языки, подобные Lisp и
> Refal рекомендую взглянуть на www.supercompilers.com.
С пропагандой функциональных языков я давно ознакомился. Теоретически
- красиво. И преимущества в чем-то где-то и когда-то тоже очевидны.

Но, видимо, не всех устраивает асимптотическая релезность в
перспективе. Большинство, видимо, предпочитает поучаствовать в
процессе оптимизации, если компилятор не справляется сам.

Что касается Лиспа, то я не понимаю, как язык, целиком и полностью
основанный на списках может быть эффективным.
Куда ни плюнь - n^2 или факториалы выползают. Жуть.
Нехилый же для него должен быть компилятор.

А вообще буду весьма благодарен тебе и/или Луговскому за ссылки на
хорошую литературу.

> А вообще-то в 99% задач замедлением быстродействия на порядок можно
> пожертвовать ради ускорения сроков разработки на порядок.
Никто и не спорит.

> И именно
> для этого нужны разнообразные высокоуровневые конструкции. А уж то,
> что они к тому же хорошо поддаются оптимизации (именно за счет своей
> высокоуровневости) - это приятный побочный эффект.
Я не против, но при условии, что "хорошо поддаются".

--
Best regards, Aleksey Cheusov.

[Victor Wagner]

Aleksey Cheusov <***@scnsoft.com> wrote:
>> Еще на тему того, что могут или не могут дать языки, подобные Lisp и
>> Refal рекомендую взглянуть на www.supercompilers.com.
AC> С пропагандой функциональных языков я давно ознакомился. Теоретически
AC> - красиво. И преимущества в чем-то где-то и когда-то тоже очевидны.

AC> Но, видимо, не всех устраивает асимптотическая релезность в
AC> перспективе. Большинство, видимо, предпочитает поучаствовать в
AC> процессе оптимизации, если компилятор не справляется сам.

Если еще учесть что это самое большинство нифига не смыслит в этой самой
оптимизации... Потому как например между 8088 и Pentium эффективность
некоторых решений поменялась строго наоборот.


AC> Что касается Лиспа, то я не понимаю, как язык, целиком и полностью
AC> основанный на списках может быть эффективным.
AC> Куда ни плюнь - n^2 или факториалы выползают. Жуть.

Это как же так писать надо чтобы n^2 и факториалы выползали? При
хвостовой-то рекурсии?

AC> Нехилый же для него должен быть компилятор.

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

AC> А вообще буду весьма благодарен тебе и/или Луговскому за ссылки на
AC> хорошую литературу.

По-моему, в FAQ RU.LISP вся хорошая литература перечислена.



>> А вообще-то в 99% задач замедлением быстродействия на порядок можно
>> пожертвовать ради ускорения сроков разработки на порядок.
AC> Никто и не спорит.

>> И именно
>> для этого нужны разнообразные высокоуровневые конструкции. А уж то,
>> что они к тому же хорошо поддаются оптимизации (именно за счет своей
>> высокоуровневости) - это приятный побочный эффект.
AC> Я не против, но при условии, что "хорошо поддаются".

Зачем тебе это? Ведь абзацем раньше ты согласился с тем, что проигрыш в
быстродействии на порядок окупается, если это позволяет сэкономить
мыслительные усилия программиста.

--

[Aleksey Cheusov]

***@45.free.net (Victor Wagner) writes:

> Aleksey Cheusov <***@scnsoft.com> wrote:
> >> Еще на тему того, что могут или не могут дать языки, подобные Lisp и
> >> Refal рекомендую взглянуть на www.supercompilers.com.
> AC> С пропагандой функциональных языков я давно ознакомился. Теоретически
> AC> - красиво. И преимущества в чем-то где-то и когда-то тоже очевидны.
>
> AC> Но, видимо, не всех устраивает асимптотическая релезность в
> AC> перспективе. Большинство, видимо, предпочитает поучаствовать в
> AC> процессе оптимизации, если компилятор не справляется сам.
>
> Если еще учесть что это самое большинство нифига не смыслит в этой самой
> оптимизации... Потому как например между 8088 и Pentium эффективность
> некоторых решений поменялась строго наоборот.
Я не про ассемблер, а про ту оптимизацию, которую предоставляют
императивные языки.

> AC> Нехилый же для него должен быть компилятор.
>
> А компилятор именно что нехилый. Ему очень помогает то, что сама
> программа это тоже список. И её очень удобно всячески преобразовывать
> при оптимизации.
Это как раз таки мелочи. Тоже самое может себе позволить любой компилятор
любого языка. Интересно, как в лиспе (и других) ты собираешься оптимизировать
код создаваемый run-time?

> >> А вообще-то в 99% задач замедлением быстродействия на порядок можно
> >> пожертвовать ради ускорения сроков разработки на порядок.
> AC> Никто и не спорит.
>
> >> И именно
> >> для этого нужны разнообразные высокоуровневые конструкции. А уж то,
> >> что они к тому же хорошо поддаются оптимизации (именно за счет своей
> >> высокоуровневости) - это приятный побочный эффект.
> AC> Я не против, но при условии, что "хорошо поддаются".
>
> Зачем тебе это? Ведь абзацем раньше ты согласился с тем, что проигрыш в
> быстродействии на порядок окупается, если это позволяет сэкономить
> мыслительные усилия программиста.
Во-первых, затем выше было что-то про 99%.
А во-вторых за тем, что с меня это требуют.
И отмазки вроде "зато я потратил на это меньше времени" никого не волнуют.
Это конкретно моя ситуация. Вначале я пишу с десяток прототипов, а потом,
извини-подвинься, приходится переписывать на С++. Многие прототипы
так ими и остаются.

--
Best regards, Aleksey Cheusov.

[Victor Wagner]

Aleksey Cheusov <***@scnsoft.com> wrote:
>> Если еще учесть что это самое большинство нифига не смыслит в этой самой
>> оптимизации... Потому как например между 8088 и Pentium эффективность
>> некоторых решений поменялась строго наоборот.
AC> Я не про ассемблер, а про ту оптимизацию, которую предоставляют
AC> императивные языки.

Те же, извиняюсь, яйца, вид сбоку. Особенно если под "императивными
языками" мы понимаем C, который является вольным переложением
ассемблера PDP-11.

Точно так же, многие "оптимизации", доступные на уровне C-кода,
например, неумеренное употребление слова register, могут привести к
СНИЖЕНИЮ производительности на другом процессоре.

Оптимизировать надо на уровне алгоритма. Хотя даже это неабсолютно.
Я могу, например, представить себе архитектуру, где использование
double для хранения таймштапа будет эффективнее чем 32-битное целое для
дней + 32битное целое для секунд внутри дня. Или где рекурсия будет
эффективнее итерации и наоборот.
>> А компилятор именно что нехилый. Ему очень помогает то, что сама
>> программа это тоже список. И её очень удобно всячески преобразовывать
>> при оптимизации.
AC> Это как раз таки мелочи. Тоже самое может себе позволить любой компилятор
AC> любого языка. Интересно, как в лиспе (и других) ты собираешься оптимизировать
AC> код создаваемый run-time?

А в Lisp- системах весь код создается run-time, а compile это такая
встроенная процедура.

>>
>> Зачем тебе это? Ведь абзацем раньше ты согласился с тем, что проигрыш в
>> быстродействии на порядок окупается, если это позволяет сэкономить
>> мыслительные усилия программиста.
AC> Во-первых, затем выше было что-то про 99%.

Ну так ты этот несчастный один процент, который действительно критичен
по быстродействию, напишешь на C или на ассемблере, и вылижешь до
требуемой скорости. У тебя будет на это время, так как 99% ты сделаешь
в десять раз быстрее.

AC> А во-вторых за тем, что с меня это требуют.
AC> И отмазки вроде "зато я потратил на это меньше времени" никого не волнуют.

Странная контора. В нормальных конторах требуют чтобы была указанная
функциональность в указанные сроки, и чтобы работало. А что там внутри -
C++ или forth - не очень волнует.


--
Ну какой я, к черту, линуксоид? У меня даже Жигули на солярке!

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> Если еще учесть что это самое большинство нифига не смыслит в этой самой
>> оптимизации... Потому как например между 8088 и Pentium эффективность
>> некоторых решений поменялась строго наоборот.
> Я не про ассемблер, а про ту оптимизацию, которую предоставляют
> императивные языки.

И что это за оптимизация? Явно повлиять на register scheduling, запудрить
оптимизатору такой самодеятельностью мозги, и получить дикого тормоза?

>> А компилятор именно что нехилый. Ему очень помогает то, что сама
>> программа это тоже список. И её очень удобно всячески преобразовывать
>> при оптимизации.
> Это как раз таки мелочи. Тоже самое может себе позволить любой компилятор
> любого языка.

Может. Hо за бОльшую цену...

> И отмазки вроде "зато я потратил на это меньше времени" никого не волнуют.
> Это конкретно моя ситуация. Вначале я пишу с десяток прототипов, а потом,
> извини-подвинься, приходится переписывать на С++. Многие прототипы
> так ими и остаются.

Деточка профайлера не видела?

[Aleksey Cheusov]

Vitaly Lugovsky <***@ontil.ihep.su> writes:

> > И отмазки вроде "зато я потратил на это меньше времени" никого не волнуют.
> > Это конкретно моя ситуация. Вначале я пишу с десяток прототипов, а потом,
> > извини-подвинься, приходится переписывать на С++. Многие прототипы
> > так ими и остаются.
>
> Деточка профайлера не видела?

Деточка в отличие от дяденьки знает задачу, о которой гооврит.

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> > И отмазки вроде "зато я потратил на это меньше времени" никого не волнуют.
>> > Это конкретно моя ситуация. Вначале я пишу с десяток прототипов, а потом,
>> > извини-подвинься, приходится переписывать на С++. Многие прототипы
>> > так ими и остаются.
>>
>> Деточка профайлера не видела?
>
> Деточка в отличие от дяденьки знает задачу, о которой гооврит.

Дяденька знает, что таких задач не бывает, где ВЕСЬ прототип приходилось бы
перепейсывать на ассемблере.

[Alexander Krotov]

Vitaly Lugovsky <***@ontil.ihep.su> wrote:
VL> И что это за оптимизация? Явно повлиять на register scheduling, запудрить
VL> оптимизатору такой самодеятельностью мозги, и получить дикого тормоза?

Виталий, деточка, вы до сих пор schedulите registerы ?

-ank

[Vitaly Lugovsky]

X-FTN-MSGID: 2:5080/***@fidonet 2b41a3f9
User-Agent: tin/1.5.14-20020926 ("Soil") (UNIX) (Linux/2.4.21pre5-vsl-up-alt1
(i686))
Xref: news.cca.usart.ru fido7.ru.unix.prog:10577

Alexander Krotov <***@despammed.com> wrote:

> VL> И что это за оптимизация? Явно повлиять на register scheduling,
> VL> запудрить
> VL> оптимизатору такой самодеятельностью мозги, и получить дикого тормоза?
>
> Виталий, деточка, вы до сих пор schedulите registerы ?

Я этим не занимаюсь, а вот кой кто - таки очень это любит. grep "register"
по гнутым сырцам - и бежать пить валерьянку.

[Alexander Krotov]

Vitaly Lugovsky <***@ontil.ihep.su> wrote:
>> VL> И что это за оптимизация? Явно повлиять на register scheduling,
>> VL> запудрить
>> VL> оптимизатору такой самодеятельностью мозги, и получить дикого тормоза?
>>
>> Виталий, деточка, вы до сих пор schedulите registerы ?
VL>
VL> Я этим не занимаюсь, а вот кой кто - таки очень это любит. grep "register"
VL> по гнутым сырцам - и бежать пить валерьянку.

kama /usr/src/contrib/gcc $ grep -i register *.c| grep -i schedu
loop.c: all the register substitutions scheduled in REG_MAP. */
loop.c: register substitutions scheduled in REG_MAP. */
reorg.c: are better handled by scheduling before register allocation (by the
toplev.c:/* The following flags have effect only for scheduling before register
toplev.c: N_("Reschedule instructions before register allocation") },
toplev.c: N_("Reschedule instructions after register allocation") },

Намек понятен ?

-ank

[Ilya Dikarev]

Vitaly Lugovsky <***@ontil.ihep.su> wrote:
>> И отмазки вроде "зато я потратил на это меньше времени" никого не волнуют.
>> Это конкретно моя ситуация. Вначале я пишу с десяток прототипов, а потом,
>> извини-подвинься, приходится переписывать на С++. Многие прототипы
>> так ими и остаются.

VL> Деточка профайлера не видела?
Кстати.... Я тут начал разбиратьсяс *ix-программированием.
Такой вот вопрос - что заюзать в качестве профайлера?

--
XMMS is in /*Silence*/

Hаизусть команду make
Знают Шапка и Mandrake

[Victor Wagner]

Ilya Dikarev <***@f984.n463.z2.fidonet.org> wrote:

VL>> Деточка профайлера не видела?
ID> Кстати.... Я тут начал разбиратьсяс *ix-программированием.
ID> Такой вот вопрос - что заюзать в качестве профайлера?

Вообще в Unix принято встраивать сборщики статистики в саму программу.
Посредством опции -p компилятора.

А чем эту выдачу анализировать - вопрос другой. Обычно я для этого gprof
применяю.


--
... И запустить всех спутниц жизни на жизнестационарную орбиту...
(c)Yarick Rastrigin

[Dmitri Vorobiev]

Ilya Dikarev wrote:
> Кстати.... Я тут начал разбиратьсяс *ix-программированием.
> Такой вот вопрос - что заюзать в качестве профайлера?

1. gcc с ключиком -pg для инструментирования бинарника;
2. gprof (man gprof) для цифирок;
3. cgprof+graphviz (freshmeat.net) для картинок.

Д. Воробьёв

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

> Hо, видимо, не всех устраивает асимптотическая релезность в
> перспективе. Большинство, видимо, предпочитает поучаствовать в
> процессе оптимизации, если компилятор не справляется сам.

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

> Что касается Лиспа, то я не понимаю, как язык, целиком и полностью
> основанный на списках может быть эффективным.

Ути-пути... Hадо иногда книжечки читать, чтоб понимать хоть что либо...

> Куда ни плюнь - n^2 или факториалы выползают. Жуть.

А массивов в Лиспе уже нет? Вах-вах, какой казол украл - шаз зарэжу гада... :(

> Hехилый же для него должен быть компилятор.

Должен. И есть. И не один.

> А вообще буду весьма благодарен тебе и/или Луговскому за ссылки на
> хорошую литературу.

А на сами компиляторы поглядеть ломает?

[Aleksey Cheusov]

Vitaly Lugovsky <***@ontil.ihep.su> writes:

> Aleksey Cheusov <***@scnsoft.com> wrote:
>
> > Hо, видимо, не всех устраивает асимптотическая релезность в
> > перспективе. Большинство, видимо, предпочитает поучаствовать в
> > процессе оптимизации, если компилятор не справляется сам.
>
> Чушь. Для этого есть всякие там Си++ и прочие подобные ассемблеры.
> Оптимизация внутренностей циклов - дело, мало касающееся возможостей
> языка в части метапрограммирования.

А я об этом и говорил.

> > Что касается Лиспа, то я не понимаю, как язык, целиком и полностью
> > основанный на списках может быть эффективным.
>
> Ути-пути... Hадо иногда книжечки читать, чтоб понимать хоть что
> либо...

Ну так посоветуй что-нибудь хорошее доброе вечное.

> > Куда ни плюнь - n^2 или факториалы выползают. Жуть.
>
> А массивов в Лиспе уже нет? Вах-вах, какой казол украл - шаз зарэжу
> гада... :(

Да есть, есть.

> > Hехилый же для него должен быть компилятор.
>
> Должен. И есть. И не один.
>
> > А вообще буду весьма благодарен тебе и/или Луговскому за ссылки на
> > хорошую литературу.
>
> А на сами компиляторы поглядеть ломает?

Как то не до этого было.
И на какие конкретно?

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> > Hо, видимо, не всех устраивает асимптотическая релезность в
>> > перспективе. Большинство, видимо, предпочитает поучаствовать в
>> > процессе оптимизации, если компилятор не справляется сам.
>>
>> Чушь. Для этого есть всякие там Си++ и прочие подобные ассемблеры.
>> Оптимизация внутренностей циклов - дело, мало касающееся возможостей
>> языка в части метапрограммирования.
>
> А я об этом и говорил.

е-а. Ви гойворили, что ви антисемит. У меня все ходы запейсаны.

>> Ути-пути... Hадо иногда книжечки читать, чтоб понимать хоть что
>> либо...
>
> Hу так посоветуй что-нибудь хорошее доброе вечное.

Джойнера, хотя бы.

>> > Куда ни плюнь - n^2 или факториалы выползают. Жуть.
>>
>> А массивов в Лиспе уже нет? Вах-вах, какой казол украл - шаз зарэжу
>> гада... :(
>
> Да есть, есть.

Hу так откуда n^2 тогда?

>> > А вообще буду весьма благодарен тебе и/или Луговскому за ссылки на
>> > хорошую литературу.
>>
>> А на сами компиляторы поглядеть ломает?
>
> Как то не до этого было.
> И на какие конкретно?

CMU CL. Или на его младшего бератищьку SBCL (http://sbcl.sourceforge.net).

[Aleksey Cheusov]

Vitaly Lugovsky <***@ontil.ihep.su> writes:

> > Hу так посоветуй что-нибудь хорошее доброе вечное.
>
> Джойнера, хотя бы.

Не. Ты все-таки спроецируй свою многомерную библиотеку сюда
или в ru.lisp или мне по email.
Найти сам я конечно могу, но интересно, какие книги считаешь хорошими ты.
Не только по лиспу, но и по функциональщине вообще.

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

> Hе. Ты все-таки спроецируй свою многомерную библиотеку сюда
> или в ru.lisp или мне по email.

Ouch. Hе в тему сослался. Джойнер - про уродство C++, да ещё и с позиций
ООПщины пишет.

> Hайти сам я конечно могу, но интересно, какие книги считаешь хорошими ты.
> Hе только по лиспу, но и по функциональщине вообще.

Много чего по Лиспу, включая особенности компиляции:

http://www.paulgraham.com/

По функциональщине вообще - мой любимый Харрисон:

http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html

[Dmitry Astapov]

Evening, Aleksey.

Aleksey Cheusov <***@scnsoft.com> 16:55 04/11/2003 wrote:

AC> Что касается Лиспа, то я не понимаю, как язык, целиком и полностью
AC> основанный на списках может быть эффективным. Куда ни плюнь - n^2 или
AC> факториалы выползают. Жуть. Hехилый же для него должен быть
AC> компилятор.

Hе совсем про Lisp, но все же. В google по словам list fusion можно нарыть
некоторое колво статей про то, как при компиляции программ вида "из списка
А получить список Б, из него - список Ц, из него - Д, из него - Е, и вот
его-то и вывести" можно устранять операции создания всех промежуточных
структур данных (т.е. списков Б, Ц, Д, Е). Очень способствует эффективной
компиляции програм, целиком и полностью основаных на списках ...

--
Dmitry Astapov //ADEpt
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

> generic programming сам по себе никому не нужен.

Ути-пути...

> Он нужен для получения хорошего быстродействия.

Ути-пути... А для DSL-ей всяких, деточка, он не нужен? В садик, деточка...

> Hи python, ни perl ни тем более lisp и tcl тебе этого не дадут.

Ути-пути... CMU CL разве не уделает всякую C++-парашу? В садик, деточка...

[Aleksey Cheusov]

Vitaly Lugovsky <***@ontil.ihep.su> writes:

> > Hи python, ни perl ни тем более lisp и tcl тебе этого не дадут.
>
> CMU CL разве не уделает всякую C++-парашу?

Прямо вот так вот просто взял и уделал на любой задаче.
Щаз.... :)))

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> > Hи python, ни perl ни тем более lisp и tcl тебе этого не дадут.
>>
>> CMU CL разве не уделает всякую C++-парашу?
>
> Прямо вот так вот просто взял и уделал на любой задаче.
> Щаз.... :)))

Hе на любой, но почти на любой. Hо там, где может быть уместно
метапрограммирование - уделает. Там, где не уделает - всё равно всегда
найдётся язык, на порядки более приспособленный, чем параша-C++.

[Lev Serebryakov]

What do you think about sharp blades, Vitaly?

[Answer on] [Vitaly Lugovsky wrote to Aleksey Cheusov at [11 Nov 03 17:50]]:

>> Прямо вот так вот просто взял и уделал на любой задаче.
>> Щаз.... :)))
VL> Hе на любой, но почти на любой. Hо там, где может быть уместно
VL> метапрограммирование - уделает. Там, где не уделает - всё равно всегда
VL> найдётся язык, на порядки более приспособленный, чем параша-C++.
И я скажу, что уже говорил в RU.GNU: это все здорово, когда на каждое блюдо
своя вилка. Hо в 95% случаев все можно HОРМАЛЬHО есть обычной вилкой среднего
качества. C++ -- как раз такая вилка. Уже не алюминевая, к счастью, но и не
специальная, именно для тушеного мяса с авокадо.

Remember, pain is part of pleasure, Vitaly.
... И двери хлопнули за спиной, как капкан...

[Vitaly Lugovsky]

Lev Serebryakov <***@p1.f661.n5030.z2.fidonet.org> wrote:

> VL> Hе на любой, но почти на любой. Hо там, где может быть уместно
> VL> метапрограммирование - уделает. Там, где не уделает - всё равно всегда
> VL> найдётся язык, на порядки более приспособленный, чем параша-C++.
> И я скажу, что уже говорил в RU.GNU: это все здорово, когда на каждое блюдо
> своя вилка. Hо в 95% случаев все можно HОРМАЛЬHО есть обычной вилкой среднего
> качества. C++ -- как раз такая вилка. Уже не алюминевая, к счастью, но и не
> специальная, именно для тушеного мяса с авокадо.

Да какая это вилка. Это ложка деревянная. Расписная.
Вилка - это хотя бы связка bash+python+C...

[Anton Petrusevich]

Vitaly Lugovsky wrote:

>> среднего качества. C++ -- как раз такая вилка. Уже не алюминевая, к
>> счастью, но и не специальная, именно для тушеного мяса с авокадо.
> Да какая это вилка. Это ложка деревянная. Расписная.
> Вилка - это хотя бы связка bash+python+C...

Ох. И какой только бред тут не прочитаешь...
--
Anton Petrusevich

[Ivan Boldyrev]

"LS" == Lev Serebryakov writes:
LS> C++ -- как раз такая вилка.

И эту зубочистку вы называете вилкой? Уж луше китайскими палочками
пользоваться...

:)

--
Ivan Boldyrev

.signature is under construction.

[Vitaly Lugovsky]

Ivan Boldyrev <***@dataeast.ru> wrote:

> LS> C++ -- как раз такая вилка.
>
> И эту зубочистку вы называете вилкой? Уж луше китайскими палочками
> пользоваться...

А вот на палочки попрошу не наезжать. Палочки - значительно удобнее всяких
там ваших евро-пейсских вилок.

[Ivan Boldyrev]

"VL" == Vitaly Lugovsky writes:
VL> Ivan Boldyrev <***@dataeast.ru> wrote:
>> LS> C++ -- как раз такая вилка.
>>
>> И эту зубочистку вы называете вилкой? Уж луше китайскими палочками
>> пользоваться...

VL> А вот на палочки попрошу не наезжать. Палочки - значительно
VL> удобнее всяких там ваших евро-пейсских вилок.

А где тут наезд, а? :)

--
Ivan Boldyrev

Иногдаун -- человек, который иногда тупит.

[Vitaly Lugovsky]

Ivan Boldyrev <***@dataeast.ru> wrote:

>>> LS> C++ -- как раз такая вилка.
>>>
>>> И эту зубочистку вы называете вилкой? Уж луше китайскими палочками
>>> пользоваться...
>
> VL> А вот на палочки попрошу не наезжать. Палочки - значительно
> VL> удобнее всяких там ваших евро-пейсских вилок.
>
> А где тут наезд, а? :)

Дык палочки - это хорошо, а C++ - это плохо. ;)

ЗЫ: у меня вечная проблема - палочки нигде не продаются... :(

[Lev Serebryakov]

What do you think about sharp blades, Vitaly?

[Answer on] [Vitaly Lugovsky wrote to Ivan Boldyrev at [16 Nov 03 09:20]]:

VL> ЗЫ: у меня вечная проблема - палочки нигде не продаются... :(
У нас в Питере HЕ HАЙТИ палочки -- это большая проблема. Потому как продаются
очень много где, от одноразовых из прессованого бамбука до дорогрущих из
настоящей слоновой кости, с эмалевой финфитью, etc.
Hеужели у вас в Екатиренбурге проблемы? Ой, да, ты же где-то в США... И что,
там проблемы?! То жалуетесь, что китайцев -- не продохнуть, а тут палочки не
купить...

Впрочем, все это оффтопик...

Remember, pain is part of pleasure, Vitaly.
... Ты чувствуешь озон - это коронный разряд...

[Ivan Boldyrev]

"VL" == Vitaly Lugovsky writes:
VL> Ivan Boldyrev <***@dataeast.ru> wrote:
>>>> LS> C++ -- как раз такая вилка.
>>>>
>>>> И эту зубочистку вы называете вилкой? Уж луше китайскими палочками
>>>> пользоваться...
>>
>> VL> А вот на палочки попрошу не наезжать. Палочки - значительно
>> VL> удобнее всяких там ваших евро-пейсских вилок.
>>
>> А где тут наезд, а? :)

VL> Дык палочки - это хорошо, а C++ - это плохо. ;)

Вот и я говорю -- лучше :)

--
Ivan Boldyrev

И немного о себе: не женат, не брит, не воспитан.

[Nickita A Startcev]

Привет, Lev !


11 Nov 03 , 23:27 Lev Serebryakov писал к Vitaly Lugovsky:

VL>> всегда найдётся язык, на порядки более приспособленный, чем
VL>> параша-C++.
LS> И я скажу, что уже говорил в RU.GNU: это все здорово, когда на
LS> каждое блюдо своя вилка. Hо в 95% случаев все можно HОРМАЛЬHО есть
LS> обычной вилкой среднего качества. C++ -- как раз такая вилка. Уже не
LS> алюминевая, к счастью, но и не специальная, именно для тушеного мяса с
LS> авокадо.

Кроме вилки еще нужна тарелка/блюдце/ковшик. В смысле либы всякие удобные или
визивизгливая среда. А иногда и ложка типа интерпретируемых-скриптовых языков
нужна.

. С уважением, Hикита.
... "Пыль толще 1 см падает сама".

[Alexandr Molchevsky]

Hello Lev.

11 Nov 03 23:27, you wrote to Vitaly Lugovsky:

>>> Прямо вот так вот просто взял и уделал на любой задаче.
>>> Щаз.... :)))
VL>> Hе на любой, но почти на любой. Hо там, где может быть уместно
VL>> метапрограммирование - уделает. Там, где не уделает - всё равно
VL>> всегда найдётся язык, на порядки более приспособленный, чем
VL>> параша-C++.
LS> И я скажу, что уже говорил в RU.GNU: это все здорово, когда на
LS> каждое блюдо своя вилка. Hо в 95% случаев все можно HОРМАЛЬHО есть
LS> обычной вилкой среднего качества. C++ -- как раз такая вилка. Уже не
LS> алюминевая, к счастью, но и не специальная, именно для тушеного мяса с
LS> авокадо.

Что-то мне С++ больше палочки китайские напоминает. :)

Alexandr

[Lev Serebryakov]

[Answering from] [FOR.SYSOP]

What do you think about sharp blades, Alexandr?

[Answer on] [Alexandr Molchevsky wrote to Lev Serebryakov at [12 Nov 03
23:55]]:

VL>>> Hе на любой, но почти на любой. Hо там, где может быть уместно
VL>>> метапрограммирование - уделает. Там, где не уделает - всё равно
VL>>> всегда найдётся язык, на порядки более приспособленный, чем
VL>>> параша-C++.
LS>> И я скажу, что уже говорил в RU.GNU: это все здорово, когда на
LS>> каждое блюдо своя вилка. Hо в 95% случаев все можно HОРМАЛЬHО
LS>> есть обычной вилкой среднего качества. C++ -- как раз такая
LS>> вилка. Уже не алюминевая, к счастью, но и не специальная, именно
LS>> для тушеного мяса с авокадо.
AM> Что-то мне С++ больше палочки китайские напоминает. :)
Это еще и лучше -- они таки удобнее вилки, если уметь ими пользоватся :)

А вообще-то, договоритесь между собой с Ivan Boldyrev, палочки или зубочистка
:)

Remember, pain is part of pleasure, Alexandr.
... ...Слышишь - дай мне канал связи!

[Ivan Boldyrev]

"LS" == Lev Serebryakov writes:

AM>> Что-то мне С++ больше палочки китайские напоминает. :)

LS> Это еще и лучше -- они таки удобнее вилки, если уметь ими
LS> пользоватся :)

LS> А вообще-то, договоритесь между собой с Ivan Boldyrev, палочки
LS> или зубочистка :)

:) Предлагаю компромисс: C++ -- это две зубочистки, которые к
настоящим китайским палочкам отношения не имеет :)

--
Ivan Boldyrev

Девушки, я вас люблю! БУДЬТЕ ОСТОРОЖНЫ!

[Vitaly Lugovsky]

Anton Petrusevich <***@att-ltd.biz> wrote:

>> Затем, что если это не будут делать они, это придется делать в том или
>> ином виде либо программисту руками (например, реализовывать аналог
>> темплейтов) либо рантайм-системе. И то и другое - дороже.
>
> Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
> темплейтов мне очень сомнительна.

Темплейты в C++ нужны хотя бы для того, чтоб он немножко был бы похож на
язык программирования (без них он уж вовсе - полное дерьмо).

> Я понимаю, что от этого механизма реально
> тащицца Александр Степанов, но вот лично я например, как-то не очень. Вещи
> типа:
> struct ltstr {
> bool operator()(const std::string &s1, const std::string &s1) {
> return s1 < s2;
> }
> };
> typedef std::map<std::string key, std::string value, ltstr> std_string_hash;
> typedef std::map<std::string key, std::string value, ltstr>::iterator
> i_std_string_hash;
>
> Hа мой взгляд, ugly. По такому хешу в gdb _очень_ сложно посмотреть
> содержимое. И я понимаю его трудности. А когда мне нужен хеш хешей... А как
> это всё "приятно" в использовании...

Темплейты (то бишь, полиморфизм) нужны хотя бы для того, как минимум, чтоб
избавиться от идиотской потребности в использовании всяких там gdb.

[Aleksey Cheusov]

Vitaly Lugovsky <***@ontil.ihep.su> writes:

> Anton Petrusevich <***@att-ltd.biz> wrote:
>
> >> Затем, что если это не будут делать они, это придется делать в том или
> >> ином виде либо программисту руками (например, реализовывать аналог
> >> темплейтов) либо рантайм-системе. И то и другое - дороже.
> >
> > Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
> > темплейтов мне очень сомнительна.
>
> Темплейты в C++ нужны хотя бы для того, чтоб он немножко был бы похож на
> язык программирования (без них он уж вовсе - полное дерьмо).

Темплейтов маловато. Попробуй на них реализовать Bridge
не потеряв при этом динамического полиморфизма.
Вызов функции - жалкое подобие на то, что нужно.

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> > Чесслово, не углубляясь в глубокий спор, необходимость наличия механизма
>> > темплейтов мне очень сомнительна.
>>
>> Темплейты в C++ нужны хотя бы для того, чтоб он немножко был бы похож на
>> язык программирования (без них он уж вовсе - полное дерьмо).
>
> Темплейтов маловато.

Дык. Hо без них - это вообще не язык.

[Alexander Krotov]

Anton Petrusevich <***@att-ltd.biz> wrote:
AP> Hа мой взгляд, ugly. По такому хешу в gdb _очень_ сложно посмотреть
AP> содержимое. И я понимаю его трудности. А когда мне нужен хеш хешей... А как
AP> это всё "приятно" в использовании...

Не нужно по такому хешу ходить gdb. Вредно это "как само по себе,
так и в общих чертах". Абсолютно пустая трата сил.

Я к stlевским контейнерам отношусь примерно как к коду, сгенерированному
yaccом: Разбирать сгенерированный код бесполезно. Нужно печатать содержимое
контейнера или лог вызываемых функций.

-ank

[Anton Petrusevich]

Aleksey Cheusov wrote:

> Лично я использую абстрактные классы в перемешку в темплейтами.
> Вторых на порядок меньше, но иногда без них никуда. Скорость, знаешь ли.

Скорость _чего_? Если получаемой программы, то лучше доброго Си ещё ничего
не придумали. Программу на С++ из 5,5 тыщ строк я писал месяц. Программу на
Си из 2,5 тыщ строк -- неделю. Первую отлаживал потом полтора месяца
(привет std::string и их тредовой небезопасности!), пока все стали
довольны, вторую отлаживал 3 дня, пока поймал последнюю ошибку. О скорости
_чего_ мы тут говорим? О результирующей скорости программ? Дык тут тоже С++
_лучше_ быть не может. Для ясности, это были разные программы, хотя
участвовали в общем деле :)

Меня С++ "подкупает" своей лёгкостью создания сложных структур данных, но
почему-то реального выигрыша я не вижу. Получается, что на Си у меня
программы начинают реально работать без ошибок быстрее (если
проэкстраполировать результат 2,5 тыщ строк до 5,5). Hынче та программа на
С++ уже 7,5 тыщ строк, но вот более новую версию я уже даже не знаю, стоит
ли писать на С++ или снова вернуться на Си. Возможно, портануть из STL
класс аллокаторов (дефолтный вроде там неплох) в Си, исправить одну-две
функции в своих сишных строчках, чтобы это дело пользовали... Единственный
минус неиспользования С++, на который я реально напоролся, это то, что
после 4х лет неиспользования С++ начинаешь его подзабывать, и тесты при
приёме на работу уже не очень гладко проходят. Особенно, когда большинство
вопросов по STL, которую в жизни ни разу не пользовал (ну не было в 97г ещё
STL в стандартных поставках, а тест проходил в 2001 в USA).
--
Anton Petrusevich

[Vitaly Lugovsky]

Anton Petrusevich <***@att-ltd.biz> wrote:

>> Лично я использую абстрактные классы в перемешку в темплейтами.
>> Вторых на порядок меньше, но иногда без них никуда. Скорость, знаешь ли.
>
> Скорость _чего_? Если получаемой программы, то лучше доброго Си ещё ничего
> не придумали.

Да ну?!?

> Программу на С++ из 5,5 тыщ строк я писал месяц. Программу на
> Си из 2,5 тыщ строк -- неделю.

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

> Первую отлаживал потом полтора месяца
> (привет std::string и их тредовой небезопасности!),

Отладка - суксь.

> пока все стали
> довольны, вторую отлаживал 3 дня, пока поймал последнюю ошибку. О скорости
> _чего_ мы тут говорим? О результирующей скорости программ? Дык тут тоже С++
> _лучше_ быть не может.

Теоретически - может. Темплейт - это хоть какой-то хинт компилятору.
Ручками же оптимизированный код на Си - никакой компилятор не
переоптимизирует.

> Меня С++ "подкупает" своей лёгкостью создания сложных структур данных,

Ой? Где же это в C++ такая лёгкость?!? Си++ в этом отношении крив и
отвратителен. Для этого надо пользоваться языками, в которых есть
алгебраические типы данных (то есть, статически типизированными языками).

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> Aleksey Cheusov wrote:
>
> > Лично я использую абстрактные классы в перемешку в темплейтами.
> > Вторых на порядок меньше, но иногда без них никуда. Скорость, знаешь ли.
>
> Скорость _чего_? Если получаемой программы, то лучше доброго Си ещё ничего
> не придумали.
Ты очень сильно ошибаешься.

> Программу на С++ из 5,5 тыщ строк я писал месяц. Программу на
> Си из 2,5 тыщ строк -- неделю. Первую отлаживал потом полтора месяца
> (привет std::string и их тредовой небезопасности!), пока все стали
> довольны, вторую отлаживал 3 дня, пока поймал последнюю ошибку.
Ты просто не умеешь писать на С++.
А std::string-ом кстати никто тебя пользоваться не заставлял.
Я лично от этого шила держусь подальше.

> О скорости
> _чего_ мы тут говорим? О результирующей скорости программ?
Да.

> Дык тут тоже С++
> _лучше_ быть не может.
Ты ошибаешься.
Сравни на досуге qsort и std::sort.
Это только один простейший пример.

> Меня С++ "подкупает" своей лёгкостью создания сложных структур данных, но
> почему-то реального выигрыша я не вижу.
Если твои "сложные" структуры данных умещаются в С,
да к тому же еще и поддаются пониманию,
значит СЛОЖНЫХ структур ты просто никогда и не создавал.

> Получается, что на Си у меня
> программы начинают реально работать без ошибок быстрее (если
> проэкстраполировать результат 2,5 тыщ строк до 5,5).
Во-первых действительно "У ТЕБЯ". А во вторых 5.5 тысяч строк
это еще не программа, а лабораторная работа студента. Когда у тебя будет
155.5 тысяч ты запоешь по-другому.
А проекты такого размера (и больше) пишут на С люди,
которые это умеют делать.

> Hынче та программа на
> С++ уже 7,5 тыщ строк, но вот более новую версию я уже даже не знаю, стоит
> ли писать на С++ или снова вернуться на Си. Возможно, портануть из STL
> класс аллокаторов (дефолтный вроде там неплох) в Си, исправить одну-две
> функции в своих сишных строчках, чтобы это дело пользовали...
Не сошелся свет клином на STL.

--
Best regards, Aleksey Cheusov.

[Alexander Krotov]

Aleksey Cheusov <***@scnsoft.com> wrote:
>> Меня С++ "подкупает" своей лёгкостью создания сложных структур данных, но
>> почему-то реального выигрыша я не вижу.
AC> Если твои "сложные" структуры данных умещаются в С,
AC> да к тому же еще и поддаются пониманию,
AC> значит СЛОЖНЫХ структур ты просто никогда и не создавал.

Распечатал и повесил на стенку.

-ank

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> Aleksey Cheusov wrote:
>
> > Лично я использую абстрактные классы в перемешку в темплейтами.
> > Вторых на порядок меньше, но иногда без них никуда. Скорость, знаешь ли.
>
> Скорость _чего_? Если получаемой программы, то лучше доброго Си ещё ничего
> не придумали.

Кстати, gcc не умеет сворачивать рекурсию в циклы, поэтому (и не только)
на некоторых искуственных тестах всякая функциональщина вроде ocaml-а
оказывается быстрее. К тому жу оптимизация
в пределах одной функции/одного объектного файла - далеко не все,
что можно было бы сделать. Поищи в google по слову shootout.
Forth-е, например,
за счет того, что параметры не заталкиваются в стек по десять
раз тогда, когда это не нужно, тоже может оказаться быстрее.
Так что не все так однозначно.

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

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

Хвостовую рекурсию gcc давно уже умеет. Его тормознутость в другом
заключается...

[Max Khon]

hi, there!

04 Nov 03 00:17, I wrote to Evgeny Lenkevich:

>>> И понятие "аналогичности" в случае ObjectPascal, который исходно,
>>> на уровне дизайна языка, заточен под быструю однопроходную
>>> компиляцию versus C++ с ее двухэтажным препроцессором (сначала
>>> обычным C-шным, а потом template всякими) это вопрос достаточно
>>> дискуссионный.

EL>> Глупый вопрос: а зачем С++ компилеры так работают, в чем тут
EL>> дело?

MK> в недоделанности и в особенностях языка. в g++, например, понятие

в недоделанности компиляторов имелось ввиду конечно же.
появилась плохая привычка слова в фразах пропускать.

MK> precompiled headers отсутствует, а на win32 без специальных
MK> телодвижений (простых, но их делать приходится) они тоже не
MK> включаются.

/fjoe

[Vitaly Lugovsky]

Max Khon <***@f79.n5000.z2.fidonet.org> wrote:

> MK> в недоделанности и в особенностях языка. в g++, например, понятие
>
> в недоделанности компиляторов имелось ввиду конечно же.
> появилась плохая привычка слова в фразах пропускать.

Языка тоже. Понятия "модуль" в этом портабельном псевдоассемблере придумать
не догадались, систему типов сохранили так же ассемблерную... Отсюда и
необходимость во всяких там тяжеловесных препроцессорах с include...

[Max Khon]

hi, there!

04 Nov 03 13:14, you wrote to me:

>> MK> в недоделанности и в особенностях языка. в g++, например,
>> MK> понятие
>>
>> в недоделанности компиляторов имелось ввиду конечно же.
>> появилась плохая привычка слова в фразах пропускать.

VL> Языка тоже. Понятия "модуль" в этом портабельном псевдоассемблере
VL> придумать не догадались, систему типов сохранили так же
VL> ассемблерную... Отсюда и необходимость во всяких там тяжеловесных
VL> препроцессорах с include...

языка тоже, но это к теме не относится
и вообще давно уже в оффттопик вылезли :)

/fjoe

[Anton Petrusevich]

Alexander Krotov wrote:

> Hе нужно по такому хешу ходить gdb. Вредно это "как само по себе,
> так и в общих чертах". Абсолютно пустая трата сил.
>
> Я к stlевским контейнерам отношусь примерно как к коду, сгенерированному
> yaccом: Разбирать сгенерированный код бесполезно. Hужно печатать
> содержимое контейнера или лог вызываемых функций.

Я тут больше про core dumped говорю.
--
Anton Petrusevich

[Alexander Krotov]

Anton Petrusevich <***@att-ltd.biz> wrote:
>> Hе нужно по такому хешу ходить gdb. Вредно это "как само по себе,
>> так и в общих чертах". Абсолютно пустая трата сил.
>>
>> Я к stlевским контейнерам отношусь примерно как к коду, сгенерированному
>> yaccом: Разбирать сгенерированный код бесполезно. Hужно печатать
>> содержимое контейнера или лог вызываемых функций.
AP>
AP> Я тут больше про core dumped говорю.

Извиняюсь, неправильно понял.

-ank

[Anton Petrusevich]

Victor Wagner wrote:

> Я бы сказал, что threads это проблема не только у STL. Те же проблемы
> и у Perl, и у Tcl.

Ох... Perl... При "грамотном" использовании он у меня корки бросал тока шум
стоял... :)

> Если речь идет об эхотаге, то как правило fork + явно выделенные области
> общей памяти через SysV IPC или mmap гораздо выгоднее. Даже в тех
> разновидностях эхотага, где fork относительно дорогой, например в
> Solaris.

Я принял бы это как решение, если б не нужно было городить поверх всего
этого какой-то динамический аллокатор. Впрочем, говорят, что переключение
контекстов между тредами в современном линуксе 2.6 _намного_ дешевле чем
переключение контекстов между процессами. А это тоже аргумент когда речь
идёт о десятке тысяч процессов/ниток. По поводу супер скалябельности FSM и
особенностей работы/реализации я спорить не буду, для девелопмента сложных
вещей когда машина состояний определяется окончательно только в процессе
разработки, когда нужно учитывать особенности активны/не очень активных
соединений, когда единственный переносимый API poll/select провоцирует
нагрузку на цпу чтобы найти виновников событий, я считаю, FSM применима
плохо. Впрочем, убеждать никого не берусь.

--
Anton Petrusevich

[Anton Petrusevich]

Valentin Nechayev wrote:

> Э... а... а какая при этом реализация? И где проблема?

libstdc++, из родной поставки gcc 3.2. Проблема в падающих корках.
http://www.sgi.com/tech/stl/string_discussion.html -- здесь в самом начале
объяснение.

> Мне так навскидку показалось, что влияет внутренний string buffer, который
> шарится между ветками, и если ветки своими локами синхронизируют доступ
> к своим видимым данным - это не влияет на string buffers видимые из них.
> Угадал?

Да я утрахался с синхронизацией, по одним и тем же местам на 50 раз всё
просмотрел -- не видел никаких ошибок.

> Аналогичные проблемы могут быть и с деревьями/хэшами, хоть и не столь
> прямолинейно.

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

> AP> Я честно пытался
> AP> "расшаривать" все строчки что могут совместно использоваться нитками
> AP> (методом { return string(s.data(), s.size()); } ), мне это никак не
> AP> помогало. Пока не избавился от std::string совсем.
>
> А что взамен? Своё без промежуточного "буфера"?

Да.
--
Anton Petrusevich

[Anton Petrusevich]

Aleksey Cheusov wrote:

> Ты просто не умеешь писать на С++.

После 6-летнего перерыва начал снова писать на С++ в феврале. И обнаружил
что это уже совсем не тот С++ что я помнил. Тут спорить не буду.

> А std::string-ом кстати никто тебя пользоваться не заставлял.
> Я лично от этого шила держусь подальше.

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

>> Дык тут тоже С++
>> _лучше_ быть не может.
> Ты ошибаешься.
> Сравни на досуге qsort и std::sort.
> Это только один простейший пример.

М... Пример использования генерик программирования? Hу чесслово, когда мне
станет критично время работы qsort, я напишу свой, специально
оптимизированный sort, который будет не медленнее. Я понимаю, что тут дело
в принципиальной необходимости указателя на функцию сравнения для генерик
решения на Си, и в возможности инлайновой подстановки на С++. Есть
_несколько_ плюсов у генерик программирования. Hо непринципиальных, по
большому счёту.

> Если твои "сложные" структуры данных умещаются в С,
> да к тому же еще и поддаются пониманию,
> значит СЛОЖHЫХ структур ты просто никогда и не создавал.

Да где уж мне... Я как-то по простому всё, списки, хеши, деревья, строчки,
массивы... А так чтобы придумать СЛОЖHУЮ структуру, которую бы я сам не
понимал -- не удавалось. Тут нужен гениальный мозг, который бы придумывал
то, что сам не понимал, мне такое не светит.

> Во-первых действительно "У ТЕБЯ". А во вторых 5.5 тысяч строк
> это еще не программа, а лабораторная работа студента. Когда у тебя будет
> 155.5 тысяч ты запоешь по-другому.

Я это, я не злобный совсем уж буратин. Когда надо писать в одной программе
больше 7-8 тыщ строк, я начинаю думать как разбить программу на части,
чтобы это были уже отдельные программы. Иначе мэинтэйнэбилити летит в ...

> А проекты такого размера (и больше) пишут на С люди,
> которые это умеют делать.

Честь им и хвала. И как они поют?

> Hе сошелся свет клином на STL.

Окей. Хотелось бы узнать реально используемые альтернативы. Чтоб большие
проекты, непонятные и СЛОЖHЫЕ структуры данных, без проблем в малтитредовом
окружении, результирующая программа эффективнее чем на Си.
--
Anton Petrusevich

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> > А std::string-ом кстати никто тебя пользоваться не заставлял.
> > Я лично от этого шила держусь подальше.
>
> О! И что взамен?
Не поверишь. char *.
МНЕ хватает. А std::string я использую только там, где мне нужна скорость.

> >> Дык тут тоже С++
> >> _лучше_ быть не может.
> > Ты ошибаешься.
> > Сравни на досуге qsort и std::sort.
> > Это только один простейший пример.
>
> М... Пример использования генерик программирования?
Насколько я понимаю generic programming, оно не имеет никакого отношения к
темплейтам. Темплйты - всего-лишь способ реализации.

> > Если твои "сложные" структуры данных умещаются в С,
> > да к тому же еще и поддаются пониманию,
> > значит СЛОЖHЫХ структур ты просто никогда и не создавал.
>
> Да где уж мне... Я как-то по простому всё, списки, хеши, деревья, строчки,
> массивы... А так чтобы придумать СЛОЖHУЮ структуру, которую бы я сам не
> понимал -- не удавалось. Тут нужен гениальный мозг, который бы придумывал
> то, что сам не понимал, мне такое не светит.

:))) Имелся ввиду код. написанный на С для СЛОЖНЫХ структур данных.

> > Hе сошелся свет клином на STL.
>
> Окей. Хотелось бы узнать реально используемые альтернативы. Чтоб большие
> проекты, непонятные и СЛОЖHЫЕ структуры данных, без проблем в малтитредовом
> окружении, результирующая программа эффективнее чем на Си.

Если в двух словах, но я считаю весьма полезным совместное использование
темплейтов и абстрактных классов. По крайней мере это очень неплохо работает
у меня. Первые - там, где нужно чего-нибудь чекономить.
Вторые - там, где нужна гибкость.
А если ты о внешних библиотеках, то мне как раз они не нужны.
Практически все, что нужно, уже написано. А то, что есть open source
для этого дела - фе-е-е-е...

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> О! И что взамен?
> Hе поверишь. char *.

ASCIIZ? А если Z в конце прокакали? ;)

[Aleksey Cheusov]

Vitaly Lugovsky <***@ontil.ihep.su> writes:

> Aleksey Cheusov <***@scnsoft.com> wrote:
>
> >> О! И что взамен?
> > Hе поверишь. char *.
>
> ASCIIZ? А если Z в конце прокакали? ;)

А прокакать можно все что угодно.

--
Best regards, Aleksey Cheusov.

[Vitaly Lugovsky]

Aleksey Cheusov <***@scnsoft.com> wrote:

>> >> О! И что взамен?
>> > Hе поверишь. char *.
>>
>> ASCIIZ? А если Z в конце прокакали? ;)
>
> А прокакать можно все что угодно.

Hо нолик прокакать проще. ASCIIZ таки надо давить... Этот кошмар пора бы
уже даво забыть на фиг...

[Nikita Melnikov]

Vitaly Lugovsky <***@ontil.ihep.su> wrote:

>>> >> О! И что взамен?
>>> > Hе поверишь. char *.
>>> ASCIIZ? А если Z в конце прокакали? ;)
>> А прокакать можно все что угодно.
VL> Hо нолик прокакать проще. ASCIIZ таки надо давить... Этот кошмар пора бы
VL> уже даво забыть на фиг...
И что ты предлагаешь в замен? Мне интересно, какая реализация именно тебе
кажется оптимальной.

--
Nikita Melnikov
xmms: DJ Sparks - Drug Store

[Vitaly Lugovsky]

Nikita Melnikov <***@p128.f956.n5030.z2.fidonet.org> wrote:

> VL> Hо нолик прокакать проще. ASCIIZ таки надо давить... Этот кошмар пора бы
> VL> уже даво забыть на фиг...
> И что ты предлагаешь в замен? Мне интересно, какая реализация именно тебе
> кажется оптимальной.

ASCIID, конечно же.

[Valentin Nechayev]

>>> Vitaly Lugovsky wrote:

> VL>> Hо нолик прокакать проще. ASCIIZ таки надо давить... Этот кошмар пора бы
> VL>> уже даво забыть на фиг...
>> И что ты предлагаешь в замен? Мне интересно, какая реализация именно тебе
>> кажется оптимальной.
VL> ASCIID, конечно же.

Расшифруй.


-netch-

[Vitaly Lugovsky]

Valentin Nechayev <***@segfault.kiev.ua> wrote:

>> VL>> Hо нолик прокакать проще. ASCIIZ таки надо давить... Этот кошмар пора
>> VL>> бы
>> VL>> уже даво забыть на фиг...
>>> И что ты предлагаешь в замен? Мне интересно, какая реализация именно тебе
>>> кажется оптимальной.
> VL> ASCIID, конечно же.
>
> Расшифруй.

Это в VAX/VMS такая конвенция была, строка с дескриптором. В дескрипторе -
длина строки, и, возможно, адрес продолжения строки (то есть - строка может
быть однонаправленным списком, что есть быть удобно для операций
конкатенации - которые сейчас жрут, как я подозреваю, больше половины
вычислительных ресурсов человечества...).

[Andrey Sverdlichenko]

On Sun, 16 Nov 2003 09:19:09 +0300, Vitaly Lugovsky wrote:

> Это в VAX/VMS такая конвенция была, строка с дескриптором. В
> дескрипторе -
> длина строки, и, возможно, адрес продолжения строки (то есть - строка
> может быть однонаправленным списком, что есть быть удобно для операций
> конкатенации - которые сейчас жрут, как я подозреваю, больше половины
> вычислительных ресурсов человечества...).

std::rope, что ли?

[Nikita Melnikov]

Vitaly Lugovsky <***@ontil.ihep.su> wrote:

>>> VL>> Hо нолик прокакать проще. ASCIIZ таки надо давить... Этот кошмар
>>> VL>> пора
>>> VL>> бы
>>> VL>> уже даво забыть на фиг...
>>>> И что ты предлагаешь в замен? Мне интересно, какая реализация именно тебе
>>>> кажется оптимальной.
>> VL> ASCIID, конечно же.
>>
>> Расшифруй.

VL> Это в VAX/VMS такая конвенция была, строка с дескриптором. В дескрипторе
VL> -
VL> длина строки, и, возможно, адрес продолжения строки (то есть - строка
VL> может
VL> быть однонаправленным списком, что есть быть удобно для операций
VL> конкатенации - которые сейчас жрут, как я подозреваю, больше половины
VL> вычислительных ресурсов человечества...).

А в живом виде он где-нибудь присутсвует?


--
Nikita Melnikov
xmms: Spirit - Spellbound

[Anton Petrusevich]

Aleksey Cheusov wrote:

> Forth-е, например,
> за счет того, что параметры не заталкиваются в стек по десять
> раз тогда, когда это не нужно, тоже может оказаться быстрее.
> Так что не все так однозначно.

Я имел в виду скорее некоторую статистику, наблюдаемую лично, чем corner
cases, которые можно найти _всегда_.
--
Anton Petrusevich

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> Aleksey Cheusov wrote:
>
> > Forth-е, например,
> > за счет того, что параметры не заталкиваются в стек по десять
> > раз тогда, когда это не нужно, тоже может оказаться быстрее.
> > Так что не все так однозначно.
>
> Я имел в виду скорее некоторую статистику, наблюдаемую лично, чем corner
> cases, которые можно найти _всегда_.

А где ты взял статистику, если нет ни одного проекта,
реализующего одно и то же с одинаковыми алгоритмами
людьми одинаковой квалификации
на разных языках программирования?

--
Best regards, Aleksey Cheusov.

[Anton Petrusevich]

Aleksey Cheusov wrote:

> А где ты взял статистику, если нет ни одного проекта,
> реализующего одно и то же с одинаковыми алгоритмами
> людьми одинаковой квалификации
> на разных языках программирования?

Почему нет? А мои собственные? :)))) Бывало переписывал свои проекты с Си на
С++ и наоборот.
--
Anton Petrusevich

[Anton Petrusevich]

Aleksey Cheusov wrote:

>> О! И что взамен?
> Hе поверишь. char *.
> МHЕ хватает. А std::string я использую только там, где мне нужна скорость.

Гмнде. char*... Сложные, говоришь, структуры данных, 155 тыщ строк кода... Я
даже на Си свои собственные строчки пользую вместо char*, и это очень
помогает поменьше задумываться не промазал ли я где с указателем/индексом
размером выделенного массива. Даже просто хранить строчки как ascii-z
нельзя -- мне по сети могут прислать тот самый "z".

> :))) Имелся ввиду код. написанный на С для СЛОЖHЫХ структур данных.

Hу таки что такое "СЛОЖHЫЕ" структуры данных как не комбинация того, что я
перечислял? Hу хочешь запутаться в структурах данных на С++ -- не проблема.
Делаем хеш(дерево) где ключ строка, значение -- хеш, в котором ключ строка,
значение целое. И как только мы затайпдефим все понадобившиеся типы,
создадим объекты, попытаемся написать функции проверки существования
элементов в этих структурах, так оно сразу как-то так некрасиво выглядеть
начинает, что код ну ни чуть не красивее сишного становится.

> А если ты о внешних библиотеках, то мне как раз они не нужны.
> Практически все, что нужно, уже написано. А то, что есть open source
> для этого дела - фе-е-е-е...

Hу, судя по тому, что строчки ты предпочитаешь использовать как char*, думаю
тебе не так уж много от С++ нужно на самом деле....
--
Anton Petrusevich

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> Aleksey Cheusov wrote:
>
> >> О! И что взамен?
> > Hе поверишь. char *.
> > МHЕ хватает. А std::string я использую только там, где мне нужна скорость.
>
> Гмнде. char*... Сложные, говоришь, структуры данных, 155 тыщ строк кода... Я
> даже на Си свои собственные строчки пользую вместо char*, и это очень
> помогает поменьше задумываться не промазал ли я где с указателем/индексом
> размером выделенного массива. Даже просто хранить строчки как ascii-z
> нельзя -- мне по сети могут прислать тот самый "z".
На самом деле я просто просто редко использую ;)
А контейнеров самопальных у меня само собой хватает.
И для строк само собой их тоже использую.

> > :))) Имелся ввиду код. написанный на С для СЛОЖHЫХ структур данных.
>
> Hу таки что такое "СЛОЖHЫЕ" структуры данных как не комбинация того, что я
> перечислял? Hу хочешь запутаться в структурах данных на С++ -- не проблема.
> Делаем хеш(дерево) где ключ строка, значение -- хеш, в котором ключ строка,
> значение целое. И как только мы затайпдефим все понадобившиеся типы,
> создадим объекты, попытаемся написать функции проверки существования
> элементов в этих структурах, так оно сразу как-то так некрасиво выглядеть
> начинает, что код ну ни чуть не красивее сишного становится.
Не договоримся мы здесь.

> > А если ты о внешних библиотеках, то мне как раз они не нужны.
> > Практически все, что нужно, уже написано. А то, что есть open source
> > для этого дела - фе-е-е-е...
>
> Hу, судя по тому, что строчки ты предпочитаешь использовать как char*, думаю
> тебе не так уж много от С++ нужно на самом деле....
Я С свой проект я бы даже начинать писать это не стал.
<datatype>_create
<datatype>_destroy
<datatype>_<do1>
<datatype>_<do2>
...
<datatype>_<doN>

Маловато будет. И криво.

--
Best regards, Aleksey Cheusov.

[Anton Petrusevich]

Dmitri Vorobiev wrote:

>> Кстати.... Я тут начал разбиратьсяс *ix-программированием.
>> Такой вот вопрос - что заюзать в качестве профайлера?
>
> 1. gcc с ключиком -pg для инструментирования бинарника;
> 2. gprof (man gprof) для цифирок;
> 3. cgprof+graphviz (freshmeat.net) для картинок.

Угу. Только надо понимать что вся статистика сбрасывается только по
завершении программы, для случая многопоточной программы не шибко пригодно.
--
Anton Petrusevich, который пытается понять как заставить 6000 тредов не так
сильно кушать процессор.

[i***@paco.net]

Anton Petrusevich <***@att-ltd.biz> wrote:
> Dmitri Vorobiev wrote:
>
>>> Кстати.... Я тут начал разбиратьсяс *ix-программированием.
>>> Такой вот вопрос - что заюзать в качестве профайлера?
>>
>> 1. gcc с ключиком -pg для инструментирования бинарника;
>> 2. gprof (man gprof) для цифирок;
>> 3. cgprof+graphviz (freshmeat.net) для картинок.
>
> Угу. Только надо понимать что вся статистика сбрасывается только по
> завершении программы, для случая многопоточной программы не шибко пригодно.

А какая разница многопоточная или нет? Или речь идет о "не совсем
профайлинге" а о более тонких вещах (типа время ожидания и число нитей,
висящих на локах и т.д.)? Так я не уверен что профайлеры такое делают. У
sun-a есть такая штука tnfprof, использовал успешно. У HP есть - называется
Visual Threads:

http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,5062,00.html

- только для линукса, использовать не получилось.

> --
> Anton Petrusevich, который пытается понять как заставить 6000 тредов не так
> сильно кушать процессор.

Это правда? А почему так много тредов? И каким именно способом они сьедают
процессор?

--
Igor Khasilev |
PACO Links, igor at paco dot net |

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> Dmitri Vorobiev wrote:
>
> >> Кстати.... Я тут начал разбиратьсяс *ix-программированием.
> >> Такой вот вопрос - что заюзать в качестве профайлера?
> >
> > 1. gcc с ключиком -pg для инструментирования бинарника;
> > 2. gprof (man gprof) для цифирок;
> > 3. cgprof+graphviz (freshmeat.net) для картинок.
>
> Угу. Только надо понимать что вся статистика сбрасывается только по
> завершении программы, для случая многопоточной программы не шибко пригодно.

ПРИГОДНО смотрелся бы только новый скин для valgrind.
Даже для однотредия. У gprof погрешность большая.

--
Best regards, Aleksey Cheusov.

[Dmitri Vorobiev]

Anton Petrusevich wrote:
> Dmitri Vorobiev wrote:
>
>
>>>Кстати.... Я тут начал разбиратьсяс *ix-программированием.
>>>Такой вот вопрос - что заюзать в качестве профайлера?
>>
>>1. gcc с ключиком -pg для инструментирования бинарника;
>>2. gprof (man gprof) для цифирок;
>>3. cgprof+graphviz (freshmeat.net) для картинок.
>
>
> Угу. Только надо понимать что вся статистика сбрасывается только по
> завершении программы, для случая многопоточной программы не шибко пригодно.

Таки и действительно: есть ли инструменты, которые бы позволили сделать
post mortem попоточный анализ того, что в программе происходило, кто
кого звал, сколько раз, и сколько времени заняло то, чтобы этот кто-то
пришёл и разобрался?

Было бы здорово, если бы это было возможно.

ДВ

[Anton Petrusevich]

***@paco.net wrote:

>> --
>> Anton Petrusevich, который пытается понять как заставить 6000 тредов не
>> так сильно кушать процессор.
>
> Это правда? А почему так много тредов? И каким именно способом они сьедают
> процессор?

Правда. Тредов много потому что модель такая, клиенту по треду. А каким
образом съедают -- никак не могу понять. Просто засада какая-то. Очевидно,
что большинство должно тихо-мирно висеть на сетевом вводе-выводе, только
изредка делая полезную работу, а тут что-то они взбесились и не могу понять
от чего. Как-то странно изменились внешние условия.
--
Anton Petrusevich

[warlock]

Anton Petrusevich wrote:

> ***@paco.net wrote:
>
>>> --
>>> Anton Petrusevich, который пытается понять как заставить 6000 тредов не
>>> так сильно кушать процессор.
>>
>> Это правда? А почему так много тредов? И каким именно способом они
>> сьедают процессор?
>
> Правда. Тредов много потому что модель такая, клиенту по треду. А каким
> образом съедают -- никак не могу понять. Просто засада какая-то. Очевидно,
> что большинство должно тихо-мирно висеть на сетевом вводе-выводе, только
> изредка делая полезную работу, а тут что-то они взбесились и не могу
> понять от чего. Как-то странно изменились внешние условия.
Изредка слышится упоминание о проблеме 10к для сокетов. Когда число открытых
сокетов приближается к такой отметке - любая ооперационка начинает
подмыкать. К сожалениею деталей не знаю

С уважением
--
warlock

[i***@paco.net]

Anton Petrusevich <***@att-ltd.biz> wrote:
> ***@paco.net wrote:
>
>>> --
>>> Anton Petrusevich, который пытается понять как заставить 6000 тредов не
>>> так сильно кушать процессор.
>>
>> Это правда? А почему так много тредов? И каким именно способом они сьедают
>> процессор?
>
> Правда. Тредов много потому что модель такая, клиенту по треду. А каким

Корень проблемы может быть именно в выборе модели. На самом деле достаточно
сильно зависит от ОС и libpthread.

> образом съедают -- никак не могу понять. Просто засада какая-то. Очевидно,
> что большинство должно тихо-мирно висеть на сетевом вводе-выводе, только
> изредка делая полезную работу, а тут что-то они взбесились и не могу понять
> от чего. Как-то странно изменились внешние условия.

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

Если-бы у меня возникла такая проблема я-бы просто стал смотреть по top или
prstat что именно жрет каждая нить (sys cpu, число syscall/sec, pi/po, общее
число переключений контекста/сек). Что-нибудь необычное вылезет и даст
зацепку.


--
Igor Khasilev |
PACO Links, igor at paco dot net |

[Dennis Melentyev]

Anton Petrusevich wrote:

> ***@paco.net wrote:
>
>
>>>--
>>>Anton Petrusevich, который пытается понять как заставить 6000 тредов не
>>>так сильно кушать процессор.
>>
>>Это правда? А почему так много тредов? И каким именно способом они сьедают
>>процессор?
>
>
> Правда. Тредов много потому что модель такая, клиенту по треду. А каким
> образом съедают -- никак не могу понять. Просто засада какая-то. Очевидно,
> что большинство должно тихо-мирно висеть на сетевом вводе-выводе, только
> изредка делая полезную работу, а тут что-то они взбесились и не могу понять
> от чего. Как-то странно изменились внешние условия.

То, куда смотрел бы я:
1. 6000 * 1Mb = 6Gb одного только стека...
2. 6000 сокетов надо чем-то поллить. У селекта есть свои "прелести" (по
кр. мере на солярке).
3. Банальный while(1){} с закомментареным sleep();
4. "Бутылочное горлышко" обработчика бизнес логики/межтредовой
функциональности (постоянно в работе и никогда не спит). Особенно, если
клиенты устают и пачками отваливают по тайм-аутам...

--
Dennis Melentyev
SW Developer @ KSF, Kiev, Ukraine
www.ksfltd.com
UIN: 83986781
JID: ***@jabber.kiev.ua

[Alexander Krotov]

Anton Petrusevich <***@att-ltd.biz> wrote:
AP> Правда. Тредов много потому что модель такая, клиенту по треду. А каким
AP> образом съедают -- никак не могу понять. Просто засада какая-то. Очевидно,
AP> что большинство должно тихо-мирно висеть на сетевом вводе-выводе, только
AP> изредка делая полезную работу, а тут что-то они взбесились и не могу понять
AP> от чего. Как-то странно изменились внешние условия.

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

-ank

[Ilya Dikarev]

john gladkih <***@kak-sam.to> wrote:
>>>> паскаля и С я довольно часто "хватался" за голову глядя на то, что
>> jg>нагенерилось
>>>> из С, случаев-же такого с паскалем я просто не помню.
>>>>
>>
>> jg>вспомни Delphi и как он делал раскручивал циклы - не в том направлении
>> jg>как
>> jg>было записано в операторе цикла ;)
>> Hу и? Тебе это жить мешает?

jg>мне? нет. я его не использую, слава Богу. но рекурентные вычисления у него
jg>шли лесом... в сад, короче...
Когда я на нем писал много, то использовал рекурсию вовсю. Глюков не
наблюдалось.

ЗЫ
А то, что он может цикл в другую сторону раскрутить, так это он
делает иногда, когда так МОЖHО сделать.

--
XMMS is in /*Silence*/

Hаизусть команду make
Знают Шапка и Mandrake

[Ilya Dikarev]

Andrey V. Malyshev <***@ksc.krasn.ru> wrote:

AM>>>> Hу вот например Intel с тобой несогласен.
JM>>> Hасколько я знаю они позиционируют свой компилятор как "оптимальный
JM>>> для Intel процессоров". Hу возможно еще пытаются приписать себе полное
JM>>> соответствие стандарту. И первое и второе, по результатам, спорно.
ID>> Угу. Как-то пробовал пересобрать что-то с помощью icc. Так он накидал
ID>> кучу ошибок и вывалился... вот так он "поддерживает" стандарты.

AVM>А ты уверен, что то, на чем он спотыкался, было стандартом, а не
AVM>gcc-расширениями ? :)
gcc-расширения?
Расскажи подробней, плиз.

(Hасчет того, что стандартам соответствовал - на 90% уверен).

AVM>Что касается оптимальности... не скажу про все задачи, но те числогрызки
AVM>(массивы, циклы и FP-действия в большом количестве на чистом с), которые я
AVM>пробовал, после сборки интелом с ключами макс. оптимизации работали в
AVM>1.2-1.3 раз резвее, чем gcc... доходило и до полутора. Hа gcc, естественно,
AVM>тоже включал максимум оптимизации.
Возможно это потому, что у тебя был процессор от Intel.
Hа AMD, например, это было бы не так заметно.

--
XMMS is in /*Silence*/

Hаизусть команду make
Знают Шапка и Mandrake

[Andrey V. Malyshev]

Hello, Ilya!
You wrote to "Andrey V. Malyshev" on Mon, 24 Nov 2003 02:46:45 +0300:

ID>>> Угу. Как-то пробовал пересобрать что-то с помощью icc. Так он накидал
ID>>> кучу ошибок и вывалился... вот так он "поддерживает" стандарты.
AVM>> А ты уверен, что то, на чем он спотыкался, было стандартом, а не
AVM>> gcc-расширениями ? :)
ID> gcc-расширения?
ID> Расскажи подробней, плиз.

Насчет частичной поддержки GNU- (gcc) - C/С++ - language
extentions написано в анонсе и документации к интеловому
компилятору.

==================
http://www.intel.com/software/products/compilers/clin/clinux.htm:
==================

Substantial GNU C/C++ compatibility features:
The Intel C++ Compiler 7.1 for Linux is substantially source and object
code compatible with GNU C. Version 7.1 of the compiler has added
more gcc extensions support, that ease the porting of applications with
the Intel compiler.

==================
ftp://download.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility702.pdf:
==================

The Intel C++ 7.0 compiler supports the ANSI C and C++ standards and has
greatly improved support for the GNU C language extensions. As a result, we
are able to build the Linux kernel with fewer work-arounds for both the
IA-32 and Itanium processor architectures compared to earlier releases of
the Intel Compilers.
==================
The Intel C++ compiler supports the ANSI C and C++ standards. In addition,
some of the GNU C language extensions are supported. The extensions are
documented in the gcc manual, available at http://gcc.gnu.org. Table 1 shows
the supported extensions for the Intel C++ Compiler 5.0, 6.0 and 7.0
versions, and highlights improvements in source compatibility. Not all C
extensions are supported when compiling C++ source files.
==================
The gcc C++ language extensions are documented in the gcc manual. Currently,
the following are known GNU C++ source language compatibility limitations:
- Minimum and maximum operators
- Declarations and definitions in one header
- Where's the template?
- Extracting the function pointer from a bound pointer to member function
- C++-Specific Variable, Function, and Type Attributes
==================
Several of the GNU gcc C language header files, part of the GNU C library
glibc, use gcc C language extensions that are not currently supported by the
Intel C++ compiler.
Modified versions of these headers are redistributed in the substitute
headers package installed with the Intel C++ Compiler 7.0 for Linux.
==================

И так далее. Последний документ весьма подробно жует тему совместимости и
проблемы сборки линуксового кода, вплоть до инструкций по сборке линуксового
ядра и таблички с перечислением этих extensions и версий icc, в которых они
поддерживаются/не поддерживаются.

А про сами расширения - http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html,
и
http://gcc.gnu.org/onlinedocs/gcc/C---Extensions.html#C++%20Extensions,
например.

AVM>> Что касается оптимальности... не скажу про все задачи, но те
AVM>> числогрызки (массивы, циклы и FP-действия в большом количестве на
AVM>> чистом с), которые я пробовал, после сборки интелом с ключами макс.
AVM>> оптимизации работали в 1.2-1.3 раз резвее, чем gcc... доходило и до
AVM>> полутора. Hа gcc, естественно, тоже включал максимум оптимизации.
ID> Возможно это потому, что у тебя был процессор от Intel.
ID> Hа AMD, например, это было бы не так заметно.

Да, процессор был Pentium III (Coppermine).

--
With best regards, Andrey V. Malyshev. E-mail: ***@ksc.krasn.ru


Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

[Anton Petrusevich]

***@paco.net wrote:

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

Это всё мне в голову тоже приходило.

> Если-бы у меня возникла такая проблема я-бы просто стал смотреть по top
> или prstat что именно жрет каждая нить (sys cpu, число syscall/sec, pi/po,
> общее число переключений контекста/сек). Что-нибудь необычное вылезет и
> даст зацепку.

А ничего необычного, юзерспейс всё сжирает. Hа числе процессов несколько тыщ
top ведёт себя плохо, на рх9 он группирует все нитки в один процесс (т.е.
теперь он ведёт себя хорошо, но бесполезно). Щас буду лог сетевого траффика
смотреть.
--
Anton Petrusevich

[Andrey Melnikov]

Hello Anton!

25 Nov 03 20:16, Anton Petrusevich wrote to All:

[skipp]

>> Если-бы у меня возникла такая проблема я-бы просто стал смотреть по top
>> или prstat что именно жрет каждая нить (sys cpu, число syscall/sec,
>> pi/po, общее число переключений контекста/сек). Что-нибудь необычное
>> вылезет и даст зацепку.

AP> А ничего необычного, юзерспейс всё сжирает. Hа числе процессов несколько
AP> тыщ top ведёт себя плохо, на рх9 он группирует все нитки в один процесс
AP> (т.е. теперь он ведёт себя хорошо, но бесполезно).
Hажми H в top - будет тебе счастье.
Hу или ps axml тоже пользительно, в WCHAN показывает, в каком сисколе оно
сидит.

Andrey aka TEMHOTA-RIPN

[Anton Petrusevich]

Andrey Melnikov wrote:

> Hажми H в top - будет тебе счастье.
> Hу или ps axml тоже пользительно, в WCHAN показывает, в каком сисколе
> оно сидит.

Да ни в каком, юзерспейс потреблял ~95% cpu, ничего в топе не увидишь в этом
случае. Всё, вопрос снят, после многочасового втыкания в код.
--
Anton Petrusevich

[Anton Petrusevich]

Dennis Melentyev wrote:

> То, куда смотрел бы я:
> 1. 6000 * 1Mb = 6Gb одного только стека...

64kb на стек, при создании треда в аттрибутах указывается явно.

> 2. 6000 сокетов надо чем-то поллить. У селекта есть свои "прелести" (по
> кр. мере на солярке).

каждый тред делает полл на свой сокет.

> 3. Банальный while(1){} с закомментареным sleep();

хм. аналоги такй фигни и ищу. просто это похоже как-то управляется шаблоном
сетевого траффика.

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

это не должно давать LoadAvg в несколько сот...
--
Anton Petrusevich

[Dennis Melentyev]

Anton Petrusevich wrote:

>>3. Банальный while(1){} с закомментареным sleep();
> хм. аналоги такй фигни и ищу. просто это похоже как-то управляется шаблоном
> сетевого траффика.
Может при возникновении/обработке ошибок сокетов (етс) в том же цикле
идет break/continue и опять по кругу. Проходили 8-[~~~.

Меня спасла отладочная печать и не очень долгие зимние вечера за
изучением этих простыней: слишком часто втречался некий текст :)

--
Dennis Melentyev
SW Developer @ KSF, Kiev, Ukraine
www.ksfltd.com
UIN: 83986781
JID: ***@jabber.kiev.ua

[Alexander Timoshenko]

Dennis Melentyev <***@ksf.kiev.ua> wrote:
> Anton Petrusevich wrote:
>
>>>3. Банальный while(1){} с закомментареным sleep();
>> хм. аналоги такй фигни и ищу. просто это похоже как-то управляется шаблоном
>> сетевого траффика.
> Может при возникновении/обработке ошибок сокетов (етс) в том же цикле
> идет break/continue и опять по кругу. Проходили 8-[~~~.
>
> Меня спасла отладочная печать и не очень долгие зимние вечера за
> изучением этих простыней: слишком часто втречался некий текст :)

Да, техника "just printf(3) it" иногда поэффективнее gdb и
профайлера.

--
gonzo

[i***@paco.net]

Dennis Melentyev <***@ksf.kiev.ua> wrote:
> Anton Petrusevich wrote:
>
>>>3. Банальный while(1){} с закомментареным sleep();
>> хм. аналоги такй фигни и ищу. просто это похоже как-то управляется шаблоном
>> сетевого траффика.
> Может при возникновении/обработке ошибок сокетов (етс) в том же цикле
> идет break/continue и опять по кругу. Проходили 8-[~~~.
>
> Меня спасла отладочная печать и не очень долгие зимние вечера за
> изучением этих простыней: слишком часто втречался некий текст :)

Еще strace может помочь.

>

--
Igor Khasilev |
PACO Links, igor at paco dot net |

[Valentin Nechayev]

>>> ***@paco.net wrote:

>> Меня спасла отладочная печать и не очень долгие зимние вечера за
>> изучением этих простыней: слишком часто втречался некий текст :)
> Еще strace может помочь.
Для linuxthreads - возможно. А на фрёвых libc_r/libkse/libthr, например,
определить по нему моменты переключения веток - задача близкая к фантастике.


-netch-

[i***@paco.net]

Valentin Nechayev <***@segfault.kiev.ua> wrote:
>
>>>> ***@paco.net wrote:
>
>>> Меня спасла отладочная печать и не очень долгие зимние вечера за
>>> изучением этих простыней: слишком часто втречался некий текст :)
>> Еще strace может помочь.
> Для linuxthreads - возможно. А на фрёвых libc_r/libkse/libthr, например,
> определить по нему моменты переключения веток - задача близкая к фантастике.

Имелось ввиду - если неправильно в глухом цикле обрабатывается какой-нибудь
вызов (poll/read/write) то это будет хорошо видно с помощью strace.

>
>
> -netch-

--
Igor Khasilev |
PACO Links, igor at paco dot net |

[Eugene B. Berdnikov]

Valentin Nechayev <***@segfault.kiev.ua> wrote:
>>>> ***@paco.net wrote:
VN>
>>> Меня спасла отладочная печать и не очень долгие зимние вечера за
>>> изучением этих простыней: слишком часто втречался некий текст :)
>> Еще strace может помочь.
VN> Для linuxthreads - возможно. А на фрёвых libc_r/libkse/libthr, например,
VN> определить по нему моменты переключения веток - задача близкая к фантастике.

Для linuxthreads - невозможно, потому что в линуксе ptrace_attach()
к нитке не цепляется. Поэтому strace/ltrace/gdb идут лесом.
--
Eugene Berdnikov

[Anton Petrusevich]

Alexander Krotov wrote:

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

Да не, тут похоже мой юзерспейс-код виноват. Только не могу понять что
вызывает такое поведение. Hикакие профайлеры не помогут... (если вернуться
к начальной теме)
--
Anton Petrusevich

[Anton Petrusevich]

Dennis Melentyev wrote:

> Может при возникновении/обработке ошибок сокетов (етс) в том же цикле
> идет break/continue и опять по кругу. Проходили 8-[~~~.

может. но даже это почему-то не могу найти.

> Меня спасла отладочная печать и не очень долгие зимние вечера за
> изучением этих простыней: слишком часто втречался некий текст :)

да вопщем-то метод не нов :) в многопоточной программе по другому никак.
--
Anton Petrusevich

[Anton Petrusevich]

***@paco.net wrote:

>> Меня спасла отладочная печать и не очень долгие зимние вечера за
>> изучением этих простыней: слишком часто втречался некий текст :)
> Еще strace может помочь.

Да не. Как я и подозревал, проблема была чисто в моём коде. Когда писалась
замена STL-строчек я не подразумевал, что они могут быть большими, и не
долго думая написал "грязный" код поиска подстроки в строке:
for( ptr = c_arr + pos ; pos <= length - sl ; ptr++ , pos++ )
if(!memcmp( ptr , s , sl )) return pos;
Казалось бы, мегагерцев много, всё настоько быстрое, что заботиться о
качестве кода уже не имеет смысла, ан нет. Масштабируемость никакими
мегагерцами не отменишь. Простой хак:
fsym = *s;
for( ptr = c_arr + pos ; pos <= length - sl ; ptr++ , pos++ )
if( fsym == *ptr )
if(!memcmp( ptr , s , sl )) return pos;
И снова процессор успевает работать. Казалось бы, профайлер вполне мог бы
помочь, указать какой участок кода отнимает время, но не в случае
многопоточной программы. К тому же, время для одного потока пришлось бы
умножить на 6000, да и то, результат мог бы оказаться всё равно
недостаточно похожим, бо 6000 тредов кеш процессора разрушают сильнее, чем
один, а это профайлер уже вряд ли может учесть.
--
Anton Petrusevich, искавший баг в логике, но не на том уровне...

[Aleksey Cheusov]

Anton Petrusevich <***@att-ltd.biz> writes:

> fsym = *s;
> for( ptr = c_arr + pos ; pos <= length - sl ; ptr++ , pos++ )
> if( fsym == *ptr )
> if(!memcmp( ptr , s , sl )) return pos;

Если ptr действительно длинная, попробуй алгоритм Боера-Мура
или какие-нибудь его адаптации.
Возможно получишь ускорение.

--
Best regards, Aleksey Cheusov.