Здравствуйте, FR, Вы писали:
PD>>Пусть себе пользуются и цикл выше оптимизируют. Пока я не увижу конкретного рецепта, как я (именно я) могу ускорить пусть не в 10, а хотя бы в 2 раза — все это может быть только любопытным фактом. А вот если дашь мне ссылку на то, как это сделать реально в моей программе — я тебе тройки буду ставить ежедневно до конца года
FR>А представь завтра выходит такой компилятор и все твои программы мгновенно становятся некачественными
Вообще-то плохо представляю, потому что не понимаю, что он там такое в коде может сделать ? Перенести в compile-time вычисления, которые туда можно вынести — это детские игры. Развернуть циклы с переменной границей — это несерьезно. Машинный код , полученный от С++, близок по качеству коду, написанному на асме хорошим программистом, а уж на асме никаких суперкомпиляторов нет и не предвидится
Понимаешь, нечего тут супероптимизировать. Разве что алгоритм, но это другая песня. При данном алгоритме С++ реализация хороша.
PD>>Заказчик только меня не поймет.
FR>Зато благодарные потомки тебя не забудут
PD>>И пусть целят. Пока достаточно задействовать 10% тактовой частоты — пусть резвятся. Когда 100% потребуется задействовать — тогда посмотрим.
FR>Не ты не понял под новыми языками я имел в виду действительно новые, а не шарп с явой и питоном. FR>Это гуглевский Go или Ржавчина
или D (хоть и не совсем новый) FR>Они и 99% вполне могут задействовать.
Вот это серьезно. В принципе, я вовсе не адепт именно С++. Язык оставляет желать лучшего. Вот С я действительно люблю — в нем (в рамках того, что в нем есть, если не пытаться в него что-то добавить) все сделано изумительно, ни убавить, ни прибавить. А С++ — монстр, и не очень логичен, и неудачные идеи содержит (множественное наследование хотя бы). Так что если появится язык, который лучше С++ и реально будет использоваться — лично я не против перейти. Я переходил с Алгола на Фортран, с Фортрана на Паскаль, с Паскаля на С++, почему бы на старости лет еще на какой-нибудь язык не перейти ? Но мне для этого нужно, чтобы он был реально используемым, а не маргинальным направлением. Если посмотришь на список языков выше — я всегда переходил на тот язык, который был "в струе" на тот момент.
Ну а еще есть требования заказчика
PD>>Чудес же не может быть. C++ — не совсем точно и не совсем верно, но можно назвать языком с нулевым оверхедом. В нем лишнее не делается, а качество кода отличается от идеального только тем, что оптимизатор все же до идеала довести не может, немного хуже. В новых языках есть оверхед — делается то, что можно не делать. JIT- компиляция, вские проверки и т.д. На это время тратится. И это неустранимо. Лучше С++ в этом плане может быть только язык, который так же, как он , дает мне полное управление, но лучше его по качеству. Тут я согласен — синтаксис и семантика С++ отнюдь не идеал.
FR>Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.
Вообще говоря — дай-то бог.
Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то плохо представляю, потому что не понимаю, что он там такое в коде может сделать ? Перенести в compile-time вычисления, которые туда можно вынести — это детские игры. Развернуть циклы с переменной границей — это несерьезно. Машинный код , полученный от С++, близок по качеству коду, написанному на асме хорошим программистом, а уж на асме никаких суперкомпиляторов нет и не предвидится
Там язык пофиг, можно и для асма http://ru.wikipedia.org/wiki/Суперкомпиляция
PD>Понимаешь, нечего тут супероптимизировать. Разве что алгоритм, но это другая песня. При данном алгоритме С++ реализация хороша.
Тык он и оптимизирует именно алгоритм под конкретные данные или группу конкретных данных.
FR>>Не ты не понял под новыми языками я имел в виду действительно новые, а не шарп с явой и питоном. FR>>Это гуглевский Go или Ржавчина
или D (хоть и не совсем новый) FR>>Они и 99% вполне могут задействовать.
PD>Вот это серьезно. В принципе, я вовсе не адепт именно С++. Язык оставляет желать лучшего. Вот С я действительно люблю — в нем (в рамках того, что в нем есть, если не пытаться в него что-то добавить) все сделано изумительно, ни убавить, ни прибавить. А С++ — монстр, и не очень логичен, и неудачные идеи содержит (множественное наследование хотя бы). Так что если появится язык, который лучше С++ и реально будет использоваться — лично я не против перейти. Я переходил с Алгола на Фортран, с Фортрана на Паскаль, с Паскаля на С++, почему бы на старости лет еще на какой-нибудь язык не перейти ? Но мне для этого нужно, чтобы он был реально используемым, а не маргинальным направлением. Если посмотришь на список языков выше — я всегда переходил на тот язык, который был "в струе" на тот момент.
Это да, но все-таки ты уже пропустил яву/шарп
FR>>Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.
PD>Вообще говоря — дай-то бог. PD>Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то плохо представляю, потому что не понимаю, что он там такое в коде может сделать ? Перенести в compile-time вычисления, которые туда можно вынести — это детские игры.
Подумаешь, перформанс может на порядки вырасти, мелочовочка
PD>Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.
Ладно, хватит о ней. Пусть из пеленок выйдет
PD>>Понимаешь, нечего тут супероптимизировать. Разве что алгоритм, но это другая песня. При данном алгоритме С++ реализация хороша.
FR>Тык он и оптимизирует именно алгоритм под конкретные данные или группу конкретных данных.
Ох, плохо я что-то верю.
PD>>Вот это серьезно. В принципе, я вовсе не адепт именно С++. Язык оставляет желать лучшего. Вот С я действительно люблю — в нем (в рамках того, что в нем есть, если не пытаться в него что-то добавить) все сделано изумительно, ни убавить, ни прибавить. А С++ — монстр, и не очень логичен, и неудачные идеи содержит (множественное наследование хотя бы). Так что если появится язык, который лучше С++ и реально будет использоваться — лично я не против перейти. Я переходил с Алгола на Фортран, с Фортрана на Паскаль, с Паскаля на С++, почему бы на старости лет еще на какой-нибудь язык не перейти ? Но мне для этого нужно, чтобы он был реально используемым, а не маргинальным направлением. Если посмотришь на список языков выше — я всегда переходил на тот язык, который был "в струе" на тот момент.
FR>Это да, но все-таки ты уже пропустил яву/шарп
Почему ? Я писал на Яве, писал на шарпе (без linq), мне за это платили. Конечно, я в них лишь дилетань, не более.
FR>>>Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.
PD>>Вообще говоря — дай-то бог. PD>>Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.
FR>
FR>Ладно давай закруглятся
With best regards
Pavel Dvorkin
Re[13]: Помогает ли Linq сделать код понятнее или быстрее?
R>>>>>LINQ Sum: 915 ms R>>>>>обычный цикл: 134 ms R>>>>>C++ : 61 ms
M>>>>Как всегда, приводятся какие-то непонятные примеры и выдаются за быстродействие Понятно же, что никому даром не нужно ни такое суммирование, ни такое решение.
R>>>в качестве оценки эффективности реализации Sum на простых запросах приведенный код (даже несмотря на неточность в выводе результатов) вполне адекватен.
M>>Он ничем абсолютно не адекватен.
R>то есть с логикой совсем плохо ;( R>тезис: элементарные операции типа Sum в Linq'e реализованы неэффективно по сравнению с обычном циклом R>доказательство: две элементарных программы, версия с Linq работает раз в 5 медленнее.
R>ну и где неадекватность?
В синтетичности теста
M>>Кажется, тут умные люди, и все понимают, что при работе с миллионами и десятками миллионов элементов не будет использоваться ни один ни другой подход. Когда разница между O(n) и O(n*n) на наборе данных различается в 10ms (а ну-ка, проверьте кто-нить код из примера на 1000 даблов), то смысла разводить сыр-бор нет вообще.
R>умные люди понимают, что: R>1) задачи с обработкой (и в частности суммированием) миллионов и десятков миллионов не редкость. Особенно если заниматься не примитивом.
И там явно не используются циклы в лоб.
R>2) "обычный" массив на тысячи элементов: один вложенный цикл и вот уже миллионы-десятки миллионов итераций.
Массив на тысячу элементов — это не массив на миллион.
R>3) да, нынче во многих случаях (на ширпотребовско-даунских задачах) с нынешними компами на производительность можно забить — хорошая новость для программистов вида Formoshlep Vulgaris
Не только для них.
R>Беда в том, что программист, привыкший писать бездумно (хуже того, неспособный думать), не напишет нормально там, где это по-настоящему нужно. Хуже того, даже простую задачу по-настоящему "талантливый" программист может превратить в неподьемную для компа. Конкретный пример из недавнего: надо некоторое количество строчек (C++) длиной в несколько десятков символов каждая, слить в одну. Юное дарование пишет что-то вроде: strcat(Buffer, nextString); в цикле. Не царское это дело миллисекунды считать . У него на тестовых примерах с десятками строк все работает прекрасно. Угадайте сколько этот чудо-код стал выполняться в реальной жизни когда кол-во строк перевалило за 10,000 ?? И ведь задача-то элементарная, и количество элементов опять же тысячи, а не десятки миллионов. Короче, человеческая дурь победит любые гигагерцы. что регулярно и происходит.
А вот ставить задачи надо правильно. Меня поражает это «вдруг» в рассуждениях. «Вдруг» количество строчек перевалило за 10 000. «Вдруг» количество запросов стало большим. «Вдруг» массивы стали по миллиону элементов каждый. 99.9999999% таких высосанных из пальца проблем устраняются на этапе проектирования и ТЗ.
M>> Узкое место в программе наверняка окажется совсем не там.
R>узкое место в программе в 99% случаев находится по ту сторону монитора . собственно, это я и пытаюсь сказать.
Узкое место в программе чаще всего находится не там, где думает программист. Профайлер спасет отца.
Здравствуйте, gandjustas, Вы писали:
K>>Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?
G>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.
А у меня вышло 160 и 290 мс
Re[13]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
K>>>Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?
G>>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.
I>А у меня вышло 160 и 290 мс
Я в цикле сделал i<array.Length
Re[14]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, gandjustas, Вы писали:
G>>>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.
I>>А у меня вышло 160 и 290 мс
G>Я в цикле сделал i<array.Length
У меня тож самое. Интересно, почему такая разница с Sum. Что у тебя за проц-фреймворк ? У меня 4й фреймворк, Core 2 Quad Q9300 2.5 гц
Re[15]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.
I>>>А у меня вышло 160 и 290 мс
G>>Я в цикле сделал i<array.Length
I>У меня тож самое. Интересно, почему такая разница с Sum. Что у тебя за проц-фреймворк ? У меня 4й фреймворк, Core 2 Quad Q9300 2.5 гц
4 фреймворк, Core 2 Duo T5550 1,8 ГГц
Re[16]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, gandjustas, Вы писали:
G>>>Я в цикле сделал i<array.Length
I>>У меня тож самое. Интересно, почему такая разница с Sum. Что у тебя за проц-фреймворк ? У меня 4й фреймворк, Core 2 Quad Q9300 2.5 гц
G>4 фреймворк, Core 2 Duo T5550 1,8 ГГц
У тебя ноут что ли ? Странные результаты, с массивом время почти одинаковое, а с Sum отличие которое должно следовать из разницы по частоте
Re[17]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Я в цикле сделал i<array.Length
I>>>У меня тож самое. Интересно, почему такая разница с Sum. Что у тебя за проц-фреймворк ? У меня 4й фреймворк, Core 2 Quad Q9300 2.5 гц
G>>4 фреймворк, Core 2 Duo T5550 1,8 ГГц
I>У тебя ноут что ли ?
Ага
I>Странные результаты, с массивом время почти одинаковое, а с Sum отличие которое должно следовать из разницы по частоте
Думаю нормально, в процессорах много оптимизировано для линейных циклов.
Re[18]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
G>>>>>Есть, как минимум в не-windows. Вообще это дико неудобно использовать будет.
PD>>>>Вполне удобно, поверь.
G>>>На C++ это будет удобно (читай надо писать свой аллокатор)? G>>>На C# это будтет удобно?
PD>>Есть там поддержка mmf или нет ? G>Есть.
G>>>На java это будет удобно? PD>>В яве поддержка mmf есть. G>Но я не это спросил.
G>>>На python это будет удобно? PD>>А это меня не интересует. G>Тогда зачем ты сюда пришел?
G>>>Фактически это будет удобно только на С. G>>>Так что верить тебе у меня нет никаких оснований. PD>>Не хочешь — не верь. Я на Яве такое писал. G>Покажи код.
G>>>>>А как я уже писал в этой теме — время работы программиста гораздо дороже времени работы компьютера. PD>>>>Да, я помню про этот аргумент, обосновывающий халтуру. G>>>Обоснуй сначала что это "халтура". Если заказчик доволен и разработчик получил бабло, то это самая обычная работа. PD>>Сто раз обосновывал, поищи. G>Ты стока буллшита написал на форуме, что я утону в нем пока найду в нем конкретную мысль. G>Моя конкретная мысль: исполнитель доволен, заказчик доволен — значит это была хорошая работа.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, anton_t, Вы писали:
_>Упорядоченный массив — это массив, в котором все элементы расположены по порядку. Очевидно, что для пустого массива это выполняется.
Заметим, что обратное условие также выполняется Так что это таки вопрос соглашения.
M>А вот ставить задачи надо правильно. Меня поражает это «вдруг» в рассуждениях. «Вдруг» количество строчек перевалило за 10 000. «Вдруг» количество запросов стало большим.
Vitas совершенно прав, а ты нет. Я лично ускорял программу, в которой такой же, как ты, перец использовал сортировал списки списков копированием. Несколько лет назад там было 10 списков по десять элементов, а спустя пару лет стало сто по сто (условно, порядок именно такой). И все, приплыли — стоп машина, юзеры рвут и мечут, девелоперы в мыле ищут баги и фиксят.
Такой же как ты, наверное, писал — а что тьам считать милисекунды...
Да здравствует мыло душистое и веревка пушистая.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, anton_t, Вы писали:
_>>Упорядоченный массив — это массив, в котором все элементы расположены по порядку. Очевидно, что для пустого массива это выполняется.
K>Заметим, что обратное условие также выполняется Так что это таки вопрос соглашения.
Неупорядоченный массив — массив, в котором существуют элементы, расположенные не по порядку. Очевидно, что для пустого массива это не выполняется.
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
_>Неупорядоченный массив — массив, в котором существуют элементы, расположенные не по порядку. Очевидно, что для пустого массива это не выполняется.
Математики все еще до нас украли:
Определение 1. Множество M называется упорядоченным, если между его элементами установлено некоторое отношение a < b ("a предшествует b"), обладающее следующими свойствами: 1) между любыми двумя элементами a и b существует одно и только одно из трех соотношений: a = b, a < b, b < a; 2) для любых трех элементов a, b и c из a < b, b < c следует a < c.
Пустое множество считается упорядоченным.
Re[15]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Vamp, Вы писали:
M>>А вот ставить задачи надо правильно. Меня поражает это «вдруг» в рассуждениях. «Вдруг» количество строчек перевалило за 10 000. «Вдруг» количество запросов стало большим. V>Vitas совершенно прав, а ты нет. Я лично ускорял программу, в которой такой же, как ты, перец использовал сортировал списки списков копированием. Несколько лет назад там было 10 списков по десять элементов, а спустя пару лет стало сто по сто (условно, порядок именно такой). И все, приплыли — стоп машина, юзеры рвут и мечут, девелоперы в мыле ищут баги и фиксят. V>Такой же как ты, наверное, писал — а что тьам считать милисекунды...
Ты как будто через очки в сеточку читаешь =)
Если в ТЗ несколько лет назад было написано 10х10, то это проблема писавшего ТЗ, который не подумал, что скоро надо будет 100х100.
Вот когда будут ресурсы неограниченными — тогда и будем предварительно оптимизировать все, что движется.
А пока — одни будут получать премии за то, что выкатили рабочую версию в срок, а другие — за то, что ускорили потом в 10 раз.
Вроде как, выгодно всем
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, anton_t, Вы писали:
_>>Неупорядоченный массив — массив, в котором существуют элементы, расположенные не по порядку. Очевидно, что для пустого массива это не выполняется.
FR>Математики все еще до нас украли:
FR>
FR> Определение 1. Множество M называется упорядоченным, если между его элементами установлено некоторое отношение a < b ("a предшествует b"), обладающее следующими свойствами: 1) между любыми двумя элементами a и b существует одно и только одно из трех соотношений: a = b, a < b, b < a; 2) для любых трех элементов a, b и c из a < b, b < c следует a < c.
FR>Пустое множество считается упорядоченным.
То что ты процитировал — это определение линейно упорядоченного множества. К упорядоченным массивам, о которых речь, это не имеет отношения. Хотя пустое множество линейно упорядоченно по той же причине, что и пустой массив упорядочен — нет ни одного элемента, который противоречит определению.
Re[16]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, midcyber, Вы писали:
M>Если в ТЗ несколько лет назад было написано 10х10, то это проблема писавшего ТЗ, который не подумал, что скоро надо будет 100х100.
Вы издеваетесь? Более менее нормальное ТЗ — жуткая редкость; детальное ТЗ, где описано макс кол-во элементов — еще большая редкость. Обычно такие моменты оставляют на откуп программиста.
А вообще, есть хороший совет — не пессимизировать раньше времени (правда есть и второй — не оптимизировать раньше времени ) И если вместо квадратичной сложности можно получить линейную не прикладывая особых услилий, то лучше ее сразу и получить...
M>А пока — одни будут получать премии за то, что выкатили рабочую версию в срок, а другие — за то, что ускорили потом в 10 раз. M>Вроде как, выгодно всем
Понятно же, что никому даром не нужно ни такое суммирование, ни такое решение.
