Re: Помогает ли Linq сделать код понятнее или быстрее?
От: frogkiller Россия  
Дата: 31.07.10 14:43
Оценка: 1 (1) +4 :))) :)
Здравствуйте, 0K, Вы писали:

0K>По мотивам: http://rsdn.ru/forum/dotnet/3900028.flat.aspx
Автор: Dog
Дата: 30.07.10

0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

Прочитал исходное обсуждение, увидел:

Помня одно предыдущее значение, соедини последовательность с самой собой, смещённой с на один элемент вперёд, и проверь, что во всех парах левое значение меньше или равно правому.

Вспомнил классическое дадена тебе мышь — работай мышью... Долго думал...

Это всё очень красиво. Да-да, красиво, так говорит моё программерское чувство прекрасного. Но оно так же и бесполезно. Более того, оно вредно, потому что насмотрятся нубы на такое и будут делать всегда и везде, не думая ни о скорости, ни о выделении памяти, ни о побочных эффектах. А это печально.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: SpaceConscience  
Дата: 31.07.10 20:53
Оценка: +1 :))) :))) :))
0K>Мой вариант (долго не думал):

0K>
0K>var numbers = new[] {1, 3, 5, 7, 9};
0K>bool isAscending = true;

0K>int temp = numbers[0];

0K>for (int i = 1; i < numbers.Length; i++)
0K>{
0K>    if (temp > numbers[i])
0K>    {
0K>        isAscending = false;
0K>        break;
0K>    }

0K>    temp = numbers[i];
0K>}
0K>


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


var e = true; for (var i = 1; i < xs.Length; i++) if (xs[i-1] > xs[i]) e = false;
var isAscending = e;


Во, вот так к "мирку" уже ближе. Декларативнее. Приобщайся!
Собрался ставить минус? Да сам иди в жопу!

































































.
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 31.07.10 11:32
Оценка: 5 (3) +5
Здравствуйте, 0K, Вы писали:

0K>for (int i = 1; i < numbers.Length; i++)

0K>{
0K> if (temp > numbers[i])
0K> {
0K> isAscending = false;
0K> break;
0K> }

0K> temp = numbers[i];

0K>}
0K>[/c#]

0K>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?


Вот такой:

let rec f = function 
  | a::b::_  when a > b   -> false
  | h::t                  -> f t
  | _                     -> true


А Linq это так, жалкое подобие
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 03.08.10 02:57
Оценка: 3 (1) +4 :)))
Здравствуйте, 0K, Вы писали:

0K>По мотивам: http://rsdn.ru/forum/dotnet/3900028.flat.aspx
Автор: Dog
Дата: 30.07.10


0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


А вообще граждане шарписты поздравляю вас.
Синдром Александреску из C++ успешно до вас добрался, притом во всей своей красе
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 01.08.10 08:04
Оценка: +8
Здравствуйте, gandjustas, Вы писали:

0K>>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?

G>Твой в любом случае хуже всех, так как принимает массив, а не любую последовательность. Твой вариант является наименее общим при том что самый длинный.

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

G>В F# есть потрясающая функция Seq.pairwise, которая список [x1,x2,x3...] превращает в список пар [(x1,x2), (x2,x3)...] делает примерно тоже что в вариантах 2 и 4, только с одним итератором и совершенно не требует эмуляции ленивости с запоминанием.


работает, правда, все в разы медленнее, но кого нынче это волнует...
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: Klapaucius  
Дата: 02.08.10 12:20
Оценка: 10 (7)
Здравствуйте, FR, Вы писали:

let rec f = function 
  | a::b::_  when a > b   -> false
  | h::t                  -> f t
  | _                     -> true


FR>А Linq это так, жалкое подобие


Это плохой код. Хорошая практика — это писать с использованием комбинаторов из стандартной библиотеки. Для ml-подобных языков правильным решением будет, например, такое
Автор:
Дата: 01.08.10
.
xs |> Seq.pairwise |> Seq.forall (fun (a,b) -> a <= b)

Ну и в случае наличия подходящего набора библиотечных функций и на C#, будет так:
xs.Reduce((a, b) => a <= b).And()
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 31.07.10 10:42
Оценка: 1 (1) +2 -3 :)
По мотивам: http://rsdn.ru/forum/dotnet/3900028.flat.aspx
Автор: Dog
Дата: 30.07.10


Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

Варианты ответа:

1.

var s = new[] {1, 3, 3, 7, 9};
var r = s.Aggregate(new {V=int.MinValue, C=0}, (a, val) => a.V < val ? new {V=val, C=a.C+1} : a).C == s.Length;


2.

var ascending = Enumerate()
                .Memoize(1)
                .Let(e => e.Zip(e.Skip(1), (a, b) => a < b))
                .All(x => x);


(это с применением Rx, кстати кто скажет что это такое?)

3.

var isAscending = xs.OrderBy(x => x).SequenceEqual(xs);



4.

var isAscending = xs.Replay(ys => ys.Zip(ys.Skip(1), (x, y) => x <= y), 1).All(x => x);


Мне, как поверхностно знакомому с Linq (самые простые конструкции я использую) понятен только вариант 3 (там сначала сортировка всего массива -- это очень необдуманно, сортировка не нужна в данном случае). Остальное мне нужно сидеть минут 5 и думать что же хотел сказать этот индус.

Мой вариант (долго не думал):

var numbers = new[] {1, 3, 5, 7, 9};
bool isAscending = true;

int temp = numbers[0];

for (int i = 1; i < numbers.Length; i++)
{
    if (temp > numbers[i])
    {
        isAscending = false;
        break;
    }

    temp = numbers[i];
}


Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 04.08.10 07:12
Оценка: 3 (2) +2 :)
Здравствуйте, fmiracle, Вы писали:

F>А может быть стоило бы задуматься о контексте задачи, а потом уже ломать копья про (не)эффективность?


F>Скажем, этот самый третий пример проверки отсортированности (с сортировкой и сравнением) прекрасно подходит для модульных тестов. Там и объемы данных небольшие, и время выполнения несильно критично, и писать их надо очень много (запросто выходит больше по объему чам самого кода), и при этом как раз там проверка что возвращаемая последовательность упорядочена — задача вполне себе часто встречающаяся.


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

Кроме того, я все-равно не понимаю чем линковская сортировка с последующим сравнением нагляднее чем цикл. они ж даже по размеру примерно одинаковые.

Дальше. про LINQ. На мой взгляд есть три случая:

1) некая навороченная конструкция, которая на LINQ'е записывается просто и эффектно,а без линка — длинная простыня кода. Разумеется, здесь линк очень к месту.

2) нечто где LINQ нафиг не нужен, но он смотрится естесственней, например, написать someArray.Sum(x=>x) нагляднее чем простой цикл с суммированием, при этом сложность обоих алгоритмов одинакова, они отличаются только формой записи. здесь снова есть смысл использовать LINQ, хотя... см.ниже

3) там где LINQ нафиг не нужен, не подходит и тулить его просто вредительство. типа как в рассматриваемом примере.
заведомо на ровном месте без всякой выгоды вставлять в программу тормоза — вредительство.

Эх, не поленился я. Проверил линковский SUM.

тупое суммирование массива из 30,000,000 doubles.

LINQ Sum: 915 ms
обычный цикл: 134 ms
C++ : 61 ms

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

        private const int N = 30000000;
        static void Main(string[] args)
        {

            var ba = new double[N];
            for (int i = 0; i < N; i++)
                ba[i] = i*i;

            double sum = 0;
            DateTime t0 = DateTime.Now;
            for (int i = 0; i < N; i++)
                sum += ba[i];
            DateTime t1 = DateTime.Now;
            Console.WriteLine("{0} {1}", sum, t1-t0);

            t0 = DateTime.Now;
            double sum2 = ba.Sum(item => item);
            t1 = DateTime.Now;
            Console.WriteLine("{0} {1}", sum, t1 - t0);
        }
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 01.08.10 12:15
Оценка: +1 :)))
Здравствуйте, gandjustas, Вы писали:

G>Твой в любом случае хуже всех, так как принимает массив, а не любую последовательность.


Для тех, кто не уловил принцип:

bool isOrdered = true;

enumerator.MoveNext();
var temp = enumerator.Current;

while (enumerator.MoveNext())
{
    if (temp > enumerator.Current)
    {
        isOrdered = false;
        break;
    }

    temp = enumerator.Current;
}


Разницы нет последовательность или тип, который нужно листать с помощью вызова функции. Вообще в 99% массивы предпочтительнее -- все равно все хранится в памяти.

G>Твой вариант является наименее общим при том что самый длинный.


Да? А так:

bool o = true; e.MoveNext();
var temp = e.Current;
while (e.MoveNext()){ if (temp > e.Current) { o = false; break; } temp = e.Current; }


Мальчик. Объясняю пока жив: главное понятность кода а не во сколько байт ты его втиснул.
Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 09:26
Оценка: +2 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Mamut, Вы писали:


M>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,


PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?

Это не вылезает за пределы того что он видит на других сайтах.

Есть же давно известное правило.
До 0.1 секунды для пользователя "моментально", до 1 секунды "быстро", до 10 секунд "приемлемо". Причем касается реакции интерфейса, а не времени выполнения работы. Если интерфейс умудряется фибдбэчить каждую секунду, то и минута покажется пользователю приемлемым временем работы.
Re[24]: пояснение о качестве
От: Cadet  
Дата: 04.08.10 10:58
Оценка: +3 -1
Здравствуйте, CreatorCray, Вы писали:

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


Это почему вдруг? Была проблема, посл появления софта проблема исчезла? Софт решает проблему, это хороший софт с точки зрения решаемой задачи.

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

Можно продолжить.

Оценка она всегда многогранная, ты как программист оценишь программу по одним критериям, Шеридан как сисадмин по другим, тетя Маша-бухгалтер по третим, а дядя Вася-гендир — по четвертым.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: IT Россия linq2db.com
Дата: 01.08.10 22:41
Оценка: +3
Здравствуйте, 0K, Вы писали:

IT>>Хотя бы в том, что твой пример без Linq упадёт на пустой последовательности.

0K>А ваш пример на Linq для пустой последовательности выдаст true или false? Значение для пустой последовательности не определено -- это зависит от логики программы. По этому проверку я не включал.

True или False — это поведение. Невключение проверки — это бага. И, кстати, лучше с этим не спорить.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: пояснение о качестве
От: FR  
Дата: 04.08.10 12:16
Оценка: :)))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Извини, но я здесь никаких контраргументов не вижу. Вижу только декларативное заявление.


Тык на то он и функциональщик.
Re[36]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 11:38
Оценка: +3
PD>>>Так и всякой дряни наглотаться можно

M>>Можно конечно Но если эта дрянь удовлетворяет мои потребности, это как бы мои проблемы


PD>Именно так. Не разобравшись с качеством продукта и не выслушав мнения специалистов я создам себе проблемы, которые потом решать будут медики.


Нас на самом деле занесло немного в ту степь (что всегда происходит с аналогиями).

Программа, выполняющая требования заказчика, — это, как минимум, мороженное, которое проходит по медицинским показателям. Технические моменты вроде замены сортировки пузырьком на merge sort соответствуют замене обезжиренного молока в мороженном на полноценные сливки, например

Почему? Потому что заказчик говорит: я хочу, чтобы программа соответствовала требованиям А, Б, В. Если программа им соответствует — прекрасно, и никакие внутренние, технические проблемы программы (вроде сортировки пузырьком) не приведут к проблемам, требующих медиков (она не напишет -1000000 там, где должно стоять +10).


У нас в соседнем офисе ребята работают на крупную западную компанию, что-то там продающую по интернету. Их бухгалтерия сидела на какой-то майкрософтовской фигне и горя не чаяла. Эта система не потеряла ни цента денег за 4 или 5 лет работы.

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

«Ага», сказали программисты и полезли в базу данных.
«$*&^%$#$%^&*()(*&^%$#@!@#$%^&*()_)(*&^%$#W@#$%^&*()_)(*&^%$», сказали программисты, увидев базу данных, которая состояла из таблиц с названиями типа D00089 и полями, названными не менее информативно.
Но ладно, разобрались

В новой системе — все что надо, MVC, OOP, декомпозиция данных, информативные таблицы, триггеры, хранимые процедуры, отчеты на любой вкус... Но два раза система потеряла по десятку тысяч долларов (баг найден и устранен)...

Теперь внимание, вопрос — какая система лучше?

Специалист (сферовакуумный?) скажет, что, безусловно, вторая система. Она и написана грамотно, и отчеты генерятся за 10-45 секунд против 2 часов в прежней системе и т.п.

А бухгалтерия скажет: «идите туда, где солнце не светит», потому что фирма потеряла почти 20 000 баксов, а отчеты нам нужны раз в месяц, можно и подождать 2 часа.

И будет права бухглтерия, а не специалист. Потому что в итоге решает заказчик. А для заказчика единственным критерием качества программы является то, как она обрабатывает его, заказчика, данные.


dmitriid.comGitHubLinkedIn
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: Кэр  
Дата: 04.08.10 01:31
Оценка: 2 (2)
Здравствуйте, 0K, Вы писали:

0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.

Конкретно для этой задачи использовать Linq — не очень ясно зачем надо.

Но как только начинается группировка, фильтрация, получение и слияние более чем одного списка — тот уже без Linq очень грустно.
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: Klapaucius  
Дата: 04.08.10 10:29
Оценка: 2 (2)
Здравствуйте, gandjustas, Вы писали:

double sum2 = ba.Sum(item => item);


G>Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length


Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 02.08.10 07:20
Оценка: 1 (1) +1
0K>По мотивам: http://rsdn.ru/forum/dotnet/3900028.flat.aspx
Автор: Dog
Дата: 30.07.10


0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


0K>Варианты ответа:


[skip]

0K>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?



Поянтность ответов зависит от степени овладевания Linq'ом. Все остальное — домыслы на пустом месте.


dmitriid.comGitHubLinkedIn
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: Privalov  
Дата: 01.08.10 16:37
Оценка: :))
Здравствуйте, FR, Вы писали:

SC>>

SC>>var e = true; for (var i = 1; i < xs.Length; i++) if (xs[i-1] > xs[i]) e = false;
SC>>var isAscending = e;

SC>>


FR>Много недостатков алгоритм даже не квадратичный, "if" вместо оператора "?" мутабельный e нет рекурсии, в общем незачет


А зачем там нужен "?" ? Разве недостаточно

   e = !(xs[i-1] > xs[i]);

Re[22]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 06:03
Оценка: +2
PD>Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.

Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.

В случае массового софта хороший софт — это софт, решающий проблемы целевой аудитории.

Если качество продукта будут оценивать специалисты, мы из войн типа «iPhone — гуано» никогда не выберемся


dmitriid.comGitHubLinkedIn
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: Klapaucius  
Дата: 04.08.10 08:51
Оценка: +2
Здравствуйте, Кэр, Вы писали:

Кэр>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.


А инструкция и будет. Пододите курсор к вызову одной библиотечной функции — всплывает подсказка. Подводите к другой — и тут подсказка. Да и названия функций, если удачно подобраны — уже подсказка. К невнятным манипуляциям в цикле никаких подсказок нет, если только к каждому циклу они не будут написаны самим программистом. Ну и на практике он они написаны не будут.
В том числе и поэтому (но не только) и нужно использовать библиотечные функции, которые делают известные изучившему библиотеку действия, комбинировать их и выражать таким образом явно, что код делает, а не городить рыхлые нагромождения из элементарных действий в циклах, которые по отдельности понятны, но только этих деталей уже не 3, как в примере выше, а десятки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[62]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.10 12:41
Оценка: -1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

>>наверно нужно все бросать и заняться этим?


PD>Проще купить Intel C++.


А если уже используется ICC, как ускорить код без суперкомпиляции ?


PD>Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.


Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.
Re[66]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.10 14:25
Оценка: -1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

I>>Библиотеки являются следствием из языка.


PD>Что значит следствием ?


Это значит, что если функции сделаны, как с++, то стоит ожидать бред вроде stl или boost.

А долгая компиляция, макросы, синтаксис означают, что не стоит ожидать появления библиотек с понятным дизайном.

I>>Если для языка нельзя написать хороший инструмент, например, для генерации кода, то естественно и библиотек требующих генерацию кода, никогда не появится.


PD>Ничего не понял. Вроде как такой инструмент компилятором называется.


Сразу видно, ты про генерацию кода ничего не слышал, потому тебе и мерещится компилятор.

Генерация кода — это автоматизация рутины. Как толькл появился хороший фреймворк то многие задачи на оном можно автоматизировать.

А в С++ все надо делать или копипастом, или руками, или выращиванием шаблонов как в стл или буст.

PD>Что я и делаю. А разве я предлагал его использовать для написания сайтов ? Не предлагал и не предложу. У нас и так задач хватает.


При чем здесь сайты ?
Re[47]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 06.08.10 08:07
Оценка: 3 (1)
Здравствуйте, Mamut, Вы писали:


PD>>Ладно, давай заканчивать.


M>Думаю, можно Все равно, мне кажется, мы друг друга понимаем, но КСВ обязывает


Понимаешь, если уж честно...

Я твой критерий не приму, но понять могу. Сказать, что он ложный на 100%, не скажу. Какая-то доля истины в нем, наверное есть. Кто платит — тот и заказывает музыку.

Меня другое беспокоит. Далее — само собой, без личностей.

Это опасный критерий. Может, в умелых, профессиональных руках он и сработает как следует. Но он открывает широкие ворота для халтурщиков. Он дает им основание делать абы как, лишь бы заказчик рекламацию не выставил. А быстродействие нынешних компьютеров таково, что очень многое и можно сделать абы как, все равно тактовая частота и объем ОП все покроет. Вот пришлось бы им то же на Пентиум-100 делать (а я 100% уверен, что для большинства сайтов с 10 посетителями в день Пентиум-100 и 16 Мб — вполне достаточно, доказательсво простое : работали же лет 10-15 назад) — они бы иначе заговорили.

Вот давай до абсурда доведем. Быстродействие (в том числе и диска, чтоб ему) и память еще раз в 20 увеличились. А задачи остались прежними, потому что они бизнес-сутью определяются, а не тактовой частотой (не все, конечно). Да тут полное раздолье будет — валяй что угодно, любую халтуру делай, все равно заказчик доволен будет. И создастся т.н. "террор среды" (впрочем, почему создастся, он уже есть) — когда много людей делают халтуру, они себя быстро убеждают в том. что они именно как надо делают, а все кто их за халтуру ругает, ничего не понимают и воообще зануды.

Не боишься ?
With best regards
Pavel Dvorkin
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 01.08.10 17:11
Оценка: 1 (1)
Здравствуйте, gandjustas, Вы писали:

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

G>>>
G>>>Скажи по-русски что такое отсортированный массив.

R>>???


G>Чего непонятного. Приведи определение отсортированного массива (последовательности чисел в общем случае)


Вы не знаете что такое отсортированный массив?


G>Как это относится к вопросу?

G>Ты не путай общность "архитекруры" и общность алгоритма. Второе всегда лучше, первое — спорно.

любая задача должна решаться адекватными средствами. Неадекватно отстреливать воробьев из пушек, неадекватно маленькому ребенку, спрашивающему почему небо голубое, рассказывать про рассеяние Рэлея; неадекватно использовать LINQ там, где прекрасно работает простой цикл, а на LINQ'е приходится извращаться и увеличивать сложность алгоритма.

При этом LINQ, безусловно, отличная вещь.


R>>ню-ню. время программиста, который для проверки упорядоченности массива его сортирует, а потом сравнивает (в оригинале такое чудо есть), должно оцениваться по ОТРИЦАТЕЛЬНОЙ ставке .

G>С чего ты взял? Задачу то он выполняет.
G>И такая проверка закончится быстрее, чем будет написан цикл.

извините, но это уже на профнепригодность тянет ;(
Вы вообще в курсе что массивы бывают большие? И что замена алгоритма сложностью O(n) на O(n*n) запросто приводит к тому, что на маленьких тестовых примерах у девелопера все работает нормально, а в реальной жизни, на реальных больших данных у юзера все фатально тормозится и виснет. Причем ладно бы замена хоть как-то упрощала жизнь, а то просто тупое вредительство...


R>>Для иллюстрации достаточно на WinMobile в тамошнем ворде открыть plain text на пару мегабайт -- тоже небось чье-то индусское время очень дорого стоило...

G>Совсем не понял как это связано с проверкой упорядоченности массива.

самым что ни на есть прямым образом -- word на winmobile отличный (и, к сожалению, очень далеко не единственный) пример того, к чему приводит безмозглое программирование без понимания.
Re[17]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 03.08.10 05:37
Оценка: 1 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>На python это будет удобно?


PD>А это меня не интересует.


Зря там очень хорошая поддержка mmf — http://docs.python.org/library/mmap.html
Тем более по скорости питон уже бьет и C++ и яву http://www.rsdn.ru/forum/flame.comp/3902202.flat.aspx#3902202
Автор: Mamut
Дата: 02.08.10
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: The Lex Украина  
Дата: 31.07.10 19:00
Оценка: +1
Здравствуйте, frogkiller, Вы писали:

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


Печальнее всего еще и то, что в 9 случаях из 10 оно "красиво-нечитабельное". Попробуй потом такой код "поддержать"...

ЗЫ: задачи на логику на собеседованиях — зло! шибко "умный" программер придет — точно "умничать" будет.
Голь на выдумку хитра, однако...
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 31.07.10 22:36
Оценка: +1
Здравствуйте, 0K, Вы писали:

0K>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?

Твой в любом случае хуже всех, так как принимает массив, а не любую последовательность. Твой вариант является наименее общим при том что самый длинный.
В F# есть потрясающая функция Seq.pairwise, которая список [x1,x2,x3...] превращает в список пар [(x1,x2), (x2,x3)...] делает примерно тоже что в вариантах 2 и 4, только с одним итератором и совершенно не требует эмуляции ленивости с запоминанием.

Написать аналогичную функцию для C# несложно и при её использовании проверка на упорядоченность последовательности будет короткой, красивой и даже очевидной. При этом можно будет проверять на упорядоченность последовательность чисел, принимаемых по сети\доставаемых из бд, без сохранения всей последовательности в памяти.

Кроме того алгоритмы с Linq можно композировать, например для получения упорядоченных подпоследовательностей.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 01.08.10 08:48
Оценка: +1
Здравствуйте, vitasR, Вы писали:

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


Самый понятный по моему рекурсивный, вот вариант на близком к шарпу D

pure auto f(int Arr[])
{
    if(Arr.length < 2)
        return true;
    
    if(Arr[0] > Arr[1])
        return false;
    
    return f(Arr[1 .. $]);
}


Тут сразу видна суть в императивном же варианте временная переменная ее заслоняет.
Ну и по эффективности из-за оптимизации хвостовой рекурсии этот вариант практически эквивалентен циклу:

    if(Arr.length < 2)
00402017  push        ebx  
00402018  push        esi  
00402019  mov         esi,dword ptr [esp+2Ch] 
0040201D  cmp         esi,2 
00402020  push        edi  
00402021  jae         main@f+21h (402031h) 
        return true;
00402023  pop         edi  
00402024  mov         eax,1 
00402029  pop         esi  
0040202A  pop         ebx  
0040202B  add         esp,20h 
0040202E  ret         8    
    
    if(Arr[0] > Arr[1])
00402031  mov         edx,ecx 
00402033  mov         ebx,dword ptr [edx] 
00402035  mov         eax,esi 
00402037  cmp         ebx,dword ptr [edx+4] 
0040203A  jle         main@f+37h (402047h) 
        return false;
0040203C  pop         edi  
0040203D  xor         eax,eax 
0040203F  pop         esi  
00402040  pop         ebx  
00402041  add         esp,20h 
00402044  ret         8    
    
    return f(Arr[1 .. $]);
00402047  lea         edi,[esi-1] 
0040204A  add         edx,4 
0040204D  mov         ecx,edx 
0040204F  mov         dword ptr [esp+0Ch],edi 
00402053  mov         esi,edi 
00402055  mov         dword ptr [esp+10h],edx 
00402059  cmp         dword ptr [esp+0Ch],2 
0040205E  jb          main@f+13h (402023h) 
00402060  jmp         main@f+21h (402031h)
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: Yarik_L  
Дата: 01.08.10 12:55
Оценка: :)
Здравствуйте, 0K, Вы писали:

0K>Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?

Если взять любой упорядоченный массив, то очевидно что все массивы, получающиеся из исходного вычеркиванием отдельных элементов, также будут упорядоченными. Значит и пустой массив обязан быть таковым
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 01.08.10 14:15
Оценка: +1
Здравствуйте, gandjustas, Вы писали:


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

G>
G>Скажи по-русски что такое отсортированный массив.

???


R>>стремление к общности там где она нафиг не нужна — большая ошибка на самом деле.

G>Обоснуй.

например здесь


R>>работает, правда, все в разы медленнее, но кого нынче это волнует...

G>Конечно, не волнует. Время компьютера дешево, а время программиста дорого.

ню-ню. время программиста, который для проверки упорядоченности массива его сортирует, а потом сравнивает (в оригинале такое чудо есть), должно оцениваться по ОТРИЦАТЕЛЬНОЙ ставке . бо как приходят такие чуды в перьях и в делают любой проект просто не рабочим. Для иллюстрации достаточно на WinMobile в тамошнем ворде открыть plain text на пару мегабайт -- тоже небось чье-то индусское время очень дорого стоило...
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.08.10 16:04
Оценка: :)
Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, gandjustas, Вы писали:


G>>Это ты где такую шутку прочитал?

G>>99% данных обычно программа получает извне.

0K>Ну да, и записывает их в ОЗУ. А раз в ОЗУ, то лучше массив.

С чего ты взял что записывает?
С чего ты взял что массив лучше?
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 10:46
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:


PD>>>И что же тут неэффективного, можно пояснить ? Разумееется, под динамическим массивом понимается не то убожество, которое есть во многих средах, а механизм резервирования и коммитирования памяти, когда изменение размера производится всегда без переаллокации.


G>>Конкретнее, как это сделать не зная заранее длину массива?


PD>Обычно некую верхнюю границу (G) мы знаем. Можно ее на всякий случай в несколько раз увеличить. Резервируем пространство размером G (при этом память не выделяется), а потом коммитируем кусками потребного размера. См. VirtualAlloc.


Ты предлагаешь всю работу с памятью делать через winapi?
Как-то слишком круто.
Re[16]: Помогает ли Linq сделать код понятнее или быстрее?
От: CreatorCray  
Дата: 02.08.10 12:21
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>На C++ это будет удобно (читай надо писать свой аллокатор)?

Да.

G>Фактически это будет удобно только на С.

И С++
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 12:23
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:


G>>На C++ это будет удобно (читай надо писать свой аллокатор)?

CC>Да.
Ты все еще веришь что каждый программист на С++ способен написать аллокатор?

G>>Фактически это будет удобно только на С.

CC>И С++
Не выдавай желаемое за действительное
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: SpaceConscience  
Дата: 02.08.10 22:08
Оценка: +1
В данном случае не помогает из-за недостатка подходящего комбинатора в стандартной комплектации; там вообще слишком мало комбинаторов, и названия не у всех интуитивны.

Декларативно было бы как-то так:

int[] items = { 1, 2, 3, 4, 5 };

bool isAscending = items
    .GetAllPairsOfAdjacentItems()
    .ForAll( (previous, next) => (previous <= next) );


Разве ж это не просто и понятно? "Последовательность элементов возрастает, если для всех пар смежных элементов предыдущий элемент меньше или равен следующему". Это буквальная запись на языке программирования предыдущего предложения. Программа приближается к естественному языку. Вместо подробностей конкретного способа решения задачи (таких, как цикл обхода массива, временная переменная, выход из цикла по выполнению условия), из которых смысл производимых действий приходится реверсивно восстанавливать, ты непосредственно этот смысл выражаешь в коде.

Насчет быстрее — это другой вопрос. Это до такой степени банально, что мне даже странно про это говорить. Давно уже всем известно, что главный параметр, требующий оптимизации в программировании — это затраты на разработку, и если было бы иначе, то и самого дотнета бы не существовало. Таких программ, в которых требуется оптимизировать каждый участок кода, просто не бывает. С точки зрения теории алгоритмов с этим кодом все нормально, так как сложность у него ровно такая же, как и у цикла.
Собрался ставить минус? Да сам иди в жопу!

































































.
Re[17]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.08.10 07:07
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>>>Есть, как минимум в не-windows. Вообще это дико неудобно использовать будет.


PD>>>Вполне удобно, поверь.


G>>На C++ это будет удобно (читай надо писать свой аллокатор)?

G>>На C# это будтет удобно?

PD>Есть там поддержка mmf или нет ?

Есть.

G>>На java это будет удобно?

PD>В яве поддержка mmf есть.
Но я не это спросил.

G>>На python это будет удобно?

PD>А это меня не интересует.
Тогда зачем ты сюда пришел?

G>>Фактически это будет удобно только на С.

G>>Так что верить тебе у меня нет никаких оснований.
PD>Не хочешь — не верь. Я на Яве такое писал.
Покажи код.


G>>>>А как я уже писал в этой теме — время работы программиста гораздо дороже времени работы компьютера.

PD>>>Да, я помню про этот аргумент, обосновывающий халтуру.
G>>Обоснуй сначала что это "халтура". Если заказчик доволен и разработчик получил бабло, то это самая обычная работа.
PD>Сто раз обосновывал, поищи.
Ты стока буллшита написал на форуме, что я утону в нем пока найду в нем конкретную мысль.
Моя конкретная мысль: исполнитель доволен, заказчик доволен — значит это была хорошая работа.
Re[18]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 10:19
Оценка: +1
Здравствуйте, gandjustas, Вы писали:


G>>>На python это будет удобно?

PD>>А это меня не интересует.
G>Тогда зачем ты сюда пришел?

Обсуждать не питон и желательно не с тобой.


G>>>Фактически это будет удобно только на С.

G>>>Так что верить тебе у меня нет никаких оснований.
PD>>Не хочешь — не верь. Я на Яве такое писал.
G>Покажи код.

Да бога ради. Только кое-что я выкинул, так что считай это только прототипом


public class FileData {

    private int records_number;
    private long[] offsets;
    private int[] lengths;
    private RandomAccessFile raf;
    private FileChannel channel;
    MappedByteBuffer buffer;
    public FileData(String filename) {
            File file = new File(filename);
            long fl = file.length();
            raf = new RandomAccessFile(file, "r");
            records_number = raf.readInt();
            offsets = new long[records_number];
            lengths = new int[records_number];
            for (int i = 0; i < records_number; i++) {
                offsets[i] = raf.readLong();
                lengths[i] = raf.readInt();
            }
            channel = raf.getChannel();
            buffer = channel.map(
                    FileChannel.MapMode.READ_ONLY, 0, fl);

    }




G>Моя конкретная мысль: исполнитель доволен, заказчик доволен — значит это была хорошая работа.


Ну а моя конкретная мысль — если исполнитель доволен тем, что пользуясь некомпетентностью заказчика, всучил ему продукт низкого качества, и при этом заказчик доволен, так как не знает, какого качества тут можно достигнуть, если сделать как следует — это и есть халтура.
With best regards
Pavel Dvorkin
Re[20]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 10:50
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Ты уже забыл с чего начался разговор?

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

Ох! Ну когда вы наконец поймете, что Ваш linq строит промежуточные структуры, которые вы не видите, и они занимают место. Чудес не бывает.

Не согласен ? OK. На тебе задачу — принять откуда угодно массив и отсортировать его. Хоть с linq, хоть императивно, хоть духом святым. Только, как ты сказал, не сохраняя массив в памяти . Дисковой тоже, конечно.


G>Ты же сказал что можно зарезервить большой кусок и коммитить при необходимости для минимизации затрат (оставим обсуждение характеристик такого подхода за кадром). Это значит что надо все создаваемые объекты размещать в этой области.


Совершенно верно.

http://download-llnw.oracle.com/javase/1.4.2/docs/api/java/nio/channels/FileChannel.html#map(java.nio.channels.FileChannel.MapMode, long, long)

и метод map позволяет отмэппить любой кусок файла — так же, как в Win32. После чего туда можно писать.

G>Я же тебе сказал что это кроме как в C будет очень тяжело сделать. Ты начал спорить и привел не относящийся к делу кусок на java.


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

G>Кстати резерв большого куска и коммит по необходимости сродни работе GC.


Точнее, GC может выделить память таким почти образом (но все же не через mmf, а через VirtualAlloc), ну а все остальное к делу не относится.

G>>>Моя конкретная мысль: исполнитель доволен, заказчик доволен — значит это была хорошая работа.


PD>>Ну а моя конкретная мысль — если исполнитель доволен тем, что пользуясь некомпетентностью заказчика, всучил ему продукт низкого качества, и при этом заказчик доволен, так как не знает, какого качества тут можно достигнуть, если сделать как следует — это и есть халтура.


G>Вообще-то почти любой заказчик знает чего он хочет, особенно к концу проекта.


Неспециалист в какой бы то ни было области не может знать, что в ней возможно. Он может лишь принимать то, что ему сделают специалисты или "специалисты". А когда таких "специалистов" много и все они делают одинаково "качественный" продукт — неспециалисту крайне трудно понять, что это халтура.
With best regards
Pavel Dvorkin
Re[21]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.08.10 11:07
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:


G>>Ты уже забыл с чего начался разговор?

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

PD>Ох! Ну когда вы наконец поймете, что Ваш linq строит промежуточные структуры, которые вы не видите, и они занимают место. Чудес не бывает.

Датыче? Ну какие там структуры?
Даже если строят, то они не зависят от объема обрабатываемых данных, так что мимо кассы.

PD>Не согласен ? OK. На тебе задачу — принять откуда угодно массив и отсортировать его. Хоть с linq, хоть императивно, хоть духом святым. Только, как ты сказал, не сохраняя массив в памяти . Дисковой тоже, конечно.

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


G>>Ты же сказал что можно зарезервить большой кусок и коммитить при необходимости для минимизации затрат (оставим обсуждение характеристик такого подхода за кадром). Это значит что надо все создаваемые объекты размещать в этой области.


PD>Совершенно верно.

PD>http://download-llnw.oracle.com/javase/1.4.2/docs/api/java/nio/channels/FileChannel.html#map(java.nio.channels.FileChannel.MapMode, long, long)
PD>и метод map позволяет отмэппить любой кусок файла — так же, как в Win32. После чего туда можно писать.
Что писать? Ты сможешь в этой памяти создать managed объект? (ответ я знаю)
А если нет, то к чему вообще весь разговор, который ты начал?


G>>Я же тебе сказал что это кроме как в C будет очень тяжело сделать. Ты начал спорить и привел не относящийся к делу кусок на java.

PD>Ты просил показать кусок на Яве, где я эти channel использую. Я тебе привел. Я не телепат, чтобы знать, что именно тебе надо
А ты вообще отвечаешь только на последнее сообщение или пытаешься разговор вести.
Если первый вариант, то лучше не отвечай, тут и без тебя таких хватает.

G>>Кстати резерв большого куска и коммит по необходимости сродни работе GC.

PD>Точнее, GC может выделить память таким почти образом (но все же не через mmf, а через VirtualAlloc), ну а все остальное к делу не относится.
А это как раз значения не имеет, суть остается, непрерывный кусок зарезервированной памяти, выделяемой линейно.

G>>Вообще-то почти любой заказчик знает чего он хочет, особенно к концу проекта.

PD>Неспециалист в какой бы то ни было области не может знать, что в ней возможно. Он может лишь принимать то, что ему сделают специалисты или "специалисты". А когда таких "специалистов" много и все они делают одинаково "качественный" продукт — неспециалисту крайне трудно понять, что это халтура.
Если специалисты не действуют согласовано, то возникает конкуренция, которая ведет к снижению цен и\или повышению качества. А если присутствует сговор, то этим будут заниматься антимонопольные службы.

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

Так что как ни крути, то что какой-то софт по каким-то характеристикам тебя не устраивает, то это все равно никого не волнует. И можешь называть это халтурой, а люди все равно будут так работать.
Re[19]: Помогает ли Linq сделать код понятнее или быстрее?
От: vdimas Россия  
Дата: 03.08.10 15:01
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну вот и отлично. Хотя и забавная реализация — сделать полтора десятка overload методов на 2 функциях Win API — это уметь надо!


Ввиду отсутствия значений аргументов по-умолчанию, это обычная практика для дотнета — плодить комбинаторные комбинации одной и той же перегрузки ф-ии с разным кол-вом и составом аргументов.
Re[21]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 04.08.10 04:19
Оценка: +1
PD>Неспециалист в какой бы то ни было области не может знать, что в ней возможно. Он может лишь принимать то, что ему сделают специалисты или "специалисты". А когда таких "специалистов" много и все они делают одинаково "качественный" продукт — неспециалисту крайне трудно понять, что это халтура.

Решил дописать. Чтобы ясна была моя позиция до конца.

Если пользователь недоволен продуктом, то это одно из двух. Либо продукт некачественный. Тут все ясно. Либо продукт качественный, но не решает его задачу. Например, Paint — продукт вполне качественный (допустим), но если пользователю нужны возможности Photoshop, то Paint'ом он будет недоволен, конечно.

Если вместо пользователя мы имеем заказчика, то вариант 2 означает, что либо заказчик не сумел правильно изложить, что ему надо, либо разработчик не сумел правильно понять и сделать.

Резюме — если пользователь недоволен, его мнение важно и существенно при оценке качества за исключением разве что каких-то маргинальных случаев.

А вот если пользователь доволен — это ничего вообще не значит в плане оценки качества. И иной подход очень быстро приведет нас в царство халтуры.

Нигде пользователь не решает, является ли продукт качественным. Если я проехал по мосту, а мост не развалился — я (пользователь) доволен, но судить на этом основании о том, качественно ли сделан мост, никак нельзя. Если я положил деньги на вклад, а через год получил их с процентами — это не основание, чтобы судить о качественной работе банка. И даже если я съел мороженое, и было вкусно, и я не отравился — это тоже не основание, чтобы считать это мороженое качественным. Только специалисты могут судить о качестве. Специалисты — мостостроители, банкиры, эксперты по пищевым продуктам...

Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.
With best regards
Pavel Dvorkin
Re[22]: пояснение о качестве
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 07:15
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот если пользователь доволен — это ничего вообще не значит в плане оценки качества.

Это значит все. Пользователь доволен — исполнитель сделал свою работу.


PD>И иной подход очень быстро приведет нас в царство халтуры.

Счего бы?

Ты уже несколько лет приводишь такое утверждение, ни разу не обосновав его. Ты оправдываешься за непродуктивную работу?


PD>Нигде пользователь не решает, является ли продукт качественным.

Только пользователь и решает. Причем не только в ПО, а и во многих других сферах.

PD>Если я проехал по мосту, а мост не развалился — я (пользователь) доволен, но судить на этом основании о том, качественно ли сделан мост, никак нельзя. Если я положил деньги на вклад, а через год получил их с процентами — это не основание, чтобы судить о качественной работе банка. И даже если я съел мороженое, и было вкусно, и я не отравился — это тоже не основание, чтобы считать это мороженое качественным. Только специалисты могут судить о качестве. Специалисты — мостостроители, банкиры, эксперты по пищевым продуктам...

Хреновые у тебя аргументы.

PD>Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.


Ты пытаешься оценить качество продукта массового потребления по мнению одного пользователя.
Так нельзя делать, вот посмотри на iPhone (прям в соседних темах), сколько бы местные "эксперты" не отзывались негативно о качестве сего аппарата, а продажи у эппла только растут.

Когда продукт массовый, то надо ориентироваться на мнение этих самых масс, а не маленькой группы "экспертов".

А вот гораздо интереснее вопрос "качества" стоит когда продукт заказной разработки для одного заказчика.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: Кэр  
Дата: 04.08.10 07:34
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

0K>>>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


Кэр>>Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.


G>Да ну?

G>Сделай Select, SelectMany и Where без Linq.

Что ну? Здесь порождение новой коллекции. Linq в таких случаях экономит промежуточные/результирующие переменные коллекции — крайне удобно. Для простого перебора это не важно.

G>Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.


Foreach дает перебор ленивой бесконечной коллекции.

G>
G>seq.PairwiseBy((a,b) => a<b).All()
G>

G>По русски читать в обратном порядке: "Все пары последовательных элементов такие что первый элемент меньше второго".

Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.
Re[23]: пояснение о качестве
От: CreatorCray  
Дата: 04.08.10 10:40
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.

Софт написанный студентами левой ногой на подпорках тоже может решать проблемы заказчика. Вот только хорошим его назвать трудно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
От: fmiracle  
Дата: 04.08.10 11:46
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


Бизнес-требования.

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

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

При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: Кэр  
Дата: 04.08.10 12:42
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

Кэр>>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.


K>А инструкция и будет. Пододите курсор к вызову одной библиотечной функции — всплывает подсказка. Подводите к другой — и тут подсказка. Да и названия функций, если удачно подобраны — уже подсказка. К невнятным манипуляциям в цикле никаких подсказок нет, если только к каждому циклу они не будут написаны самим программистом. Ну и на практике он они написаны не будут.

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

Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.

Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?

Почему для простейшего алгоритма вы начали требовать знания библиотечных функций, тем более не самых популярных? Я, конечно, понимаю, что синдром студента "я выучил, значит все должны выучить!" и принцип "краткость — сестра нашего брата!" — это одни из самых мощных мотиваторов в нашей профессии. Но во всем надо знать меру.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 12:56
Оценка: -1
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, Klapaucius, Вы писали:


Кэр>>>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.


K>>А инструкция и будет. Пододите курсор к вызову одной библиотечной функции — всплывает подсказка. Подводите к другой — и тут подсказка. Да и названия функций, если удачно подобраны — уже подсказка. К невнятным манипуляциям в цикле никаких подсказок нет, если только к каждому циклу они не будут написаны самим программистом. Ну и на практике он они написаны не будут.

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

Кэр>Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.

Это потому что ты Linq не понимаешь, а циклы понимаешь.
Для человека, который одинаково понимает (не понимает) и то и другое, linq будет проще.

Кэр>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?

Цикл требует того же самого.
Ты сначала для себя определи будет ли упорядоченным пустой массив и из одного элемента.

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

А чего ты пытаешься требовать знание как пишется for и думать с чего начинается индексация массива, и как вообще получить длину массива, а если там не массив, а IEnumerable<T>?
Re[26]: пояснение о качестве
От: Cadet  
Дата: 04.08.10 14:13
Оценка: +1
Здравствуйте, 24, Вы писали:

24>А за поддержку кто платить будет? Заказчик. Значит в таком случае это плохая программа с точки зрения заказчика.


А разве это противоречит точу что я написал? С другой стороны если в этой программе тетя Маша-бухгалтер строит отчеты для налоговой за минуту и гендир смог сэкономить на найме второго буха в помощь первому — тут надо оценивать, что было бы затратнее. А безапеляционно заявить "фу, на яве писана! прога говно!", или "ааа, пузырек внутри, что за говнокодер наклепал!", или "полсекунды работает запрос, писал бы я на плюсах — в десятую долю секунды бы уложился, прога отстой" — это знаешь ли минимум смешно. Как сказать "Камаз отстой, я на хундае быстрее доеду".
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[26]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 14:46
Оценка: -1
Здравствуйте, Mamut, Вы писали:

M>>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,


PD>>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


M>Никто не внушал. Это то время, на которое он, как заказчик, согласен. Не мы это время ему внушали Если будет 0.1 сек — он только будет рад.


И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?

Понимаешь, вот ты пишешь "Это то время, на которое он, как заказчик, согласен". Верно. Не вы внушали. Тоже верно. Просто, исходя из общего уровня и не знаю чего еще он пришел к выводу, что здесь быстрее чем в 5 сек не уложишься. А оказывается, можно в 0.1 сек уложиться. Вот поэтому я и говорю, что мнение заказчика — не аргумент.. Он не в состоянии оценить, с какой это скоростью можно технически сделать. Только специалист может оценить и сказать — если вы (опять же не о вас речь, конечно) складываете 2 матрицы размером 100*100 за 1 сек, то не морочьте мне голову , потому что такие скорости надо было в досовские времена демонстрировать, а сейчас это халтура.
With best regards
Pavel Dvorkin
Re[25]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 04.08.10 14:48
Оценка: -1
Здравствуйте, Mamut, Вы писали:

M>Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта


Извини, но я привел тебе ряд примеров — мост, банк, мороженое. Возражений на эти примеры я не услышал. Могу еще десяток привести. А если эти примеры принимаются, то почему в ИТ все иначе ? Только, пожалуйста, без ссылок на особый путь России
With best regards
Pavel Dvorkin
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 15:48
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Mamut, Вы писали:


M>>>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,


PD>>>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


M>>Никто не внушал. Это то время, на которое он, как заказчик, согласен. Не мы это время ему внушали Если будет 0.1 сек — он только будет рад.


PD>И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?


PD>Понимаешь, вот ты пишешь "Это то время, на которое он, как заказчик, согласен". Верно. Не вы внушали. Тоже верно. Просто, исходя из общего уровня и не знаю чего еще он пришел к выводу, что здесь быстрее чем в 5 сек не уложишься. А оказывается, можно в 0.1 сек уложиться. Вот поэтому я и говорю, что мнение заказчика — не аргумент.. Он не в состоянии оценить, с какой это скоростью можно технически сделать. Только специалист может оценить и сказать — если вы (опять же не о вас речь, конечно) складываете 2 матрицы размером 100*100 за 1 сек, то не морочьте мне голову , потому что такие скорости надо было в досовские времена демонстрировать, а сейчас это халтура.


Ты ошибаешься в самом начале. Если время в 5 сек устраивает заказчика, то никто не будет заниматься оптимизацией до 0.1 сек.
Я бы, как руководитель, даже запретил бы такое делать.
Re[30]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 16:30
Оценка: :)
Здравствуйте, FR, Вы писали:

PD>>Нет, я просто примел быстродействие как пример. Не нравится — изволь, заменю. Качество интерфейса — можно же сделать "красиво", а можно "тяп-ляп" при том, что функциональность будет соблюдена в обоих случаях. Объем требуемой памяти. И т.д.


FR>Хорошо.


Хорошо

FR>Но реальность такова что идеального качества достигнуть невозможно, всегда будет компромисс.


Да, конечно. Мерседес — это компромисс, навеное, можно и получше за такую цену. Но специалисты скажут, что тут могло бы быть лучше и где.

FR>И опять по отдельным параметрам типа скорости или интерфейса вообще в большинстве случаев невозможно определить халтура

FR>перед тобой или нет.

Так я об этом и говорю. Пользователь — не может. Ну а хорошие специалисты все же могут. Все же если вы ухитрились 1 сек складывать 2 матрицы потому что их хранить кто-то предложил в виде хеш-таблицы (не буду упоминать кто, но вполне уважаемый член RSDN однажды такое предложил для задачи нахождения собственных векторов и значений ), то это и есть халтура или как минимум неумение работать качественно.
With best regards
Pavel Dvorkin
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 18:25
Оценка: +1
M>>>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,

PD>>>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


M>>Никто не внушал. Это то время, на которое он, как заказчик, согласен. Не мы это время ему внушали Если будет 0.1 сек — он только будет рад.


PD>И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?


Вообще-то, пофиг, что я считаю. Заказчик просто получит более качественный продукт. Мое мнение вообще не играет роли.

PD>Понимаешь, вот ты пишешь "Это то время, на которое он, как заказчик, согласен". Верно. Не вы внушали. Тоже верно. Просто, исходя из общего уровня и не знаю чего еще он пришел к выводу, что здесь быстрее чем в 5 сек не уложишься. А оказывается, можно в 0.1 сек уложиться. Вот поэтому я и говорю, что мнение заказчика — не аргумент.. Он не в состоянии оценить, с какой это скоростью можно технически сделать. Только специалист может оценить и сказать — если вы (опять же не о вас речь, конечно) складываете 2 матрицы размером 100*100 за 1 сек, то не морочьте мне голову , потому что такие скорости надо было в досовские времена демонстрировать, а сейчас это халтура.


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


dmitriid.comGitHubLinkedIn
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: Кэр  
Дата: 04.08.10 20:00
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

Кэр>>Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.

G>Это потому что ты Linq не понимаешь, а циклы понимаешь.

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

G>Для человека, который одинаково понимает (не понимает) и то и другое, linq будет проще.


Я человек, который понимает и то, и другое — и я утверждаю, что пример с linq и сложнее, и хуже по целому ряду критериев.

Кэр>>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?

G>Цикл требует того же самого.

Цикл не прячет это знание в библиотечной функции. Эта функция обладает вполне конкретным поведением, которое надо сначала изучить, а потом гарантировать неизменность.

G>Ты сначала для себя определи будет ли упорядоченным пустой массив и из одного элемента.


Для какого начала? Чтобы общаться с вашим высоким просвященным высочеством?

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

G>А чего ты пытаешься требовать знание как пишется for и думать с чего начинается индексация массива, и как вообще получить длину массива,

Это базовые навыки, которые шаряться между различными языками. Keep things as simple as possible.

G>а если там не массив, а IEnumerable<T>?


То будет foreach вместо for.
Re[29]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 05:48
Оценка: +1
M>>А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

PD>Опять то же. А если заказчик не дает пенделя или (что более вероятно) ему это показывать — все равно что показывать неандертальцу ракетный двигатель, а там халтура очевидная внутри — ты все равно считаешь этот продукт качественным ?


Критерий вычисления халтуры ровно один: работает программа в рамках, поставленных заказчиком, или не работает. Технический аспект реализации вообще никого не волнует. Ну, кроме перфекционистов, естественно


dmitriid.comGitHubLinkedIn
Re[32]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 10:36
Оценка: :)
PD>Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!

Это продукт, удовлетворяющий твоим критериям качества


dmitriid.comGitHubLinkedIn
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 10:57
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, FR, Вы писали:


FR>>Здравствуйте, gandjustas, Вы писали:


FR>>>>В юнит тесте алгоритма сортировки


G>>>Зачем? Можно просто сравнить с эталоном.


FR>>Нельзя, задолбаешся три миллиона цифр вводить


G>А зачем тебе столько?


G>Главное проверить общий случай (один) и corner cases.


FR>>>>Мы похоже по разному понимаем один проход.

FR>>>>Я имел в виду алгоритмическую сложность которая у сортировки существенно выше чем у линейного поиска.
G>>>Алгоритмическая сложность у нормального алгоритма быстрой сортировки такая же линейная, как у проверки на упорядоченность.

FR>>Покажи мне этот алгоритм, radix не предлагай он не универсален.


G>http://algolist.manual.ru/sort/quick_sort.php


G>При выборе опорным элементом центральный элемент будет ровно один проход.


Че-то я туплю сегодня, все равно будут рекурсивыне вызовы.

Надо было спать больше.
Re[46]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 06.08.10 05:51
Оценка: +1
PD>Ладно, давай заканчивать.

Думаю, можно Все равно, мне кажется, мы друг друга понимаем, но КСВ обязывает


dmitriid.comGitHubLinkedIn
Re[48]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 06.08.10 10:13
Оценка: +1
M>>Думаю, можно Все равно, мне кажется, мы друг друга понимаем, но КСВ обязывает

PD>Понимаешь, если уж честно...


PD>Я твой критерий не приму, но понять могу. Сказать, что он ложный на 100%, не скажу. Какая-то доля истины в нем, наверное есть. Кто платит — тот и заказывает музыку.


PD>Меня другое беспокоит. Далее — само собой, без личностей.


PD>Это опасный критерий. Может, в умелых, профессиональных руках он и сработает как следует. Но он открывает широкие ворота для халтурщиков. Он дает им основание делать абы как, лишь бы заказчик рекламацию не выставил. А быстродействие нынешних компьютеров таково, что очень многое и можно сделать абы как, все равно тактовая частота и объем ОП все покроет. Вот пришлось бы им то же на Пентиум-100 делать (а я 100% уверен, что для большинства сайтов с 10 посетителями в день Пентиум-100 и 16 Мб — вполне достаточно, доказательсво простое : работали же лет 10-15 назад) — они бы иначе заговорили.


Согласен

PD>Вот давай до абсурда доведем. Быстродействие (в том числе и диска, чтоб ему) и память еще раз в 20 увеличились. А задачи остались прежними, потому что они бизнес-сутью определяются, а не тактовой частотой (не все, конечно). Да тут полное раздолье будет — валяй что угодно, любую халтуру делай, все равно заказчик доволен будет. И создастся т.н. "террор среды" (впрочем, почему создастся, он уже есть) — когда много людей делают халтуру, они себя быстро убеждают в том. что они именно как надо делают, а все кто их за халтуру ругает, ничего не понимают и воообще зануды.



Свобода развращает, а абсолютная свобода развращает абсолютно. В данном случае свобода — это доступность ресурсов.

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


PD>Не боишься ?


Боюсь, кстати Но будем надеяться на лучшее


dmitriid.comGitHubLinkedIn
Re[56]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.08.10 08:03
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

I>>Один на сервер да с посещаемостью 20 человек — это уже прошлый век.


PD>Если бы рост возможностей аппаратуры в 21 веке был равен нулю (вышли на плато), то так и было бы.


При чем здесь рост возможностей ? 1 сайт на сервер это сейчас где то за гранью стат погрешности.

I>>Вот у меня, например, около 20 сайтов которыми пользуюсь довольно часто. Гуглмапс например на п-100 никак не пойдет.


PD>Я так думаю, что он вполне пошел бы на 16 Мб. Что там, в самом деле, памяти-то требует ? Подумаешь — несколько картинок разного размера и разрешения.


Гуглмапс на п-100 это нонсенс

Ты извини, но это такой феерический бред, что дальше я скипнул ибо ни читать, ни писать больше не хочется.
Re[64]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.10 13:54
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

I>>А если уже используется ICC, как ускорить код без суперкомпиляции ?


PD>Эта самая суперкомпиляция — скорее абстрактное теоретическое понятие, чем реально действующий механизм.


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

I>>Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.


PD>Ну и аргумент. Определять возможности языка наличием или отсутствием библиотек — ну и ну.


Библиотеки являются следствием из языка.

Если для языка нельзя написать хороший инструмент, например, для генерации кода, то естественно и библиотек требующих генерацию кода, никогда не появится.

>Не плохие они, а просто для других задач сделаны.


Потому и не надо нести чушь про расходование ресурсов ибо "для других задач"

Вот в этих "других задач" и пользуй свой С++.
Re[68]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.10 14:03
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

>>Числодробилки это далеко не самое главное. Это было актуально еще 10 лет назад.


PD>У кого какие задачи, можно было бы понять.


Кол.во задач растет мягко говоря нелинейно.

Задачи, решение которых экономит миллиарды долларов уже давным давно не решаются на С++.

Всё, забудь.

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


PD>Это ты моему заказчику скажи. В моих задачах быстродействие винта вообще ни при чем, а вот по времени сказано уложиться в 5 мсек — и все.


Такие задачи сейчас уже редкость.

Сейчас, например, актуально оптимизировать логистику — не самый эффективный алгоритм на питоне или хоть джаваскрипте сэкономи предприятию вагон денег и для этого С++ просто не нужен.

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

I>>А вот ускорять ввод-вывод, вводить кеширование и тд и тд — здесь уже С++ толком ничем помочь и не может.


PD>А здесь вообще никто помочь не может. Скорость в/в определяется ОС. А кеширование почему это на С++ нельзя делать ?


Всё можно сделать. Ты уверен, что С++ является наиболее удобным языком для математиков или узких специалистов ?

У меня в этом сильное сомнение.

I>>Инструменты для С++ практически отсутствуют — и это факт.

PD>Какие ? Для задач построения сайтов — да, но никто сайты на С++ и не пишет.

Дело не только в сайтах.

Оптимизация, рефакторинг, анализ, генерация кода.

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


PD>Не согласен. Это может быть верно только в той части, на которую он заточен. Как только надо что-то нетипичное для этого языка сделать — все, плохо. Возьми тот же Linq и попробуй пройди там матрицу не по строкам и не по столбцам, а по диагоналям. Ну а мне все равно на С++.


Обход по диагоналям это по твоему высокоуровневая оптимизация ?

Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: anton_t Россия  
Дата: 13.08.10 04:44
Оценка: +1
Здравствуйте, 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: Помогает ли Linq сделать код понятнее или быстрее?
От: IT Россия linq2db.com
Дата: 31.07.10 23:56
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Каков смысл в вашем Linq?


Хотя бы в том, что твой пример без Linq упадёт на пустой последовательности.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 01.08.10 06:38
Оценка:
Здравствуйте, SpaceConscience, Вы писали:

SC>Во-первых, у тебя оформление кода неправильное. Приближаться к "мирку" (к декларативному другому "мирку"), думаю, надо начать с оформления кода. Все надо стараться записать одной строчкой, переменным давать имена из одного-двух символов, никогда не указывать имена типов, главное правило: всегда плевать на эффективность ради краткости, ну и другие полезные практики:


SC>

SC>var e = true; for (var i = 1; i < xs.Length; i++) if (xs[i-1] > xs[i]) e = false;
SC>var isAscending = e;

SC>


Много недостатков алгоритм даже не квадратичный, "if" вместо оператора "?" мутабельный e нет рекурсии, в общем незачет
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.08.10 12:02
Оценка:
Здравствуйте, vitasR, Вы писали:

R>Здравствуйте, gandjustas, Вы писали:


0K>>>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?

G>>Твой в любом случае хуже всех, так как принимает массив, а не любую последовательность. Твой вариант является наименее общим при том что самый длинный.

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


Скажи по-русски что такое отсортированный массив.

R>стремление к общности там где она нафиг не нужна — большая ошибка на самом деле.

Обоснуй.

G>>В F# есть потрясающая функция Seq.pairwise, которая список [x1,x2,x3...] превращает в список пар [(x1,x2), (x2,x3)...] делает примерно тоже что в вариантах 2 и 4, только с одним итератором и совершенно не требует эмуляции ленивости с запоминанием.


R>работает, правда, все в разы медленнее, но кого нынче это волнует...

Конечно, не волнует. Время компьютера дешево, а время программиста дорого.
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 01.08.10 12:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Хотя бы в том, что твой пример без Linq упадёт на пустой последовательности.


А ваш пример на Linq для пустой последовательности выдаст true или false? Значение для пустой последовательности не определено -- это зависит от логики программы. По этому проверку я не включал.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 01.08.10 12:19
Оценка:
Здравствуйте, vitasR, Вы писали:

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


Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.08.10 12:43
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, gandjustas, Вы писали:


G>>Твой в любом случае хуже всех, так как принимает массив, а не любую последовательность.


0K>Разницы нет последовательность или тип, который нужно листать с помощью вызова функции. Вообще в 99% массивы предпочтительнее -- все равно все хранится в памяти.


Это ты где такую шутку прочитал?
99% данных обычно программа получает извне.
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 01.08.10 12:49
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?


true, также и для массива из одного элемента.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 01.08.10 12:53
Оценка:
Здравствуйте, 0K, Вы писали:

0K>главное понятность кода а не во сколько байт ты его втиснул.


Понятность понятие субъективное.
Декларативный код обычно выигрывает в понятности, особенно если для этого есть примитивы, в Linq их правда похоже нет.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 01.08.10 12:59
Оценка:
Здравствуйте, FR, Вы писали:

0K>>Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?


FR>true, также и для массива из одного элемента.


Для массива из одного элемента -- согласен. А если вообще элементов нет?
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 01.08.10 13:04
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это ты где такую шутку прочитал?

G>99% данных обычно программа получает извне.

Ну да, и записывает их в ОЗУ. А раз в ОЗУ, то лучше массив.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 01.08.10 13:06
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Для массива из одного элемента -- согласен. А если вообще элементов нет?


Математика говорит что

Пустое множество считается упорядоченным.


http://www.pm298.ru/umnozh.php
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: 0K Ниоткуда  
Дата: 01.08.10 13:15
Оценка:
Здравствуйте, Yarik_L, Вы писали:

Y_L>Если взять любой упорядоченный массив, то очевидно что все массивы, получающиеся из исходного вычеркиванием отдельных элементов, также будут упорядоченными. Значит и пустой массив обязан быть таковым


Для пустого нужно сделать исключение -- его состояние не определено. Объясню почему: по определению упорядоченного массива.
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 01.08.10 14:18
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?


вопрос соглашения, типа чему равен факториал нуля.

скорее true, по той логике, что неупорядоченный массив всегда можно упорядочить, пустой массив сделать более упорядоченным чем он уже есть нельзя.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.08.10 16:09
Оценка:
Здравствуйте, vitasR, Вы писали:

R>Здравствуйте, gandjustas, Вы писали:



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

G>>
G>>Скажи по-русски что такое отсортированный массив.

R>???


Чего непонятного. Приведи определение отсортированного массива (последовательности чисел в общем случае)


R>>>стремление к общности там где она нафиг не нужна — большая ошибка на самом деле.

G>>Обоснуй.

R>например здесь

Как это относится к вопросу?
Ты не путай общность "архитекруры" и общность алгоритма. Второе всегда лучше, первое — спорно.

R>>>работает, правда, все в разы медленнее, но кого нынче это волнует...

G>>Конечно, не волнует. Время компьютера дешево, а время программиста дорого.

R>ню-ню. время программиста, который для проверки упорядоченности массива его сортирует, а потом сравнивает (в оригинале такое чудо есть), должно оцениваться по ОТРИЦАТЕЛЬНОЙ ставке .

С чего ты взял? Задачу то он выполняет.
И такая проверка закончится быстрее, чем будет написан цикл.

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

Я видел "очень серьезных и крутых программистов", которые делают проект нерабочим гораздо более изощренными способами.

R>Для иллюстрации достаточно на WinMobile в тамошнем ворде открыть plain text на пару мегабайт -- тоже небось чье-то индусское время очень дорого стоило...

Совсем не понял как это связано с проверкой упорядоченности массива.
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.08.10 18:26
Оценка:
Здравствуйте, vitasR, Вы писали:

R>Здравствуйте, gandjustas, Вы писали:


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

G>>>>
G>>>>Скажи по-русски что такое отсортированный массив.

R>>>???


G>>Чего непонятного. Приведи определение отсортированного массива (последовательности чисел в общем случае)


R>Вы не знаете что такое отсортированный массив?


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

G>>Как это относится к вопросу?

G>>Ты не путай общность "архитекруры" и общность алгоритма. Второе всегда лучше, первое — спорно.

R>любая задача должна решаться адекватными средствами. Неадекватно отстреливать воробьев из пушек, неадекватно маленькому ребенку, спрашивающему почему небо голубое, рассказывать про рассеяние Рэлея; неадекватно использовать LINQ там, где прекрасно работает простой цикл, а на LINQ'е приходится извращаться и увеличивать сложность алгоритма.

Эмоциональная херня, LINQ — всего лишь вызовы функций, циклы гораздо сложнее, особенно for.


R>>>ню-ню. время программиста, который для проверки упорядоченности массива его сортирует, а потом сравнивает (в оригинале такое чудо есть), должно оцениваться по ОТРИЦАТЕЛЬНОЙ ставке .

G>>С чего ты взял? Задачу то он выполняет.
G>>И такая проверка закончится быстрее, чем будет написан цикл.

R>извините, но это уже на профнепригодность тянет ;(

Это правда жизни.

R>Вы вообще в курсе что массивы бывают большие?

Там где массивы большие, там алгоритмы сильно другие.

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

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

Кстати прочитай у Липперта поты с тегом Linq (если не знаешь что это, то наверное ты зря тут пишешь). Там и про Linq и про оптимизацию и прочую фигню есть.

R>>>Для иллюстрации достаточно на WinMobile в тамошнем ворде открыть plain text на пару мегабайт -- тоже небось чье-то индусское время очень дорого стоило...

G>>Совсем не понял как это связано с проверкой упорядоченности массива.
R>самым что ни на есть прямым образом -- word на winmobile отличный (и, к сожалению, очень далеко не единственный) пример того, к чему приводит безмозглое программирование без понимания.
Напиши лучше, ругать все горазды.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: SpaceConscience  
Дата: 01.08.10 21:02
Оценка:
FR>Много недостатков алгоритм даже не квадратичный, "if" вместо оператора "?" мутабельный e нет рекурсии, в общем незачет

Извини, ты ничего не понял. Тут вся соль в том, что это обычный, простецкий, прямолинейный, кондовый, понятный любому нубу и быдлокодеру вульгарный императивный код, просто отформатированный идиотским образом, и, что характерно, он при беглом взгляде напоминает фрагмент типичного произведения обитателей "мирка".
Собрался ставить минус? Да сам иди в жопу!

































































.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: IT Россия linq2db.com
Дата: 01.08.10 23:00
Оценка:
Здравствуйте, 0K, Вы писали:

Учимся держать эмоции в рамках дозволенного. Последнее (единственное в этой ветке) китайское.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: Lloyd Россия  
Дата: 01.08.10 23:11
Оценка:
Здравствуйте, 0K, Вы писали:

G>>99% данных обычно программа получает извне.


0K>Ну да, и записывает их в ОЗУ.


При больших объемах данные как правило получаются кусками, а не целиком

0K>А раз в ОЗУ, то лучше массив.


А раз кусками, то не лучше.
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 02.08.10 02:59
Оценка:
Здравствуйте, SpaceConscience, Вы писали:

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


Это я понял, но ты же свои же рекомендации насчет эффективности не выполнил, так что все-равно незачет
Ну и мирок твой куда-то в сторону перла вытягивается, у функциональщиков однострочники точно давно не в моде
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 07:36
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>При больших объемах данные как правило получаются кусками, а не целиком


0K>>А раз в ОЗУ, то лучше массив.


L>А раз кусками, то не лучше.


Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.
With best regards
Pavel Dvorkin
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: fddima  
Дата: 02.08.10 09:49
Оценка:
Здравствуйте, 0K, Вы писали:

Всему своё место. Помогает.
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 10:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Lloyd, Вы писали:


L>>При больших объемах данные как правило получаются кусками, а не целиком


0K>>>А раз в ОЗУ, то лучше массив.


L>>А раз кусками, то не лучше.


PD>Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.


Ага, дико эффективное решение.
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 10:19
Оценка:
Здравствуйте, gandjustas, Вы писали:


PD>>Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.


G>Ага, дико эффективное решение.


И что же тут неэффективного, можно пояснить ? Разумееется, под динамическим массивом понимается не то убожество, которое есть во многих средах, а механизм резервирования и коммитирования памяти, когда изменение размера производится всегда без переаллокации.
With best regards
Pavel Dvorkin
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 02.08.10 10:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.


А зачем их хранить, проще сразу обработать.
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 10:28
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:



PD>>>Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.


G>>Ага, дико эффективное решение.


PD>И что же тут неэффективного, можно пояснить ? Разумееется, под динамическим массивом понимается не то убожество, которое есть во многих средах, а механизм резервирования и коммитирования памяти, когда изменение размера производится всегда без переаллокации.


Конкретнее, как это сделать не зная заранее длину массива?
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 02.08.10 10:29
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И что же тут неэффективного, можно пояснить ? Разумееется, под динамическим массивом понимается не то убожество, которое есть во многих средах, а механизм резервирования и коммитирования памяти, когда изменение размера производится всегда без переаллокации.


Ну те же самые генераторы итераторы и т. п. (включая и linq) этим же самым и занимаются.
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 10:29
Оценка:
Здравствуйте, FR, Вы писали:

FR>А зачем их хранить, проще сразу обработать.


Ну это от задачи зависит.
With best regards
Pavel Dvorkin
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 10:32
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>И что же тут неэффективного, можно пояснить ? Разумееется, под динамическим массивом понимается не то убожество, которое есть во многих средах, а механизм резервирования и коммитирования памяти, когда изменение размера производится всегда без переаллокации.


G>Конкретнее, как это сделать не зная заранее длину массива?


Обычно некую верхнюю границу (G) мы знаем. Можно ее на всякий случай в несколько раз увеличить. Резервируем пространство размером G (при этом память не выделяется), а потом коммитируем кусками потребного размера. См. VirtualAlloc.
With best regards
Pavel Dvorkin
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 10:36
Оценка:
Здравствуйте, FR, Вы писали:

PD>>И что же тут неэффективного, можно пояснить ? Разумееется, под динамическим массивом понимается не то убожество, которое есть во многих средах, а механизм резервирования и коммитирования памяти, когда изменение размера производится всегда без переаллокации.


FR>Ну те же самые генераторы итераторы и т. п. (включая и linq) этим же самым и занимаются.


Можно поподробнее ? Например, классический способ заполнения памяти — memset или memcpy. Как это с помощью итераторов сделать или linq ? Разумеется, с неменьшей эффективностью.
With best regards
Pavel Dvorkin
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 02.08.10 10:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Можно поподробнее ? Например, классический способ заполнения памяти — memset или memcpy. Как это с помощью итераторов сделать или linq ? Разумеется, с неменьшей эффективностью.


Используя зависимые типы и суперкомпиляцию которые сведут использование итераторов и т. п. к memset.

Тебя все время сносит или на mmf или на VirtualAlloc притом независимо то начальной темы
Re[12]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 11:19
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Можно поподробнее ? Например, классический способ заполнения памяти — memset или memcpy. Как это с помощью итераторов сделать или linq ? Разумеется, с неменьшей эффективностью.


FR>Используя зависимые типы и суперкомпиляцию которые сведут использование итераторов и т. п. к memset.




FR>Тебя все время сносит или на mmf или на VirtualAlloc притом независимо то начальной темы


От начальной — да. Но отвечал-то я на замечание LLoyd
With best regards
Pavel Dvorkin
Re[12]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 11:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ты предлагаешь всю работу с памятью делать через winapi?

G>Как-то слишком круто.

Ну, во-первых, она всегда делается через winapi, потому что другого механизма в конечном счете нет.

Но явно — не обязательно. Кстати, вроде бы как работу с mmf обещали поддерживать в .NET 4.0. Сделали ?
With best regards
Pavel Dvorkin
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: fmiracle  
Дата: 02.08.10 11:28
Оценка:
Здравствуйте, vitasR, Вы писали:

R>извините, но это уже на профнепригодность тянет ;(

R>Вы вообще в курсе что массивы бывают большие? И что замена алгоритма сложностью O(n) на O(n*n) запросто приводит к тому, что на маленьких тестовых примерах у девелопера все работает нормально, а в реальной жизни, на реальных больших данных у юзера все фатально тормозится и виснет. Причем ладно бы замена хоть как-то упрощала жизнь, а то просто тупое вредительство...

А может быть стоило бы задуматься о контексте задачи, а потом уже ломать копья про (не)эффективность?

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

И в таком применении лаконичная, надежная и легкопонятная конструкция проверки рулит неимоверно. А ее минусы по эффективности одновременно с этим проблем не создают вообще.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[13]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 11:34
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:


G>>Ты предлагаешь всю работу с памятью делать через winapi?

G>>Как-то слишком круто.

PD>Ну, во-первых, она всегда делается через winapi, потому что другого механизма в конечном счете нет.

Есть, как минимум в не-windows. Вообще это дико неудобно использовать будет.
А как я уже писал в этой теме — время работы программиста гораздо дороже времени работы компьютера.

PD>Но явно — не обязательно. Кстати, вроде бы как работу с mmf обещали поддерживать в .NET 4.0. Сделали ?

Сделали.
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: Lloyd Россия  
Дата: 02.08.10 11:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

L>>А раз кусками, то не лучше.


PD>Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.


А какой смысл их хранить, если можно не хранить?
Re[14]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 11:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Есть, как минимум в не-windows. Вообще это дико неудобно использовать будет.


Вполне удобно, поверь.

G>А как я уже писал в этой теме — время работы программиста гораздо дороже времени работы компьютера.


Да, я помню про этот аргумент, обосновывающий халтуру.

PD>>Но явно — не обязательно. Кстати, вроде бы как работу с mmf обещали поддерживать в .NET 4.0. Сделали ?

G>Сделали.

Так почему не использовать ?
With best regards
Pavel Dvorkin
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 02.08.10 11:41
Оценка:
Здравствуйте, Lloyd, Вы писали:

PD>>Ну если уж на то пошло, то данные, получаемые кусками, никто не мешает хранить в массиве, особенно если массив динамический.


L>А какой смысл их хранить, если можно не хранить?


Если можно не хранить, то, конечно, лучше не хранить. Но если данные приходят кусками, а обрабатывать их можно , только получив все данные, то придется хранить.
With best regards
Pavel Dvorkin
Re[15]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 12:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:


G>>Есть, как минимум в не-windows. Вообще это дико неудобно использовать будет.


PD>Вполне удобно, поверь.


На C++ это будет удобно (читай надо писать свой аллокатор)?
На C# это будтет удобно?
На java это будет удобно?
На python это будет удобно?

Фактически это будет удобно только на С.

Так что верить тебе у меня нет никаких оснований.

G>>А как я уже писал в этой теме — время работы программиста гораздо дороже времени работы компьютера.

PD>Да, я помню про этот аргумент, обосновывающий халтуру.
Обоснуй сначала что это "халтура". Если заказчик доволен и разработчик получил бабло, то это самая обычная работа.

PD>>>Но явно — не обязательно. Кстати, вроде бы как работу с mmf обещали поддерживать в .NET 4.0. Сделали ?

G>>Сделали.

PD>Так почему не использовать ?


Зачем?
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: Lloyd Россия  
Дата: 02.08.10 12:06
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

L>>А какой смысл их хранить, если можно не хранить?


PD>Если можно не хранить, то, конечно, лучше не хранить.


Обсуждаемый пример как раз из этого разряда.
Re[18]: Помогает ли Linq сделать код понятнее или быстрее?
От: CreatorCray  
Дата: 02.08.10 12:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>На C++ это будет удобно (читай надо писать свой аллокатор)?

CC>>Да.
G>Ты все еще веришь что каждый программист на С++ способен написать аллокатор?
Я способен.
А ты веришь, что каждый программист может написать .NET runtime или .NET framework? Но кто то его написал а остальные пользуются.

G>>>Фактически это будет удобно только на С.

CC>>И С++
G>Не выдавай желаемое за действительное
Ты мне будешь рассказывать что и как в С++?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.08.10 12:32
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:


G>>>>На C++ это будет удобно (читай надо писать свой аллокатор)?

CC>>>Да.
G>>Ты все еще веришь что каждый программист на С++ способен написать аллокатор?
CC>Я способен.
CC>А ты веришь, что каждый программист может написать .NET runtime или .NET framework? Но кто то его написал а остальные пользуются.
Ты сравниваешь теплое с мягким, .NET FW — универсальное средство, а тут речь идет о специализированном аллокаторе на C++.

G>>>>Фактически это будет удобно только на С.

CC>>>И С++
G>>Не выдавай желаемое за действительное
CC> Ты мне будешь рассказывать что и как в С++?
Ты сам влез в разговор и пытаешь доказать непонятно что.
Я и так знаю что ты можешь написать аллокатор, и также знаю, что большая часть местных приплюснутых этого сделать не смогут.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 02.08.10 12:47
Оценка:
Здравствуйте, Klapaucius, Вы писали:


K>Это плохой код. Хорошая практика — это писать с использованием комбинаторов из стандартной библиотеки. Для ml-подобных языков правильным решением будет, например, такое
Автор:
Дата: 01.08.10
.

K>
K>xs |> Seq.pairwise |> Seq.forall (fun (a,b) -> a <= b)
K>


Конечно комбинаторы лучше особенно когда есть нужные, но если их нет чаще гораздо проще написать рекурсивный вариант, а не выкручиваться через ж. как в примерах выше. Хотя для данного случая конечно написать свой комбинатор тоже не сложно:

let rec pair_find f = function
  | a::b::t  -> if (f a b) then true else pair_find f (b::t)
  | _           -> false


let f l = pair_find (>) l |> not
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: SpaceConscience  
Дата: 02.08.10 20:58
Оценка:
FR>Ну и мирок твой куда-то в сторону перла вытягивается

Зачет-незачет. Мирок не мой, а ваш, профессор, и куда он там вытягивается, вам виднее.

(Чувство юмора не выдержало и с мрачным видом ушло курить трубку.)

This message was sent via the automatic space conscience delivery system. Please do not reply.
Собрался ставить минус? Да сам иди в жопу!

































































.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 02.08.10 21:29
Оценка:
Здравствуйте, SpaceConscience, Вы писали:

FR>>Ну и мирок твой куда-то в сторону перла вытягивается


SC>Зачет-незачет. Мирок не мой, а ваш, профессор, и куда он там вытягивается, вам виднее.


Сам ты нудный я еще шутник.
Re[16]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 04:44
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Здравствуйте, gandjustas, Вы писали:


G>>>Есть, как минимум в не-windows. Вообще это дико неудобно использовать будет.


PD>>Вполне удобно, поверь.


G>На C++ это будет удобно (читай надо писать свой аллокатор)?

G>На C# это будтет удобно?

Есть там поддержка mmf или нет ?

G>На java это будет удобно?


В яве поддержка mmf есть.

G>На python это будет удобно?


А это меня не интересует.

G>Фактически это будет удобно только на С.


G>Так что верить тебе у меня нет никаких оснований.


Не хочешь — не верь. Я на Яве такое писал.

G>>>А как я уже писал в этой теме — время работы программиста гораздо дороже времени работы компьютера.

PD>>Да, я помню про этот аргумент, обосновывающий халтуру.
G>Обоснуй сначала что это "халтура". Если заказчик доволен и разработчик получил бабло, то это самая обычная работа.

Сто раз обосновывал, поищи.

PD>>>>Но явно — не обязательно. Кстати, вроде бы как работу с mmf обещали поддерживать в .NET 4.0. Сделали ?

G>>>Сделали.

PD>>Так почему не использовать ?


G>Зачем?


With best regards
Pavel Dvorkin
Re[17]: Помогает ли Linq сделать код понятнее или быстрее?
От: MxMsk Португалия  
Дата: 03.08.10 05:46
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>На C# это будтет удобно?

PD>Есть там поддержка mmf или нет?
Да есть, есть: MemoryMappedFile Class.
Re[18]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 10:04
Оценка:
Здравствуйте, FR, Вы писали:


PD>>А это меня не интересует.


FR>Зря там очень хорошая поддержка mmf — http://docs.python.org/library/mmap.html


Что же, это хорошо и тогда тем более. Но поддержка mmf не может быть лучше чем в Win API — просто через него все идет. Судить, впрочем, не буду — не знаком с питоном.

FR>Тем более по скорости питон уже бьет и C++ и яву http://www.rsdn.ru/forum/flame.comp/3902202.flat.aspx#3902202
Автор: Mamut
Дата: 02.08.10


With best regards
Pavel Dvorkin
Re[18]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 10:07
Оценка:
Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, Pavel Dvorkin, Вы писали:


G>>>На C# это будтет удобно?

PD>>Есть там поддержка mmf или нет?
MM>Да есть, есть: MemoryMappedFile Class.

Ну вот и отлично. Хотя и забавная реализация — сделать полтора десятка overload методов на 2 функциях Win API — это уметь надо!
With best regards
Pavel Dvorkin
Re[19]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.08.10 10:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>>>Фактически это будет удобно только на С.

G>>>>Так что верить тебе у меня нет никаких оснований.
PD>>>Не хочешь — не верь. Я на Яве такое писал.
G>>Покажи код.

PD>Да бога ради. Только кое-что я выкинул, так что считай это только прототипом



PD>
PD>public class FileData {

PD>    private int records_number;
PD>    private long[] offsets;
PD>    private int[] lengths;
PD>    private RandomAccessFile raf;
PD>    private FileChannel channel;
PD>    MappedByteBuffer buffer;
PD>    public FileData(String filename) {
PD>            File file = new File(filename);
PD>            long fl = file.length();
PD>            raf = new RandomAccessFile(file, "r");
PD>            records_number = raf.readInt();
PD>            offsets = new long[records_number];
PD>            lengths = new int[records_number];
PD>            for (int i = 0; i < records_number; i++) {
PD>                offsets[i] = raf.readLong();
PD>                lengths[i] = raf.readInt();
PD>            }
PD>            channel = raf.getChannel();
PD>            buffer = channel.map(
PD>                    FileChannel.MapMode.READ_ONLY, 0, fl);

PD>    }

PD>


Ты уже забыл с чего начался разговор?
Итак есть потенциально бесконечный поток данных и надо его как-то обрабатывать.
Можно обрабатывать как последовательность (с помощью Linq), не сохраняя в памяти, потому что сохранять в памяти это лишние затраты.
Ты же сказал что можно зарезервить большой кусок и коммитить при необходимости для минимизации затрат (оставим обсуждение характеристик такого подхода за кадром). Это значит что надо все создаваемые объекты размещать в этой области.
Я же тебе сказал что это кроме как в C будет очень тяжело сделать. Ты начал спорить и привел не относящийся к делу кусок на java.

Кстати резерв большого куска и коммит по необходимости сродни работе GC.

G>>Моя конкретная мысль: исполнитель доволен, заказчик доволен — значит это была хорошая работа.


PD>Ну а моя конкретная мысль — если исполнитель доволен тем, что пользуясь некомпетентностью заказчика, всучил ему продукт низкого качества, и при этом заказчик доволен, так как не знает, какого качества тут можно достигнуть, если сделать как следует — это и есть халтура.


Вообще-то почти любой заказчик знает чего он хочет, особенно к концу проекта. Если он доволен, значит программма удовлетворяет его твребованиям качества. Если программа не удовлетворяет твоим требованиям качества, то это никого не волнует.
Re[22]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 11:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

<все skipped>

Извини, но дискуссию прекратил. Времени сейчас, увы нет, а дискутировать с тобой — его нужно много. А главное, это смысла не имеет.
With best regards
Pavel Dvorkin
Re[21]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 03.08.10 14:56
Оценка:
PD>Неспециалист в какой бы то ни было области не может знать, что в ней возможно. Он может лишь принимать то, что ему сделают специалисты или "специалисты". А когда таких "специалистов" много и все они делают одинаково "качественный" продукт — неспециалисту крайне трудно понять, что это халтура.

Неспециалисту очень легко понять, что то халтура. У нас заказчики просто оперируют понятиями «неудобно» и «медленно». Все. Этого достаточно


dmitriid.comGitHubLinkedIn
Re[20]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 15:34
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Ну вот и отлично. Хотя и забавная реализация — сделать полтора десятка overload методов на 2 функциях Win API — это уметь надо!


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


Я знаю. Просто забавно — сколько можно методов сделать на базе всего-то 2 функций.
With best regards
Pavel Dvorkin
Re[22]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 03.08.10 15:38
Оценка:
Здравствуйте, Mamut, Вы писали:



M>Неспециалисту очень легко понять, что то халтура. У нас заказчики просто оперируют понятиями «неудобно» и «медленно». Все. Этого достаточно


Неудобно — с этим, пожалуй, еще и соглашусь.
А вот "медленно" — очень сильно зависит от того, что делаем. Если время операции доли секунды, то заказчик просто не в состоянии сказать, медленно это или нет. Да и не важно в этом случае. А вот если время операции равно 5 секундам или 5 минутам — это медленно или нет ? Это в зависимости от задачи может быть и очень долго и очень медленно, и никакой заказчик не сможет это определить правильно.
With best regards
Pavel Dvorkin
Re[23]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 06:00
Оценка:
M>>Неспециалисту очень легко понять, что то халтура. У нас заказчики просто оперируют понятиями «неудобно» и «медленно». Все. Этого достаточно

PD>Неудобно — с этим, пожалуй, еще и соглашусь.

PD>А вот "медленно" — очень сильно зависит от того, что делаем. Если время операции доли секунды, то заказчик просто не в состоянии сказать, медленно это или нет. Да и не важно в этом случае.

Вот именно Думаю, к этому и клонит gandjustas

PD>А вот если время операции равно 5 секундам или 5 минутам — это медленно или нет ? Это в зависимости от задачи может быть и очень долго и очень медленно, и никакой заказчик не сможет это определить правильно.


Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд, для внутренней софтины — не более 3-4 секунд. Все, что больше этого времени, для заказачика попадает в категорию «медленно».


dmitriid.comGitHubLinkedIn
Re[24]: Помогает ли Linq сделать код понятнее или быстрее?
От: hattab  
Дата: 04.08.10 06:43
Оценка:
Здравствуйте, Mamut, Вы писали:

M> PD>А вот если время операции равно 5 секундам или 5 минутам — это медленно или нет ? Это в зависимости от задачи может быть и очень долго и очень медленно, и никакой заказчик не сможет это определить правильно.


M> Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд, для внутренней софтины — не более 3-4 секунд. Все, что больше этого времени, для заказачика попадает в категорию «медленно».


Ну заказчика можно еще и убедить, если умело языком чесать В моей практике было два наиболее ярких случая, когда исполнители работавшие до меня умело объясняли заказчику, что низкое быстродействие, в первом случае, и практическая невозможность решения во втором, является следствием сложности решаемых задач.
avalon 1.0rc3 rev 345, zlib 1.2.3
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 07:04
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, 0K, Вы писали:


0K>>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


Кэр>Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.


Да ну?

Сделай Select, SelectMany и Where без Linq.

Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.

Кэр>Конкретно для этой задачи использовать Linq — не очень ясно зачем надо.

Очень ясно. Нормальное определение упорядоченности массива на Linq

seq.PairwiseBy((a,b) => a<b).All()

По русски читать в обратном порядке: "Все пары последовательных элементов такие что первый элемент меньше второго".
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 07:45
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, gandjustas, Вы писали:


0K>>>>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


Кэр>>>Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.


G>>Да ну?

G>>Сделай Select, SelectMany и Where без Linq.

Кэр>Что ну? Здесь порождение новой коллекции. Linq в таких случаях экономит промежуточные/результирующие переменные коллекции — крайне удобно. Для простого перебора это не важно.


Так простой перебор и встречается крайне редко, поэтому так много всяких функций в linq.


G>>Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.


Кэр>Foreach дает перебор ленивой бесконечной коллекции.


И что?

G>>
G>>seq.PairwiseBy((a,b) => a<b).All()
G>>

G>>По русски читать в обратном порядке: "Все пары последовательных элементов такие что первый элемент меньше второго".

Кэр>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.


Простейший цикл гораздо сложнее, больше и гораздо хуже читается. Ему еще больше инструкция нужна для чтения, чем двум вызовам функций.
Re[24]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 08:08
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,


Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?
With best regards
Pavel Dvorkin
Re[23]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 04.08.10 08:09
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.


Извини, но я здесь никаких контраргументов не вижу. Вижу только декларативное заявление.
With best regards
Pavel Dvorkin
Re[23]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 04.08.10 08:11
Оценка:
Здравствуйте, gandjustas, Вы писали:

<все skipped>

Я тебе уже сказал — у меня нет желания с тобой дискутировать, и объяснил почему.
With best regards
Pavel Dvorkin
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: Klapaucius  
Дата: 04.08.10 09:03
Оценка:
Здравствуйте, FR, Вы писали:

FR>Конечно комбинаторы лучше особенно когда есть нужные, но если их нет чаще гораздо проще написать рекурсивный вариант, а не выкручиваться через ж. как в примерах выше. Хотя для данного случая конечно написать свой комбинатор тоже не сложно:


Если возникают сложности как в примерах выше — это просто признак того, что в библиотеке нет какого-то комбинатора. В данном случае функции, работающей с соседними элементами в последовательности. В таких случаях и следует написать недостающий комбинатор, который потом еще и не раз пригодится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 09:04
Оценка:
Здравствуйте, vitasR, Вы писали:

R>тупое суммирование массива из 30,000,000 doubles.


R>LINQ Sum: 915 ms

R>обычный цикл: 134 ms
R>C++ : 61 ms

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


R>
R>        private const int N = 30000000;
R>        static void Main(string[] args)
R>        {

R>            var ba = new double[N];
R>            for (int i = 0; i < N; i++)
R>                ba[i] = i*i;

R>            double sum = 0;
R>            DateTime t0 = DateTime.Now;
R>            for (int i = 0; i < N; i++)
R>                sum += ba[i];
R>            DateTime t1 = DateTime.Now;
R>            Console.WriteLine("{0} {1}", sum, t1-t0);

R>            t0 = DateTime.Now;
R>            double sum2 = ba.Sum(item => item);
R>            t1 = DateTime.Now;
R>            Console.WriteLine("{0} {1}", sum, t1 - t0);
R>        }

R>


Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: yoriсk.kiev.ua  
Дата: 04.08.10 09:45
Оценка:
Здравствуйте, vitasR, Вы писали:

R>
R>            Console.WriteLine("{0} {1}", sum, t1-t0);
R>            t0 = DateTime.Now;
R>            double sum2 = ba.Sum(item => item);
R>            t1 = DateTime.Now;
R>            Console.WriteLine("{0} {1}", sum, t1 - t0);
R>


И результаты суммирования всегда совпадают... Но это так, к слову.
Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 11:08
Оценка:
M>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,

PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


Никто не внушал. Это то время, на которое он, как заказчик, согласен. Не мы это время ему внушали Если будет 0.1 сек — он только будет рад.


dmitriid.comGitHubLinkedIn
Re[24]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 11:12
Оценка:
M>>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.
CC>Софт написанный студентами левой ногой на подпорках тоже может решать проблемы заказчика. Вот только хорошим его назвать трудно.

По каким критериям?

С точки зрения специалиста: сортировка пузырьком — это плохо, в студенческой левопяточной программе она есть, программа плохая.
С точки зрения заказчика: программа работает в пределах требуемых 0.5 секунд и обрабатывает данные так, как надо. Программа хорошая.

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


dmitriid.comGitHubLinkedIn
Re[24]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 11:18
Оценка:
M>>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.

PD>Извини, но я здесь никаких контраргументов не вижу. Вижу только декларативное заявление.


Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта


dmitriid.comGitHubLinkedIn
Re[25]: пояснение о качестве
От: 24  
Дата: 04.08.10 11:20
Оценка:
Здравствуйте, Cadet, Вы писали:
C>Если вдруг понадобилось обновлять софт, но он написан абы как, и за его модификацию надо много платить — это плохой софт с точки зрения поддержки.
А за поддержку кто платить будет? Заказчик. Значит в таком случае это плохая программа с точки зрения заказчика.
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 11:38
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, gandjustas, Вы писали:


K>
K>double sum2 = ba.Sum(item => item);
K>


G>>Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length


K>Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?


Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 12:10
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


Угу, который может пригодится, а может и не пригодится
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 12:23
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.


a, b = 1, 1

while True:
    process(a, b)
    a, b = b, a + b
    if is_exit():
        break


Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 12:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


Тут большое значение имеют и трудозатраты на получение этих 0.1 секунд. Если это стоит в 10 или 100 раз дороже любой заказчик трижды подумает надо ли оно ему.
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 12:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length


Он просто мало флеймов читал, на rsdn все плюсисты уже в курсе
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: Klapaucius  
Дата: 04.08.10 12:39
Оценка:
Здравствуйте, FR, Вы писали:

FR>Угу, который может пригодится, а может и не пригодится


Тут надо ориентироваться по обстоятельствам. К примеру, если на горизонте видно грибовидное облако атомного взрыва, то повторно использовать код, вероятнее всего, не удастся.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 12:56
Оценка:
Здравствуйте, Klapaucius, Вы писали:


K>Тут надо ориентироваться по обстоятельствам. К примеру, если на горизонте видно грибовидное облако атомного взрыва, то повторно использовать код, вероятнее всего, не удастся.


Это как повезет http://www.vesti.ru/doc.html?id=334530
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: anton_t Россия  
Дата: 04.08.10 13:42
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, vitasR, Вы писали:


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


0K>Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?


Упорядоченный массив — это массив, в котором все элементы расположены по порядку. Очевидно, что для пустого массива это выполняется.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: anton_t Россия  
Дата: 04.08.10 13:43
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, gandjustas, Вы писали:


G>>Это ты где такую шутку прочитал?

G>>99% данных обычно программа получает извне.

0K>Ну да, и записывает их в ОЗУ. А раз в ОЗУ, то лучше массив.


Даже если это zip-файл размером пару гигабайт?
Re[26]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 14:53
Оценка:
Здравствуйте, fmiracle, Вы писали:

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


Категорически не согласен. Если это так, то это скорее означает, что неправильно оценен бюджет, а вовсе не то, что скорость обусловлена сложностью. Увеличьте бюджет, наймите вместо поденщиков хороших специалистов, и они справятся с этой сложностью без проблем. Это сложность не задачи, а сложность для тех "специалистов", которые ее грамотно решать не умеют. Ну что же, хотели "числом поболее, ценю подешевле" — получайте свою халтуру, за эти деньги вы ничего иного и не получите.

F>При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.


Он далеко не всегда применим. У меня, к примеру, нет сайтов, нет пользователей и нет никакого отклика в обычном понимании этого слова.
With best regards
Pavel Dvorkin
Re[26]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 14:59
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?


FR>Тут большое значение имеют и трудозатраты на получение этих 0.1 секунд. Если это стоит в 10 или 100 раз дороже любой заказчик трижды подумает надо ли оно ему.


Верно. Но не надо этот продукт считать качественным. Надо просто сказать — за эти деньги мы вам слепили халтуру, хотите качество — платите. За определенную сумму можно построить завод по производству Запорожцев, но если вы хотите выпускать мерседесы — выложите иную сумму.
With best regards
Pavel Dvorkin
Re[26]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 15:12
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это не вылезает за пределы того что он видит на других сайтах.


G>Есть же давно известное правило.

G>До 0.1 секунды для пользователя "моментально", до 1 секунды "быстро", до 10 секунд "приемлемо". Причем касается реакции интерфейса, а не времени выполнения работы. Если интерфейс умудряется фибдбэчить каждую секунду, то и минута покажется пользователю приемлемым временем работы.

Слушай, ты вообще хоть понимаешь, что сайты — это лишь небольшая часть программного обеспечения ?
With best regards
Pavel Dvorkin
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 15:22
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

FR>>Тут большое значение имеют и трудозатраты на получение этих 0.1 секунд. Если это стоит в 10 или 100 раз дороже любой заказчик трижды подумает надо ли оно ему.


PD>Верно. Но не надо этот продукт считать качественным. Надо просто сказать — за эти деньги мы вам слепили халтуру, хотите качество — платите. За определенную сумму можно построить завод по производству Запорожцев, но если вы хотите выпускать мерседесы — выложите иную сумму.


Все таки ты путаешь быстродействие с качеством.
Никому ни нужны сверхзвуковые рейсовые городские автобусы.
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 15:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?


Прошло пять лет, та 10 секундная версия которую написал Mamut на своем любимом эрланге на новых 80 ядерных процессорах отрабатывает за 0.0001, а твоя только за 0.01 так как не умеет так хорошо параллелится, как качество будем мерять? Кусочно-линейной функцией?
Re[28]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 15:31
Оценка:
Здравствуйте, FR, Вы писали:

FR>Все таки ты путаешь быстродействие с качеством.


Нет, я просто примел быстродействие как пример. Не нравится — изволь, заменю. Качество интерфейса — можно же сделать "красиво", а можно "тяп-ляп" при том, что функциональность будет соблюдена в обоих случаях. Объем требуемой памяти. И т.д.
With best regards
Pavel Dvorkin
Re[28]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 15:34
Оценка:
Здравствуйте, FR, Вы писали:

FR>Прошло пять лет, та 10 секундная версия которую написал Mamut на своем любимом эрланге на новых 80 ядерных процессорах отрабатывает за 0.0001, а твоя только за 0.01 так как не умеет так хорошо параллелится


Так, мы что-то на иную тему переходим. Какое отношение все это имеет к качеству как я его обсуждаю? Может, Mamut уже сейчас сделал лучше меня хоть на Эрланге, хоть на чем-то еще. Может, я сделал лучше на веки вечные — распараллеливать я все же умею, почему ты решил, что не умею — не знаю. Но все это не имеет отношения к теме, которую я поднял. Поэтому извини, но эту ветку со своей стороны закрываю.
With best regards
Pavel Dvorkin
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 15:37
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:


G>>Это не вылезает за пределы того что он видит на других сайтах.


G>>Есть же давно известное правило.

G>>До 0.1 секунды для пользователя "моментально", до 1 секунды "быстро", до 10 секунд "приемлемо". Причем касается реакции интерфейса, а не времени выполнения работы. Если интерфейс умудряется фибдбэчить каждую секунду, то и минута покажется пользователю приемлемым временем работы.

PD>Слушай, ты вообще хоть понимаешь, что сайты — это лишь небольшая часть программного обеспечения ?


Разговор вообще-то именно о сайте шел.

Ты опять не следишь о чем разговор идет?
Re[28]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 15:41
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Разговор вообще-то именно о сайте шел.


G>Ты опять не следишь о чем разговор идет?


Разговор, как я его в ветке о качестве веду, никакого отношения к сайтам не имеет. В сообщении ТС — тоже. Следить за всей сотней сообщений в этом треде и считать статистику я не намерен.
With best regards
Pavel Dvorkin
Re[29]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 15:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:


G>>Разговор вообще-то именно о сайте шел.


G>>Ты опять не следишь о чем разговор идет?


PD>Разговор, как я его в ветке о качестве веду, никакого отношения к сайтам не имеет. В сообщении ТС — тоже. Следить за всей сотней сообщений в этом треде и считать статистику я не намерен.


Ровно на одну строчку вышек процитированного тобой сообщения

M>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,


И это не я написал, а Mamut.

Если ты не читаешь, то лучше не пиши.
Re[26]: пояснение о качестве
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 15:50
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Mamut, Вы писали:


M>>Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта


PD>Извини, но я привел тебе ряд примеров — мост, банк, мороженое. Возражений на эти примеры я не услышал. Могу еще десяток привести. А если эти примеры принимаются, то почему в ИТ все иначе ? Только, пожалуйста, без ссылок на особый путь России


Опять не читаешь?
Возражение на твои примеры ровно одно — они не учитывают мнение потребителей, которых нужна как минимум репрезентативная выборка для массовых продуктов, а ты приводишь только свое личное мнение.
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 15:53
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

F>>При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.


PD>Он далеко не всегда применим. У меня, к примеру, нет сайтов, нет пользователей и нет никакого отклика в обычном понимании этого слова.


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

Оптимизировать все подряд никто в здравом уме не станет.
Re[30]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 15:55
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>Ровно на одну строчку вышек процитированного тобой сообщения

G>

M>>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,


G>И это не я написал, а Mamut.


Уф! Mamut привел свой аргумент. Я свой. Он в качестве примера привел сайт. Я ему ответил без ссылок на сайт. Мы с ним обсуждаем проблему в целом, а вовсе не сайты, как легко понять.

G>Если ты не читаешь, то лучше не пиши.


Если ты это не понимаешь, то лучше не встревай. С Mamut мы как-нибудь все сами обсудим.
With best regards
Pavel Dvorkin
Re[29]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 16:12
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

FR>>Все таки ты путаешь быстродействие с качеством.


PD>Нет, я просто примел быстродействие как пример. Не нравится — изволь, заменю. Качество интерфейса — можно же сделать "красиво", а можно "тяп-ляп" при том, что функциональность будет соблюдена в обоих случаях. Объем требуемой памяти. И т.д.


Хорошо.
Но реальность такова что идеального качества достигнуть невозможно, всегда будет компромисс.
И опять по отдельным параметрам типа скорости или интерфейса вообще в большинстве случаев невозможно определить халтура
перед тобой или нет.
Re[29]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 04.08.10 16:14
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

FR>>Прошло пять лет, та 10 секундная версия которую написал Mamut на своем любимом эрланге на новых 80 ядерных процессорах отрабатывает за 0.0001, а твоя только за 0.01 так как не умеет так хорошо параллелится


PD>Так, мы что-то на иную тему переходим. Какое отношение все это имеет к качеству как я его обсуждаю? Может, Mamut уже сейчас сделал лучше меня хоть на Эрланге, хоть на чем-то еще. Может, я сделал лучше на веки вечные — распараллеливать я все же умею, почему ты решил, что не умею — не знаю. Но все это не имеет отношения к теме, которую я поднял. Поэтому извини, но эту ветку со своей стороны закрываю.


Я не имел в виду лично тебя и Мамута, это чисто гипотетически.
А мораль такая что не однозначно все даже без учета будущего.
Re[30]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 04.08.10 16:31
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я не имел в виду лично тебя и Мамута, это чисто гипотетически.


Я понял, но не хочу это направление продолжать.
With best regards
Pavel Dvorkin
Re[26]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 18:26
Оценка:
M>>Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта

PD>Извини, но я привел тебе ряд примеров — мост, банк, мороженое. Возражений на эти примеры я не услышал. Могу еще десяток привести. А если эти примеры принимаются, то почему в ИТ все иначе ? Только, пожалуйста, без ссылок на особый путь России



Да не особо-то они и принимаются

Серовакуумное мнение сферовакуумных специалистов никому даром не нужно.


dmitriid.comGitHubLinkedIn
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.10 18:33
Оценка:
R>тупое суммирование массива из 30,000,000 doubles.

R>LINQ Sum: 915 ms

R>обычный цикл: 134 ms
R>C++ : 61 ms

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

В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?


dmitriid.comGitHubLinkedIn
Re[27]: Помогает ли Linq сделать код понятнее или быстрее?
От: fmiracle  
Дата: 04.08.10 18:57
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>Категорически не согласен. Если это так, то это скорее означает, что неправильно оценен бюджет, а вовсе не то, что скорость обусловлена сложностью. Увеличьте бюджет, наймите вместо поденщиков хороших специалистов, и они справятся с этой сложностью без проблем. Это сложность не задачи, а сложность для тех "специалистов", которые ее грамотно решать не умеют. Ну что же, хотели "числом поболее, ценю подешевле" — получайте свою халтуру, за эти деньги вы ничего иного и не получите.


А, ну если деньги бесконечные, то да. У меня, к сожалению, не такой случай

Кстати, не оставишь адресок бесконечной тумбочки с деньгами? С ней-то действительно — количество сложных задач резко сократится, и проблемными останутся только теоретически нерешенные или ограниченные мощностью самого производительного железа. А то и, глядишь, и мировой уровень технологии подтянем, с такими-то ресурсами.

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

F>При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.

PD>Он далеко не всегда применим. У меня, к примеру, нет сайтов, нет пользователей и нет никакого отклика в обычном понимании этого слова.

Ты ж не дурак, так и не надо из себя его строить — никто не поверит.
Все равно для твоей задачи можно описать, какое время обработки (как пример, точно так же про все другие аспекты работы приложения) будет признано приемлимым. Если такого нет, и всегда надо "еще меньше" — то и нет возможности такую работу сдать заказчику (а как же так, у вас образ распознается за 0.00001 сек, а ведь наверняка можно и быстрее!? нет, я такую халтуру не приму!). Единственный способ сдать работу в таких условиях — это уговорить заказчика что все круто и круче быть не может (а то как же — mmf используется или еще какое умное слово, и вообще я авторитет и специалист, а ты кто такой, обычный пользователь, не тебе оценивать труд специалиста).
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.08.10 20:20
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, gandjustas, Вы писали:


Кэр>>>Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.

G>>Это потому что ты Linq не понимаешь, а циклы понимаешь.

Кэр>Ну конечно же все именно так просто. Все дело не в том, что код получается на ровном месте переусложненный с дополнительными зависимостями.

Где ты увидел дополнительные зависимости в двух вызовах функций.

G>>Для человека, который одинаково понимает (не понимает) и то и другое, linq будет проще.


Кэр>Я человек, который понимает и то, и другое — и я утверждаю, что пример с linq и сложнее, и хуже по целому ряду критериев.


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

Кэр>>>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?

G>>Цикл требует того же самого.

Кэр>Цикл не прячет это знание в библиотечной функции. Эта функция обладает вполне конкретным поведением, которое надо сначала изучить, а потом гарантировать неизменность.

Циклы тоже требуют изучение. Я же говорю что в случае одинакового знания\незнания linq проще.
При этом для понимания linq не требуется изучать реализацию. Хватит сигнатуры краткого словесного описания.

G>>Ты сначала для себя определи будет ли упорядоченным пустой массив и из одного элемента.

Кэр>Для какого начала? Чтобы общаться с вашим высоким просвященным высочеством?
Нет, чтобы писать проверку на упорядоченность.

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

G>>А чего ты пытаешься требовать знание как пишется for и думать с чего начинается индексация массива, и как вообще получить длину массива,
Кэр>Это базовые навыки, которые шаряться между различными языками. Keep things as simple as possible.

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

G>>а если там не массив, а IEnumerable<T>?

Кэр>То будет foreach вместо for.
Учитывая что массив реализует IEnumerable<T>, то что является более "базовым" всетаки for или foreach?

А потом вспомним про ленивость и окажется что комбинаторы и итераторы являются самыми базовыми.
Re[28]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 05.08.10 04:36
Оценка:
Здравствуйте, Mamut, Вы писали:

PD>>И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?


M>Вообще-то, пофиг, что я считаю. Заказчик просто получит более качественный продукт. Мое мнение вообще не играет роли.


Мы же обсуждаем вопрос. Я высказал свое мнение, а ты уходишь от ответа

PD>>Понимаешь, вот ты пишешь "Это то время, на которое он, как заказчик, согласен". Верно. Не вы внушали. Тоже верно. Просто, исходя из общего уровня и не знаю чего еще он пришел к выводу, что здесь быстрее чем в 5 сек не уложишься. А оказывается, можно в 0.1 сек уложиться. Вот поэтому я и говорю, что мнение заказчика — не аргумент.. Он не в состоянии оценить, с какой это скоростью можно технически сделать. Только специалист может оценить и сказать — если вы (опять же не о вас речь, конечно) складываете 2 матрицы размером 100*100 за 1 сек, то не морочьте мне голову , потому что такие скорости надо было в досовские времена демонстрировать, а сейчас это халтура.


M>А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.


Опять то же. А если заказчик не дает пенделя или (что более вероятно) ему это показывать — все равно что показывать неандертальцу ракетный двигатель, а там халтура очевидная внутри — ты все равно считаешь этот продукт качественным ?
With best regards
Pavel Dvorkin
Re[27]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 04:42
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта


PD>>Извини, но я привел тебе ряд примеров — мост, банк, мороженое. Возражений на эти примеры я не услышал. Могу еще десяток привести. А если эти примеры принимаются, то почему в ИТ все иначе ? Только, пожалуйста, без ссылок на особый путь России



M>Да не особо-то они и принимаются


Тогда приведи контраргументы. Я их не увидел и не услышал.

M>Серовакуумное мнение сферовакуумных специалистов никому даром не нужно.


Ну на тебе развернутое изложение одного из примеров.

Купил я мороженое и съел. Не отравился. Показалось вкусным. Я , пользователь, доволен. Это качественное мороженое ?

Черт его знает. Может, в нем вместо молока какая-то дрянь, а вместо масла — пальмовый жир. Может, в нем конесерванты такие, что лучше бы их не было. Может, там добавки не очень хорошие. Может, у него консистенция не та, а мой грубый вкус этого не улавливает. Может... додумай сам.

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

Это , надеюсь, уже не сферовакумный конь ?
With best regards
Pavel Dvorkin
Re[28]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 05.08.10 04:48
Оценка:
Здравствуйте, fmiracle, Вы писали:

PD>>Категорически не согласен. Если это так, то это скорее означает, что неправильно оценен бюджет, а вовсе не то, что скорость обусловлена сложностью. Увеличьте бюджет, наймите вместо поденщиков хороших специалистов, и они справятся с этой сложностью без проблем. Это сложность не задачи, а сложность для тех "специалистов", которые ее грамотно решать не умеют. Ну что же, хотели "числом поболее, ценю подешевле" — получайте свою халтуру, за эти деньги вы ничего иного и не получите.


F>А, ну если деньги бесконечные, то да. У меня, к сожалению, не такой случай


Не обязательно бесконечные.

F>Кстати, не оставишь адресок бесконечной тумбочки с деньгами?


Пожалуйста

http://www.cbr.ru/

Потенциально бесконечная. Правда, дадут ли тебе из этой тумбочки — сомневаюсь.

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


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

F>>При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.

PD>>Он далеко не всегда применим. У меня, к примеру, нет сайтов, нет пользователей и нет никакого отклика в обычном понимании этого слова.

F>Ты ж не дурак, так и не надо из себя его строить — никто не поверит.


Тебе не кажется, чт аргументы такого рода едва ли приличны в дискуссии ? И едва ли они приведут, что я захочу ее продолжать.
With best regards
Pavel Dvorkin
Re[28]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 05:50
Оценка:
PD>Купил я мороженое и съел. Не отравился. Показалось вкусным. Я , пользователь, доволен. Это качественное мороженое ?

PD>Черт его знает. Может, в нем вместо молока какая-то дрянь, а вместо масла — пальмовый жир. Может, в нем конесерванты такие, что лучше бы их не было. Может, там добавки не очень хорошие. Может, у него консистенция не та, а мой грубый вкус этого не улавливает. Может... додумай сам.


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


PD>Это , надеюсь, уже не сферовакумный конь ?


Я на это уже ответил

сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.


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


dmitriid.comGitHubLinkedIn
Re[29]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 06:42
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тогда тебе надо новый раздел в математике завести — сложность задач как функция выделяемых на их решение средств. Правда, один Перельман разрушит все теории такого рода


Это не в математике, а в управлении проектами. И такой раздел давным давно существует.
Re[30]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 05.08.10 06:46
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.


PD>>Опять то же. А если заказчик не дает пенделя или (что более вероятно) ему это показывать — все равно что показывать неандертальцу ракетный двигатель, а там халтура очевидная внутри — ты все равно считаешь этот продукт качественным ?


M>Критерий вычисления халтуры ровно один: работает программа в рамках, поставленных заказчиком, или не работает. Технический аспект реализации вообще никого не волнует. Ну, кроме перфекционистов, естественно


Пора заканчивать. Увы. я надеялся от тебя какие-то аргументы получить или возражения на мои замечания. А вижу лишь декларации — это так, потому что это так.
With best regards
Pavel Dvorkin
Re[29]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 06:54
Оценка:
Здравствуйте, Mamut, Вы писали:


PD>>Черт его знает. Может, в нем вместо молока какая-то дрянь, а вместо масла — пальмовый жир. Может, в нем конесерванты такие, что лучше бы их не было. Может, там добавки не очень хорошие. Может, у него консистенция не та, а мой грубый вкус этого не улавливает. Может... додумай сам.


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


PD>>Это , надеюсь, уже не сферовакумный конь ?


M>Я на это уже ответил

M>

M>сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.


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


Почему не говорят, именно говорят. Я же сказал — одна омская газета этим занимается, привлекает экспертов и печатает их заключения. Можно считать, что они рекомендуют продукты, занявшие 1-2 место (обычно их рассматривается 5-6) и наоборот, не рекомендуют аутсайдеров. Я к их мнению прислушиваюсь, к примеру.
Так что нет здесь никакой сферовакуумности. Есть вполне конкретный пример, когда мнение специалистов о том, качественное мороженое или нет, существенно, а мое как потребителя — существенно, только если я им недоволен (вот тут да, не нравится мне это мороженое, и плевать мне на все мнения всех экспертов и производителя вместе с ними), и не существенно, если оно мне нравится. Скажу точнее — не то, чтобы вообще не существенно, но явно недостаточно, чтобы судить о его качестве.

Возрази на мой последний абзац. Только без ссылок на коней и вакуум, пожалуйста
With best regards
Pavel Dvorkin
Re: Помогает ли Linq сделать код понятнее или быстрее?
От: midcyber
Дата: 05.08.10 07:26
Оценка:
Здравствуйте, 0K, Вы писали:

0K>По мотивам: http://rsdn.ru/forum/dotnet/3900028.flat.aspx
Автор: Dog
Дата: 30.07.10


0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.


0K>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?


Некорректная задача, для студента или с собеседования. Правильно:
1) либо нам нужно получить на выходе отсортированный массив. Тогда сортировать каждый раз будет быстрее, чем проверять, нужна ли сортировка.
2) если так волнует производительность, надо вставлять данные в упорядоченные списки на этапе пользовательского ввода.

P.S. Господа КСВшники, ну право стыдно, надо сразу в эту сторону дискуссию уводить.
Re[2]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 07:45
Оценка:
Здравствуйте, midcyber, Вы писали:

M>Некорректная задача, для студента или с собеседования. Правильно:


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

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


Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 07:50
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, midcyber, Вы писали:


M>>Некорректная задача, для студента или с собеседования. Правильно:

FR>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.

Я вот честно не сталкивался с такими задачами.
Зачем проверять упорядоченность? Если окажется неупорядоченным что потом делать?

Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.

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

FR>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
Быстрая сортировка упорядоченного массива — тоже один проход
Re[4]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 08:35
Оценка:
Здравствуйте, gandjustas, Вы писали:

FR>>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.


G>Я вот честно не сталкивался с такими задачами.

G>Зачем проверять упорядоченность? Если окажется неупорядоченным что потом делать?

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

G>Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.


Ну это и циклом не сложно.

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

FR>>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
G>Быстрая сортировка упорядоченного массива — тоже один проход

Угу классическим qsort с самым примитивным выбором медианы
Re[30]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 08:42
Оценка:
M>>Я на это уже ответил
M>>

M>>сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.


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


PD>Почему не говорят, именно говорят. Я же сказал — одна омская газета этим занимается, привлекает экспертов и печатает их заключения. Можно считать, что они рекомендуют продукты, занявшие 1-2 место (обычно их рассматривается 5-6) и наоборот, не рекомендуют аутсайдеров. Я к их мнению прислушиваюсь, к примеру.


Теперь перечитай то, что я процитировал. Это то же самое. В итоге все упирается в выбор пользователя/заказчика и т.п.


PD>Так что нет здесь никакой сферовакуумности. Есть вполне конкретный пример, когда мнение специалистов о том, качественное мороженое или нет, существенно, а мое как потребителя — существенно, только если я им недоволен (вот тут да, не нравится мне это мороженое, и плевать мне на все мнения всех экспертов и производителя вместе с ними), и не существенно, если оно мне нравится. Скажу точнее — не то, чтобы вообще не существенно, но явно недостаточно, чтобы судить о его качестве.


PD>Возрази на мой последний абзац. Только без ссылок на коней и вакуум, пожалуйста


Я, вообще-то, уже два раза процитировал, а ты только мои слова подтвердил. Мнение специалиста никому не нужно, пока это мнение не донесено до потребителя в стиле «у нас есть три продукта, они отличаются друг от друга по следующим критериям. Выбор за вами».

В итоге именно потребитель определяет то, что ему нужно и то, что является хорошим продуктом для него, как потребителя.


dmitriid.comGitHubLinkedIn
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 08:44
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:


FR>>>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.


G>>Я вот честно не сталкивался с такими задачами.

G>>Зачем проверять упорядоченность? Если окажется неупорядоченным что потом делать?

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

Ну приведи конкретный пример. Я не могу вспомнить ни одной проверки на упорядоченность, которая понадобилась бы хоть в одном проекте.

Или хотя бы мысли где такая проверка может понадобится?

G>>Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.

FR>Ну это и циклом не сложно.
linq выйграет в читабельности.

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

FR>>>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
G>>Быстрая сортировка упорядоченного массива — тоже один проход

FR>Угу классическим qsort с самым примитивным выбором медианы


new[] { 1, 2, 3, 4 }.Do(Console.Write).OrderBy(x => x).Run();

выводит
1234
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 08:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>
G>new[] { 1, 2, 3, 4 }.Do(Console.Write).OrderBy(x => x).Run();
G>

G>выводит
G>
G>1234
G>


Хотя туплю, он же не будет дважды по одному итератору бегать
Re[31]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 09:16
Оценка:
Здравствуйте, Mamut, Вы писали:

PD>>Почему не говорят, именно говорят. Я же сказал — одна омская газета этим занимается, привлекает экспертов и печатает их заключения. Можно считать, что они рекомендуют продукты, занявшие 1-2 место (обычно их рассматривается 5-6) и наоборот, не рекомендуют аутсайдеров. Я к их мнению прислушиваюсь, к примеру.


M>Теперь перечитай то, что я процитировал. Это то же самое. В итоге все упирается в выбор пользователя/заказчика и т.п.


Все это слова. Я привел реальный пример, когда именно мнение специалиста и только оно может быть определяющим.


PD>>Так что нет здесь никакой сферовакуумности. Есть вполне конкретный пример, когда мнение специалистов о том, качественное мороженое или нет, существенно, а мое как потребителя — существенно, только если я им недоволен (вот тут да, не нравится мне это мороженое, и плевать мне на все мнения всех экспертов и производителя вместе с ними), и не существенно, если оно мне нравится. Скажу точнее — не то, чтобы вообще не существенно, но явно недостаточно, чтобы судить о его качестве.


PD>>Возрази на мой последний абзац. Только без ссылок на коней и вакуум, пожалуйста


M>Я, вообще-то, уже два раза процитировал, а ты только мои слова подтвердил. Мнение специалиста никому не нужно, пока это мнение не донесено до потребителя в стиле «у нас есть три продукта, они отличаются друг от друга по следующим критериям. Выбор за вами».


Я с этим не вполне согласен (это мнение в плане мороженого может быть очень важным для санэпидстанции, потому что продукт, например, надо срочно с продажи снимать и конечных пользователей к нему близко не подпускать), но допустим, что это так. Пусть мнение специалистов о качестве должно быть потом доведено до пользователя и он должен решать, что выбрать. Ну и что ? Это не отменяет моей посылки — судить может только специалист, пользователь потом может его выводам верить или не верить, но не судить.

M>В итоге именно потребитель определяет то, что ему нужно и то, что является хорошим продуктом для него, как потребителя.


Я не вижу аргументов. Я вижу только декларативные заявления, вроде того, что это так, потому что это так.

Хорошо, поставлю вопрс прямо.

Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!
With best regards
Pavel Dvorkin
Re[21]: Помогает ли Linq сделать код понятнее или быстрее?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.08.10 09:51
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ох! Ну когда вы наконец поймете, что Ваш linq строит промежуточные структуры, которые вы не видите, и они занимают место. Чудес не бывает.


В общем случае можно считать, что этих структур нет. Вот для сортировки и некоторых других операций, придется выделить память равную размеру массива.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 09:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Или хотя бы мысли где такая проверка может понадобится?


В юнит тесте алгоритма сортировки

G>>>Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.

FR>>Ну это и циклом не сложно.
G>linq выйграет в читабельности.

Не факт

FR>>Угу классическим qsort с самым примитивным выбором медианы


G>
G>new[] { 1, 2, 3, 4 }.Do(Console.Write).OrderBy(x => x).Run();
G>

G>выводит
G>
G>1234
G>


Мы похоже по разному понимаем один проход.
Я имел в виду алгоритмическую сложность которая у сортировки существенно выше чем у линейного поиска.
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 09:58
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:


G>>Или хотя бы мысли где такая проверка может понадобится?


FR>В юнит тесте алгоритма сортировки


Зачем? Можно просто сравнить с эталоном.

FR>Мы похоже по разному понимаем один проход.

FR>Я имел в виду алгоритмическую сложность которая у сортировки существенно выше чем у линейного поиска.
Алгоритмическая сложность у нормального алгоритма быстрой сортировки такая же линейная, как у проверки на упорядоченность.
Re[22]: Помогает ли Linq сделать код понятнее или быстрее?
От: Pavel Dvorkin Россия  
Дата: 05.08.10 10:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:


PD>>Ох! Ну когда вы наконец поймете, что Ваш linq строит промежуточные структуры, которые вы не видите, и они занимают место. Чудес не бывает.


I>В общем случае можно считать, что этих структур нет.


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

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


Сортировка испокон веков принимается только в версии , когда дополнительная память не более O(log N).
With best regards
Pavel Dvorkin
Re[8]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 10:33
Оценка:
Здравствуйте, gandjustas, Вы писали:

FR>>В юнит тесте алгоритма сортировки


G>Зачем? Можно просто сравнить с эталоном.


Нельзя, задолбаешся три миллиона цифр вводить

FR>>Мы похоже по разному понимаем один проход.

FR>>Я имел в виду алгоритмическую сложность которая у сортировки существенно выше чем у линейного поиска.
G>Алгоритмическая сложность у нормального алгоритма быстрой сортировки такая же линейная, как у проверки на упорядоченность.

Покажи мне этот алгоритм, radix не предлагай он не универсален.
Re[9]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 10:51
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:


FR>>>В юнит тесте алгоритма сортировки


G>>Зачем? Можно просто сравнить с эталоном.


FR>Нельзя, задолбаешся три миллиона цифр вводить


А зачем тебе столько?

Главное проверить общий случай (один) и corner cases.

FR>>>Мы похоже по разному понимаем один проход.

FR>>>Я имел в виду алгоритмическую сложность которая у сортировки существенно выше чем у линейного поиска.
G>>Алгоритмическая сложность у нормального алгоритма быстрой сортировки такая же линейная, как у проверки на упорядоченность.

FR>Покажи мне этот алгоритм, radix не предлагай он не универсален.


http://algolist.manual.ru/sort/quick_sort.php

При выборе опорным элементом центральный элемент будет ровно один проход.
Re[33]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 10:53
Оценка:
Здравствуйте, Mamut, Вы писали:


PD>>Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!


M>Это продукт, удовлетворяющий твоим критериям качества


Так и всякой дряни наглотаться можно
With best regards
Pavel Dvorkin
Re[34]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 10:55
Оценка:
PD>>>Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!

M>>Это продукт, удовлетворяющий твоим критериям качества


PD>Так и всякой дряни наглотаться можно


Можно конечно Но если эта дрянь удовлетворяет мои потребности, это как бы мои проблемы


dmitriid.comGitHubLinkedIn
Re[35]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 11:18
Оценка:
Здравствуйте, Mamut, Вы писали:

PD>>Так и всякой дряни наглотаться можно


M>Можно конечно Но если эта дрянь удовлетворяет мои потребности, это как бы мои проблемы


Именно так. Не разобравшись с качеством продукта и не выслушав мнения специалистов я создам себе проблемы, которые потом решать будут медики.
With best regards
Pavel Dvorkin
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 11:44
Оценка:
Здравствуйте, gandjustas, Вы писали:


FR>>Покажи мне этот алгоритм, radix не предлагай он не универсален.


G>http://algolist.manual.ru/sort/quick_sort.php


G>При выборе опорным элементом центральный элемент будет ровно один проход.


Один проход будет не учитывая рекурсию, потом в каждой ветке повторные проходы.
В лучшем случае получим n * (ln n) проходов, что уже даже не считая затраты времени на обмены
в разы медленнее линейного поиска (у которого в среднем n / 2 прохода), в худшем же случае будет
n ^ 2 проходов.
Re[37]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 11:55
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Нас на самом деле занесло немного в ту степь (что всегда происходит с аналогиями).


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


M>Программа, выполняющая требования заказчика, — это, как минимум, мороженное, которое проходит по медицинским показателям.


Я и в этом на 100% не уверен. А вдруг он просто не столкнулся с редко проявляющимся багом, который исправить крайне сложно, так как ошибка заложена в архитектуру ? А проявляется он раз в пару лет... Жили, не тужили, радовались, а однажды с ним столкнулись — и теперь ни бе ни ме ни кукареку...

>Технические моменты вроде замены сортировки пузырьком на merge sort соответствуют замене обезжиренного молока в мороженном на полноценные сливки, например


Хорошо как на сливки, а ну как заменили на обрат ?


M>Почему? Потому что заказчик говорит: я хочу, чтобы программа соответствовала требованиям А, Б, В. Если программа им соответствует — прекрасно, и никакие внутренние, технические проблемы программы (вроде сортировки пузырьком) не приведут к проблемам, требующих медиков (она не напишет -1000000 там, где должно стоять +10).


См. выше.

< пример skipped>

M>Специалист (сферовакуумный?) скажет, что, безусловно, вторая система. Она и написана грамотно, и отчеты генерятся за 10-45 секунд против 2 часов в прежней системе и т.п.


M>А бухгалтерия скажет: «идите туда, где солнце не светит», потому что фирма потеряла почти 20 000 баксов, а отчеты нам нужны раз в месяц, можно и подождать 2 часа.


M>И будет права бухглтерия, а не специалист. Потому что в итоге решает заказчик. А для заказчика единственным критерием качества программы является то, как она обрабатывает его, заказчика, данные.


Черт его знает. Что-то в этом есть. Но принять не могу. Вот представь себе. Были у фирмы данные размером в N, и некий алгоритм прекрасно работал. Год, два, три. А потом фирма вдруг резко выросла и размер данных стал 10N. И стало все совсем нехорошо. А специалисты свое "фи" сказали бы раньше — мол, пока у вас N, 2N, 3N — все будет нормально, а потом наплачетесь. И это не пузырек, который можно и заменить. Вы, господа разработчики, положили в основу совсем неподходящую модель, а она центральное место в вашей задаче, поэтому надо было с самого начала искать тут решение NlogN, а не уповать, что N^2 сойдет.
With best regards
Pavel Dvorkin
Re[38]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 12:38
Оценка:
PD>Тогда вопрос — почему в той степи иные все же (ну согласись же ) законы ? И таких степей очень много, практически все. Помнишь, я про мост писал — та же степь. Про банк — та же. Что-то тут не так...

Ну, просто области все же разные Мороженное — это не программа, а программа — не мороженое И даже среди программ бывают разные От допущения «плюс-минус 5% нам нестрашно» до «плюс-минус 5% — это ядерный армагеддон»

M>>Программа, выполняющая требования заказчика, — это, как минимум, мороженное, которое проходит по медицинским показателям.


PD>Я и в этом на 100% не уверен. А вдруг он просто не столкнулся с редко проявляющимся багом, который исправить крайне сложно, так как ошибка заложена в архитектуру ? А проявляется он раз в пару лет... Жили, не тужили, радовались, а однажды с ним столкнулись — и теперь ни бе ни ме ни кукареку...


Такую ошибку и специалисты не выявят А может и выявят Неизвестно

>>Технические моменты вроде замены сортировки пузырьком на merge sort соответствуют замене обезжиренного молока в мороженном на полноценные сливки, например


PD>Хорошо как на сливки, а ну как заменили на обрат ?


Это как если программа, которая работала 5 секунд, стала работать 15 секунд на тех же данных


M>>Специалист (сферовакуумный?) скажет, что, безусловно, вторая система. Она и написана грамотно, и отчеты генерятся за 10-45 секунд против 2 часов в прежней системе и т.п.


M>>А бухгалтерия скажет: «идите туда, где солнце не светит», потому что фирма потеряла почти 20 000 баксов, а отчеты нам нужны раз в месяц, можно и подождать 2 часа.


M>>И будет права бухглтерия, а не специалист. Потому что в итоге решает заказчик. А для заказчика единственным критерием качества программы является то, как она обрабатывает его, заказчика, данные.


PD>Черт его знает. Что-то в этом есть. Но принять не могу. Вот представь себе. Были у фирмы данные размером в N, и некий алгоритм прекрасно работал. Год, два, три. А потом фирма вдруг резко выросла и размер данных стал 10N. И стало все совсем нехорошо. А специалисты свое "фи" сказали бы раньше — мол, пока у вас N, 2N, 3N — все будет нормально, а потом наплачетесь. И это не пузырек, который можно и заменить. Вы, господа разработчики, положили в основу совсем неподходящую модель, а она центральное место в вашей задаче, поэтому надо было с самого начала искать тут решение NlogN, а не уповать, что N^2 сойдет.


А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.


dmitriid.comGitHubLinkedIn
Re[32]: пояснение о качестве
От: fmiracle  
Дата: 05.08.10 12:38
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хорошо, поставлю вопрс прямо.

PD>Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!

Но я надеюсь, что и ты сможешь ответить — перестал ли ты избивать студентов на своих занятиях? Без комментариев, просто да или нет!



Мучает меня, правда, вопрос, будешь ли ты покупать мороженное "Магнат", которое тебе совершенно не нравится на вкус, но которое рекомендовал Союз Мороженников РФ, или будешь ты покупать мороженное "Богдан", которое — для тебя — вкусное, по составу выглядит прилично, но на которое никто не дал рекомендаций?
(а дипломированные специалисты компании "Магнат" вообще заявили, что Богдан их мороженному в подметки не годится)

- Подгузники Памперс — единственные подгузники, рекомендованные Союзом Педиатров России!
— Союз Педиатров Росиии — единственный союз, созданный специально для рекламы подгузников Памперс!

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 05.08.10 12:57
Оценка:
Здравствуйте, Mamut, Вы писали:


R>>тупое суммирование массива из 30,000,000 doubles.


R>>LINQ Sum: 915 ms

R>>обычный цикл: 134 ms
R>>C++ : 61 ms

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


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


M>В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?


вот не поветите, реальные задачи они разные бывают. И массиви на миллионы и десятки миллионов элементов совсем не редкость. Тем более что сыр-бор изначально был из-за того, что люди заменяют O(n) -> O(n*n) и не видят в этом криминала. а подобные вещи приводят к проблемам куда как быстрее.
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 13:08
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:



FR>>>Покажи мне этот алгоритм, radix не предлагай он не универсален.


G>>http://algolist.manual.ru/sort/quick_sort.php


G>>При выборе опорным элементом центральный элемент будет ровно один проход.


FR>Один проход будет не учитывая рекурсию, потом в каждой ветке повторные проходы.

FR>В лучшем случае получим n * (ln n) проходов, что уже даже не считая затраты времени на обмены
FR>в разы медленнее линейного поиска (у которого в среднем n / 2 прохода), в худшем же случае будет
FR>n ^ 2 проходов.

Ну вот я проснулся.

insertion sort дает O(n) в случае упорядоченного массива.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: Klapaucius  
Дата: 05.08.10 13:10
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Мне больше нравится код, где никаких инструкций не нужно.


Мне тоже, но к циклам это отношения не имеет. Они нечитабельны.

Кэр>И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.


Ну, простейший цикл
forever {}

особых пояснений действительно не требует, вот только он бесполезен. А все полезные требуют, да еще как!

Кэр>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?


Это были доводы против использования функций и в пользу дублирования кода?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[38]: пояснение о качестве
От: fmiracle  
Дата: 05.08.10 13:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

M>>Нас на самом деле занесло немного в ту степь (что всегда происходит с аналогиями).

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

Да все тут точно так же . Когда мост через ручей в деревне строят никто не просчиывает пределы прочности древесины и воздейсвтие атмосферных явлений — кинут пару бревен и порядок.
Когда строят мост через пролив в 5 километров по которому еще и поезда ходить будут — выкатывают стотыщ требований, которые необходимо соблюсти.

То же самое в точности и в IT. Если заказчику нужна программка для решения небольшой текущей проблемы в небольшом отделе — это одно. Требований будет немного и свобода по реализации очень большая.
Если ему нужна программа для управления деньгами большого числа пользователей — то выкатят вагон требований, в частности по надежности, масштабируемости и безопасности. Да еще и добавят требование предоставления всех исходников программы на code-review отделу информационной безопасности с необходимостью учесть все созданные замечания.

И кстати, требования по маштабируемости не будут выставлять в терминах "надо быстрее и еще-еще быстрее". Выставят предельный график изменения требований к ресурсам при заданном просте числа обрабатываемых данных. И если в этот график программа уложится — все хорошо, и опять же не очень важно как она там реализована технически.

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

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

И да — заказчик станет "доволен" именно когда все требования будут соблюдены. Принимающий ПМ, пусть он хоть вообще не шарит в IT, будет нифига не доволен принимать программу, если у него на столе отчет отдела ИБ, что программа в текущем виде черевата большими судебными исками — нахрена ему принимать эту ответственность?


Кстати, раз уж упомянул про закон, запрещающий добавлять яды в продукты питания.
Вот отличный пример, что в IT все точно так же, только область новая, регулировок пока еще меньше — некоторое время назад было законодательно издано требование ко всем организациям, которые так или иначе хранят или обрабатывают персональные данные гражан, привести свои системы хранения/обработки в соответстве с требованиями федерального закона "О персональных данных". А там в том числе требования — и что можно собирать, а что нельзя, и как должно осуществляться шифорование и в целом защита данных, и еще куча аспектов. И теперь, что характерно, ни одна компания не примет IT-систему, храняющую персональные данные, если она не соответствует требованиям закона.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 13:17
Оценка:
Здравствуйте, vitasR, Вы писали:

R>Здравствуйте, Mamut, Вы писали:



R>>>тупое суммирование массива из 30,000,000 doubles.


R>>>LINQ Sum: 915 ms

R>>>обычный цикл: 134 ms
R>>>C++ : 61 ms

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


R>в качестве оценки эффективности реализации Sum на простых запросах приведенный код (даже несмотря на неточность в выводе результатов) вполне адекватен.

Ниугадал.
У меня получилась разница .Sum и цикла в 2.3 раза, а не в 7, как у тебя. Ты видимо совсем не то померял.


M>>В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?


R>вот не поветите, реальные задачи они разные бывают. И массиви на миллионы и десятки миллионов элементов совсем не редкость.

Конечно не редкость, а вот такая обработка для таких массивов редкость.
Часто с такими сталкиваешься? что за алгоритмы на них работают? Как-то не верится что обычное суммирование хоть где-то будет.

R>Тем более что сыр-бор изначально был из-за того, что люди заменяют O(n) -> O(n*n) и не видят в этом криминала. а подобные вещи приводят к проблемам куда как быстрее.

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

Кроме того если вдруг какая-то часть будет тормозить, то её можно оптимизировать. Преждевременно этим заниматься не надо.
Re[12]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 13:32
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну вот я проснулся.


G>insertion sort дает O(n) в случае упорядоченного массива.


Угу офигено полезное свойство
Re[13]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.08.10 13:38
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:


G>>Ну вот я проснулся.


G>>insertion sort дает O(n) в случае упорядоченного массива.


FR>Угу офигено полезное свойство


Ну когда данные почти упорядочены, то лучше именно его применять.

Вот и совершенно ненужным стал алгоритм проверки упорядоченности.
Re[14]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 05.08.10 13:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

FR>>Угу офигено полезное свойство


G>Ну когда данные почти упорядочены, то лучше именно его применять.


Почти гарантированный n^2 если данные не упорядоченны может не пройти если данных много.
Re[39]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 13:58
Оценка:
Здравствуйте, Mamut, Вы писали:


PD>>Черт его знает. Что-то в этом есть. Но принять не могу. Вот представь себе. Были у фирмы данные размером в N, и некий алгоритм прекрасно работал. Год, два, три. А потом фирма вдруг резко выросла и размер данных стал 10N. И стало все совсем нехорошо. А специалисты свое "фи" сказали бы раньше — мол, пока у вас N, 2N, 3N — все будет нормально, а потом наплачетесь. И это не пузырек, который можно и заменить. Вы, господа разработчики, положили в основу совсем неподходящую модель, а она центральное место в вашей задаче, поэтому надо было с самого начала искать тут решение NlogN, а не уповать, что N^2 сойдет.


M>А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.


Почему же нет ? Все очень просто. Получили задачу эти горе-разработчики. Проанализировали ее (это им так показалось). Пришли к выводу, что основная модель в варианте 1 будет вполне приемлемо работать . А есть модель 2, но она на порядок сложнее для реализации, потребует больше времени и сил, а выигрыш проявится только при больших N. Вот и решили — денег не так уж много, времени мало, реализуем модель 1. Один, правда, заикнулся в духе : "А что потом скажем, когда данных больше будет ?", но ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.

Вот это и есть халтура.

Взяли Хибернейт. Нужды нет, что он тащит по select половину данных, которые совсем и не нужны, а по update апдейтит то, что менять совсем не надо. Зато просто по сравнению с sproc. Кто-то, правда, заикнулся — а что будет, когда размеры выборок станут большими ? Ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.

Вот это и есть халтура.
With best regards
Pavel Dvorkin
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 14:01
Оценка:
Здравствуйте, vitasR, Вы писали:

R>Здравствуйте, Mamut, Вы писали:



R>>>тупое суммирование массива из 30,000,000 doubles.


R>>>LINQ Sum: 915 ms

R>>>обычный цикл: 134 ms
R>>>C++ : 61 ms

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


R>в качестве оценки эффективности реализации Sum на простых запросах приведенный код (даже несмотря на неточность в выводе результатов) вполне адекватен.


Он ничем абсолютно не адекватен.


M>>В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?


R>вот не поветите, реальные задачи они разные бывают. И массиви на миллионы и десятки миллионов элементов совсем не редкость. Тем более что сыр-бор изначально был из-за того, что люди заменяют O(n) -> O(n*n) и не видят в этом криминала. а подобные вещи приводят к проблемам куда как быстрее.


Кажется, тут умные люди, и все понимают, что при работе с миллионами и десятками миллионов элементов не будет использоваться ни один ни другой подход. Когда разница между O(n) и O(n*n) на наборе данных различается в 10ms (а ну-ка, проверьте кто-нить код из примера на 1000 даблов), то смысла разводить сыр-бор нет вообще. Узкое место в программе наверняка окажется совсем не там.


dmitriid.comGitHubLinkedIn
Re[33]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 14:03
Оценка:
Здравствуйте, fmiracle, Вы писали:

PD>>Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!


F>Но я надеюсь, что и ты сможешь ответить — перестал ли ты избивать студентов на своих занятиях? Без комментариев, просто да или нет!


Подобной софистикой займи студентов. Я ей интересовался именно в студенческом возрасте. Мой же вопрос был вполне определенный, на него можно дать ответ "да" или "нет" в зависимости от точки зрения. Я на свой вопрос отвечаю совершенно определенно — "нет", а ты — как хочешь.

F>Мучает меня, правда, вопрос, будешь ли ты покупать мороженное "Магнат", которое тебе совершенно не нравится на вкус, но которое рекомендовал Союз Мороженников РФ, или будешь ты покупать мороженное "Богдан", которое — для тебя — вкусное, по составу выглядит прилично, но на которое никто не дал рекомендаций?

F>(а дипломированные специалисты компании "Магнат" вообще заявили, что Богдан их мороженному в подметки не годится)

Слушай, ну нельзя же так. Прочитать то, что я писал можно же было. Вот тут, к примеру, но я потом еще повторял

http://rsdn.ru/forum/flame.comp/3904386.1.aspx
Автор: Pavel Dvorkin
Дата: 04.08.10


PD>Резюме — если пользователь недоволен, его мнение важно и существенно при оценке качества за исключением разве что каких-то маргинальных случаев.

PD>Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.
With best regards
Pavel Dvorkin
Re[40]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 14:05
Оценка:
PD>>>Черт его знает. Что-то в этом есть. Но принять не могу. Вот представь себе. Были у фирмы данные размером в N, и некий алгоритм прекрасно работал. Год, два, три. А потом фирма вдруг резко выросла и размер данных стал 10N. И стало все совсем нехорошо. А специалисты свое "фи" сказали бы раньше — мол, пока у вас N, 2N, 3N — все будет нормально, а потом наплачетесь. И это не пузырек, который можно и заменить. Вы, господа разработчики, положили в основу совсем неподходящую модель, а она центральное место в вашей задаче, поэтому надо было с самого начала искать тут решение NlogN, а не уповать, что N^2 сойдет.

M>>А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.


PD>Почему же нет ? Все очень просто. Получили задачу эти горе-разработчики. Проанализировали ее (это им так показалось). Пришли к выводу, что основная модель в варианте 1 будет вполне приемлемо работать . А есть модель 2, но она на порядок сложнее для реализации, потребует больше времени и сил, а выигрыш проявится только при больших N. Вот и решили — денег не так уж много, времени мало, реализуем модель 1. Один, правда, заикнулся в духе : "А что потом скажем, когда данных больше будет ?", но ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.


PD>Вот это и есть халтура.


PD>Взяли Хибернейт. Нужды нет, что он тащит по select половину данных, которые совсем и не нужны, а по update апдейтит то, что менять совсем не надо. Зато просто по сравнению с sproc. Кто-то, правда, заикнулся — а что будет, когда размеры выборок станут большими ? Ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.


PD>Вот это и есть халтура.


Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п. Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни. Именно поэтому в реальной жизни рулят реальные требования. Прогнозирование никто не отменял. Но в таком случае софт, который не выполняет требования согласно прогнозам — плохой софт. Но опять же, не с точки зрения специалиста, а с точки зрения заказчика, который такой прогноз составил.


dmitriid.comGitHubLinkedIn
Re[39]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 14:09
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>То же самое в точности и в IT. Если заказчику нужна программка для решения небольшой текущей проблемы в небольшом отделе — это одно. Требований будет немного и свобода по реализации очень большая.

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

F>И кстати, требования по маштабируемости не будут выставлять в терминах "надо быстрее и еще-еще быстрее". Выставят предельный график изменения требований к ресурсам при заданном просте числа обрабатываемых данных. И если в этот график программа уложится — все хорошо, и опять же не очень важно как она там реализована технически.


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


Уф! Так я об этом и говорю. Только специалисты могут оценить качество. Ты сказал о специалистах по безопасности, надежности и т.д. Можно и другие критерии добавить, в зависимости от задачи.

F>И да — заказчик станет "доволен" именно когда все требования будут соблюдены. Принимающий ПМ, пусть он хоть вообще не шарит в IT, будет нифига не доволен принимать программу, если у него на столе отчет отдела ИБ, что программа в текущем виде черевата большими судебными исками — нахрена ему принимать эту ответственность?


Совершенно верно! Положительное решение о качестве могут дать только специалисты!

А вот отрицательное — могут дать и конечные пользователи. Пусть все специалисты дали самое наилучшее заключение, а бухгалтеры ругаются — работать неудобно, то и дело проблемы возникают. И все. Качественной такая программа быть признана не может.
With best regards
Pavel Dvorkin
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
От: midcyber
Дата: 05.08.10 14:41
Оценка:
Здравствуйте, FR, Вы писали:

M>>Некорректная задача, для студента или с собеседования. Правильно:

FR>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.

В случае нескольких критериев линк будет эффективнее И нагляднее, как я понимаю.

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

FR>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
Сортировать придется один раз, сортировка уже отсортированного массива — такой же линейный проход..
Re[41]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 14:41
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.


PD>>Почему же нет ? Все очень просто. Получили задачу эти горе-разработчики. Проанализировали ее (это им так показалось). Пришли к выводу, что основная модель в варианте 1 будет вполне приемлемо работать . А есть модель 2, но она на порядок сложнее для реализации, потребует больше времени и сил, а выигрыш проявится только при больших N. Вот и решили — денег не так уж много, времени мало, реализуем модель 1. Один, правда, заикнулся в духе : "А что потом скажем, когда данных больше будет ?", но ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.


PD>>Вот это и есть халтура.


PD>>Взяли Хибернейт. Нужды нет, что он тащит по select половину данных, которые совсем и не нужны, а по update апдейтит то, что менять совсем не надо. Зато просто по сравнению с sproc. Кто-то, правда, заикнулся — а что будет, когда размеры выборок станут большими ? Ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.


PD>>Вот это и есть халтура.


M>Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п.


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


>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.


Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.
Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.

А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.
With best regards
Pavel Dvorkin
Re[40]: пояснение о качестве
От: fmiracle  
Дата: 05.08.10 14:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>Уф! Так я об этом и говорю. Только специалисты могут оценить качество. Ты сказал о специалистах по безопасности, надежности и т.д. Можно и другие критерии добавить, в зависимости от задачи.


"специалисты" про которых я говорю — это те же представители заказчика, которые тоже должны быть "довольны" прежде чем программа будет принята. Почему ты под "заказчиком" понимаешь только какого-то далекого от IT человека (и вообще одного единственного человека) — мне сугубо непонятно.

Специалист по ИБ может воощбще не умеет программировать, но он знает, что надо проверить, что программа не падает при, например, попытке загрузкить в нее 4хгигабайтный файл. И если падает, то это минус, т.к. может вызвать простои в работе.

Это мало чем отличается от того, что тетя Маша из бухгалтерии ничего не знает про программирвоание, но знает, что если ctrl+c/ctrl+v не работают, то это плохо, т.к. прямой минус скорости ввода данных (например).

В чем разница невыполнения двух требований — я не понимаю. Ну и что, что один специалист в некоторой области IT, а вторая — нет.

Чем более важная программа — тем просто больше заинтерисованных лиц, которые должны быть опрошены для принятия решения "хорошая" она или нет. И собираются требования всех — и специалистов по IT и специалистов по бизнесу. Причем собираются, вот это важно, не "мнения" по готовой программе, а требования к той программе которая будет разработана, а потом уже — соирается проверка на соответствие сделанной программы представленным требованиям. И вменяемых заказчиков не интересует используется там квадратичная сложность алгоритма в точке Х или линейная — интересует общее соответствие программы требованиям, собранных от всех заинтересованных в данной программе лиц.


Да, отдел ИБ — очень заинтересован во всех программах, за работу которых он потом будет отвечать. А если не будет, то и требований он не прдеставит.
И отдел сопровождения очень заинтересован в "простоте кода" ПО, которое он потом будет дорабатывать. А если поддержку всегда будет осуществлять сторонний исполнитель, то отдел сопровождения свои требования не выставляет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[42]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 14:55
Оценка:
M>>Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п.

PD>Где я говорю про вдруг ? Я просто имею в виду, что эти горе-проектировщики не оценили характеристики системы при разных значениях параметров и понадеялись на то, что сойдет и так. И до поры до времени это никто не замечает. А "вдруг" тут никакого нет — можно было вполне предсказать, если подумать.


Ты зря вырезал все

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


>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.


PD>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.


если это про линукс, то разве там все не переписано по пять раз?

PD>Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.


PD>А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.



правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу


dmitriid.comGitHubLinkedIn
Re[41]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 15:02
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>"специалисты" про которых я говорю — это те же представители заказчика, которые тоже должны быть "довольны" прежде чем программа будет принята. Почему ты под "заказчиком" понимаешь только какого-то далекого от IT человека (и вообще одного единственного человека) — мне сугубо непонятно.


Где я писал про одного человека ?

Впрочем, если в такой формулировке — пожалуйста, соглашусь. Программа является качественной, если специалисты по ... высказались, что она качественная. В качестве многоточия разреши мне подставить что угодно — как тех специалистов, что есть у заказчика, так и тех, что у него нет (независимо от причины). Потому что если у заказчика есть специалисты по безопасности и они признали программу качественной, но нет специалистов по системному проектированию, которые ее качественной не признали бы — я не вижу, почему мнение первых надо учитывать, а вторых — нет.
With best regards
Pavel Dvorkin
Re[41]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 15:03
Оценка:
F>Это мало чем отличается от того, что тетя Маша из бухгалтерии ничего не знает про программирвоание, но знает, что если ctrl+c/ctrl+v не работают, то это плохо, т.к. прямой минус скорости ввода данных (например).

В этом месте я вспомнил про систему бронирования Amadeus (еще есть российская Сирена). Выглядит она так: http://s147.photobucket.com/albums/r315/Sweety_Jo/Amadeus/?action=view&amp;current=amadeus14.jpg

Любой специалист скажет, что это страшный страх и ужасный ужас. И это действительно так. Но в этой системе грамотный оператор за 15 секунд, не больше, моежт найти билет из Стамбула в Петербург с минимум одной пересадкой для человека с ребенком по минимальной цене.

Пусть это и бдет выглядеть, как ATASPB1S1P1C в консоли Потому что это просто отличная программа, и лучше, чем она вряд ли существуют.

Но вот специалист скажет, что это — вырвыиглазный звиздец Здесь есть туториал по нему, кстати: http://www.dipity.com/timeline/Reservation-Availability


dmitriid.comGitHubLinkedIn
Re[43]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 15:10
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п.


PD>>Где я говорю про вдруг ? Я просто имею в виду, что эти горе-проектировщики не оценили характеристики системы при разных значениях параметров и понадеялись на то, что сойдет и так. И до поры до времени это никто не замечает. А "вдруг" тут никакого нет — можно было вполне предсказать, если подумать.


M>Ты зря вырезал все


M>

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


Заказчик не всегда в состоянии этот прогноз составить. Тут именно системный аналитик поработать должен. Специалист то есть.

>>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.


PD>>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.


M>если это про линукс, то разве там все не переписано по пять раз?


Нет, про Windows NT 3.1

PD>>Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.


PD>>А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.



M>правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу


Черта с два. Программисты того времени и помыслить о 16 Мб не могли, поскольку и 64 Кб было много, я и в 70-е их не имел. Это просто сама IBM подумала как следует.
With best regards
Pavel Dvorkin
Re[44]: пояснение о качестве
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.10 15:16
Оценка:
M>>Ты зря вырезал все

M>>

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


PD>Заказчик не всегда в состоянии этот прогноз составить. Тут именно системный аналитик поработать должен. Специалист то есть.


Системный аналитик с чьей стороны? Если скажешь, что со стороны разработчика, то ошибешься Системный аналитик со стороны заказчика — согласен. Потому что программист имеет к предметной области, в которой он обычно работает, весьма опосредованое отношение. Например, предсказать рост компании (что вызовет рост количества запросов к системе, например), разработчик просто не в состоянии. А городить огород только из-за того, что мне, как разработчику, кажется, что вдруг когда-то на порядок возрастет количество клиентов, — это и есть халтура.

>>>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.


PD>>>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.


M>>если это про линукс, то разве там все не переписано по пять раз?


PD>Нет, про Windows NT 3.1


Что-то мне подсказывает, что многое там тоже было переписано, пока достигли 4 Гигов и 3 гигагерц

PD>>>Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.


PD>>>А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.



M>>правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу


PD>Черта с два. Программисты того времени и помыслить о 16 Мб не могли, поскольку и 64 Кб было много, я и в 70-е их не имел. Это просто сама IBM подумала как следует.


А что такое IBM? Некое сферовакуумное сушество? Кто-то сел, спрогнозировал, спроектировал архитектуру. И да, в данном случае это был программист. Что не делает его менее заказчиком


dmitriid.comGitHubLinkedIn
Re[45]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 15:26
Оценка:
Здравствуйте, Mamut, Вы писали:

PD>>Заказчик не всегда в состоянии этот прогноз составить. Тут именно системный аналитик поработать должен. Специалист то есть.


M>Системный аналитик с чьей стороны? Если скажешь, что со стороны разработчика, то ошибешься Системный аналитик со стороны заказчика — согласен. Потому что программист имеет к предметной области, в которой он обычно работает, весьма опосредованое отношение. Например, предсказать рост компании (что вызовет рост количества запросов к системе, например), разработчик просто не в состоянии. А городить огород только из-за того, что мне, как разработчику, кажется, что вдруг когда-то на порядок возрастет количество клиентов, — это и есть халтура.


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

>>>>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.


PD>>>>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.


M>>>если это про линукс, то разве там все не переписано по пять раз?


PD>>Нет, про Windows NT 3.1


M>Что-то мне подсказывает, что многое там тоже было переписано, пока достигли 4 Гигов и 3 гигагерц


Не очень. Ядро не сильно изменилось. А принципы заложенные вообще нет.

M>>>правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу


PD>>Черта с два. Программисты того времени и помыслить о 16 Мб не могли, поскольку и 64 Кб было много, я и в 70-е их не имел. Это просто сама IBM подумала как следует.


M>А что такое IBM? Некое сферовакуумное сушество? Кто-то сел, спрогнозировал, спроектировал архитектуру. И да, в данном случае это был программист. Что не делает его менее заказчиком


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

Ладно, давай заканчивать.
With best regards
Pavel Dvorkin
Re[42]: пояснение о качестве
От: fmiracle  
Дата: 05.08.10 16:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


Потому что их нет.
Точнее потому, что их мнение заказчика относительно данной программы не интересует. Оно совершенно незначительное. Я же даже написал в предыдущем сообщении — у заказчика есть отдел ИБ. Но разрабатываемая программа — внутренняя, не имеет выхода во внешнюю сеть и некритична по надежности. Соответственно, отдел информационной безопасности просто не выставляет к ней свои требования. Потому что они в данном случае никого не интересуют.

Точно так же меня в Москве при покупке квартиры не интересует, выдерживает ли дом 10-тибальное землятрясение и полное погружение под воду при наводнении. Потому что район тут такой — нет ни сильных землятрясений ни наводнений. В другом районе земного шара я бы может посмотрел и на эти показатели. Иной подход — всегда смотреть все-все-все-возможные гипотетически требования — это значит что примерно все производимое человечеством объявить халтурой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[43]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 05.08.10 16:16
Оценка:
Здравствуйте, fmiracle, Вы писали:

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

With best regards
Pavel Dvorkin
Re[48]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.08.10 09:34
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот давай до абсурда доведем. Быстродействие (в том числе и диска, чтоб ему) и память еще раз в 20 увеличились. А задачи остались прежними, потому что они бизнес-сутью определяются, а не тактовой частотой (не все, конечно). Да тут полное раздолье будет — валяй что угодно, любую халтуру делай, все равно заказчик доволен будет. И создастся т.н. "террор среды" (впрочем, почему создастся, он уже есть) — когда много людей делают халтуру, они себя быстро убеждают в том. что они именно как надо делают, а все кто их за халтуру ругает, ничего не понимают и воообще зануды.


Вообще то бизнес всегда требует больше, чем может выдержать железо.
Re[49]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 06.08.10 09:53
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вообще то бизнес всегда требует больше, чем может выдержать железо.


Бизнес требует то, что ему надо, а это определяется его задачами. Уровень же развития железа определяется совсем иными факторами. Не коррелирует. Возможны ситуации, когда бизнесу не хватает и очень долго не будет хватать возможностей железа (или модели расчета) — например, хороший прогноз погоды или курса акций а возможна ситуация, когда бизнесу хватило бы Пентиум-100 с 16 Мб forever — например, для сайта небольшой турфирмы, у которой в высокий сезон хорошо если 10-15 посетителей в день. У этой турфирмы новых потребностей не возникнет — просто потому что этот бизнес едва ли радикально изменится в ближайшие десятилетия.
With best regards
Pavel Dvorkin
Re[50]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.08.10 11:07
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Возможны ситуации, когда бизнесу не хватает и очень долго не будет хватать возможностей железа (или модели расчета) — например, хороший прогноз погоды или курса акций .


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

>а возможна ситуация, когда бизнесу хватило бы Пентиум-100 с 16 Мб forever — например, для сайта небольшой турфирмы, у которой в высокий сезон хорошо если 10-15 посетителей в день


На один такой сайт не выгодно ставить отдельный комп даже если это будет самое дешовое железо. В любом случае дешевле поставить сервак на сотню таких сайтов. И тут снова Пентиум-100 пролетает.
Re[51]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 06.08.10 12:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Возможны ситуации, когда бизнесу не хватает и очень долго не будет хватать возможностей железа (или модели расчета) — например, хороший прогноз погоды или курса акций .


I>управление предприятием, логистика, финансы, бухгалтерия и тд и тд и тд — здесь сколько железа ни дай, всё равно будет мало


+1

>и так везде.


А вот это далеко не верно. Думаю, что для 95% сайтов этого самого Пентиум-100/16-32 вполне хватило бы.

>>а возможна ситуация, когда бизнесу хватило бы Пентиум-100 с 16 Мб forever — например, для сайта небольшой турфирмы, у которой в высокий сезон хорошо если 10-15 посетителей в день


I>На один такой сайт не выгодно ставить отдельный комп даже если это будет самое дешовое железо. В любом случае дешевле поставить сервак на сотню таких сайтов. И тут снова Пентиум-100 пролетает.


При чем тут выгодно — невыгодно ? Его и не поставишь — на свалке его, что ли искать ? И то, что можно поставить сервер на сотню таких сайтов — верно. Но вот если бы сейчас лучшим компьютером был этот Пентиум-100 — да, сотню сайтов на нем бы не сделали, но один — вполне не хуже, чем сейчас. Я к тому, что его ресурсов для простенького сайта вполне хватит.
With best regards
Pavel Dvorkin
Re[52]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.08.10 13:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>При чем тут выгодно — невыгодно ?


Это центральный момент. Ты все ведешь к тому, что де увеличение мощности железа приводит к ухудшению кода в плане производительности.

"выгодно-невогодно" как ты назвал, вынуждает сайты разделять сервера. Потому сат все равно надо оптимизировать, что бы не задушить сервер. Чем лучше оптимизируешь, тем выгоднее будет — меньше серверов/ресурсов придется оплатить.

Вот твои слова — я почти уверен, ты про них забыл

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


По причине обозначеной выше халтура не пройдет — заказчику придется оплатить больше серверов/ресурсов.

Кроме того, задачи никогда не остаются прежними. Людям, не только бизнесу, всегда чтото надо. Количество сайтов, объем функционала на сайтах только увеличивается.
Re[53]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 06.08.10 14:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PD>>При чем тут выгодно — невыгодно ?


I>Это центральный момент. Ты все ведешь к тому, что де увеличение мощности железа приводит к ухудшению кода в плане производительности.


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

I>"выгодно-невогодно" как ты назвал, вынуждает сайты разделять сервера. Потому сат все равно надо оптимизировать, что бы не задушить сервер. Чем лучше оптимизируешь, тем выгоднее будет — меньше серверов/ресурсов придется оплатить.


Тоже не совсем так. Если на сервере сотня сайтов — да, верно. А если один, да еще с посещаемостью 20 человек в сутки — можно и не оптимизировать, все равно в эти самые секунды отклика, о которых мне тут много говорили, уложишься

I>Вот твои слова — я почти уверен, ты про них забыл


Интересно, почему ты в этом уверен ? Смею заметить, что отнюдь не забыл. И даже помню фразу, которую ты выпустил, а зря. Я ее на место вставляю и выделяю жирным

I>

I>Вот давай до абсурда доведем. Быстродействие (в том числе и диска, чтоб ему) и память еще раз в 20 увеличились. А задачи остались прежними, потому что они бизнес-сутью определяются, а не тактовой частотой (не все, конечно). Да тут полное раздолье будет — валяй что угодно, любую халтуру делай, все равно заказчик доволен будет


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

I>По причине обозначеной выше халтура не пройдет — заказчику придется оплатить больше серверов/ресурсов.


Это я вообще не понял. Если допустить, что возможности увеличились в 20 раз , а цена не изменилась (а она и не росла в последние годы), то больше платить не придется. Ныненшняя машинка не стоит дороже машинки десятилетней давности того же класса.

I>Кроме того, задачи никогда не остаются прежними. Людям, не только бизнесу, всегда чтото надо. Количество сайтов, объем функционала на сайтах только увеличивается.


Не везде и не всегда. Я с 2002 года постоянно езжу в турпоездки, и с сайтами турфирм хорошо знаком. Мало что там изменилось за эти годы. Да и с чего бы ? Бизнес тот же, стран на свете больше не стало, туров различных, может, и побольше, так раза в полтора от силы, а не в десять. Нечему там меняться, в обозримом будущем по крайней мере. И для магазина какого-нибудь — тоже. Вот купил я весной себе компьютер, облазил для этого N омских сайтов. Везде, в общем, одно и то же, прайс-лист, описание продуктов, изображение, отзывы иногда, бланк заказа и т.д. Что тут может измениться ?
With best regards
Pavel Dvorkin
Re[54]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.08.10 21:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

I>>Это центральный момент. Ты все ведешь к тому, что де увеличение мощности железа приводит к ухудшению кода в плане производительности.


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


Не дает даже возможности. Всего лишь меняются приоритеты, в каком направлении что нужно оптимизировать.

Скорость чтения веников например растет очень медленно и сейчас веники очень сильно отстают от процессора.

PD>Тоже не совсем так. Если на сервере сотня сайтов — да, верно. А если один, да еще с посещаемостью 20 человек в сутки — можно и не оптимизировать, все равно в эти самые секунды отклика, о которых мне тут много говорили, уложишься


Один на сервер да с посещаемостью 20 человек — это уже прошлый век.

PD>Это я вообще не понял. Если допустить, что возможности увеличились в 20 раз , а цена не изменилась (а она и не росла в последние годы), то больше платить не придется. Ныненшняя машинка не стоит дороже машинки десятилетней давности того же класса.


Зато требования к железу увеличились. Кол.во страниц, мегабайт и всяких попугаев, очень сильно увеличилось в пересчете на одного пользователя. Соответсвенно железа надо докупать много бОльше.

Вот у меня, например, около 20 сайтов которыми пользуюсь довольно часто. Гуглмапс например на п-100 никак не пойдет.

PD>Не везде и не всегда. Я с 2002 года постоянно езжу в турпоездки, и с сайтами турфирм хорошо знаком. Мало что там изменилось за эти годы. Да и с чего бы ? Бизнес тот же, стран на свете больше не стало, туров различных, может, и побольше, так раза в полтора от силы, а не в десять.


Туров стало больше, турфирм стало больше. Кол.во стран смотря каких, если тех, в которые _можно_ стало ездить, то очень даже увеличилось.

С теми ЗП как ранее, люди могли разве что в турцию ездить.

Сейчас желающих вагоны, одной турции уже мало. УЖе на раз ездят и в азию и ближний восток и северную америку.

Еще десять лет — и добавятся страны из южного полушария.

>Нечему там меняться, в обозримом будущем по крайней мере. И для магазина какого-нибудь — тоже. Вот купил я весной себе компьютер, облазил для этого N омских сайтов. Везде, в общем, одно и то же, прайс-лист, описание продуктов, изображение, отзывы иногда, бланк заказа и т.д. Что тут может измениться ?


А ты сравни нынешний прайслист с тем, что 5-10 лет назад был.

У нас раньше выбора вообще не было никакого. Щас конечно тоже не фонтан, но по сравнению с тем что 5 лет назад было небо и земля. Сейча я могу выбрать только мышей десяти разных фирм. Раньше хорошо если 2-3 были.
Re[55]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 07.08.10 03:46
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Скорость чтения веников например растет очень медленно и сейчас веники очень сильно отстают от процессора.


+1

PD>>Тоже не совсем так. Если на сервере сотня сайтов — да, верно. А если один, да еще с посещаемостью 20 человек в сутки — можно и не оптимизировать, все равно в эти самые секунды отклика, о которых мне тут много говорили, уложишься


I>Один на сервер да с посещаемостью 20 человек — это уже прошлый век.


Если бы рост возможностей аппаратуры в 21 веке был равен нулю (вышли на плато), то так и было бы.


I>Зато требования к железу увеличились. Кол.во страниц, мегабайт и всяких попугаев, очень сильно увеличилось в пересчете на одного пользователя. Соответсвенно железа надо докупать много бОльше.


I>Вот у меня, например, около 20 сайтов которыми пользуюсь довольно часто. Гуглмапс например на п-100 никак не пойдет.


Я так думаю, что он вполне пошел бы на 16 Мб. Что там, в самом деле, памяти-то требует ? Подумаешь — несколько картинок разного размера и разрешения.

PD>>Не везде и не всегда. Я с 2002 года постоянно езжу в турпоездки, и с сайтами турфирм хорошо знаком. Мало что там изменилось за эти годы. Да и с чего бы ? Бизнес тот же, стран на свете больше не стало, туров различных, может, и побольше, так раза в полтора от силы, а не в десять.


I>Туров стало больше, турфирм стало больше. Кол.во стран смотря каких, если тех, в которые _можно_ стало ездить, то очень даже увеличилось.


С 2002 года нет. Вот если брать с 1980 года, то очень таки да

I>С теми ЗП как ранее, люди могли разве что в турцию ездить.


Зря ты так. Ездили в начале 2000-х не только в Турцию. Я в том числе.

I>Сейчас желающих вагоны, одной турции уже мало. УЖе на раз ездят и в азию и ближний восток и северную америку.


I>Еще десять лет — и добавятся страны из южного полушария.


Давно добавились.

>>Нечему там меняться, в обозримом будущем по крайней мере. И для магазина какого-нибудь — тоже. Вот купил я весной себе компьютер, облазил для этого N омских сайтов. Везде, в общем, одно и то же, прайс-лист, описание продуктов, изображение, отзывы иногда, бланк заказа и т.д. Что тут может измениться ?


I>А ты сравни нынешний прайслист с тем, что 5-10 лет назад был.


По ценам не буду — выросли, увы. А по предложению — ну раза в 1.5, не более, поверь мне.

I>У нас раньше выбора вообще не было никакого. Щас конечно тоже не фонтан, но по сравнению с тем что 5 лет назад было небо и земля. Сейча я могу выбрать только мышей десяти разных фирм. Раньше хорошо если 2-3 были.


И что ? Были в БД 3 мыши, стало 10. Это что, требует увеличения быстродействия в 20 раз ?
With best regards
Pavel Dvorkin
Re[57]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 07.08.10 10:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Гуглмапс на п-100 это нонсенс


Я был неточен, виноват. Я имел в виду, что клиент П-100 вполне потянет этот самый гугмапс в броузере. Сервер Гугла, конечно, нет.
With best regards
Pavel Dvorkin
Re[49]: пояснение о качестве
От: Sheridan Россия  
Дата: 07.08.10 14:32
Оценка:
Приветствую, Mamut, вы писали:

M> PD>Не боишься ?


M> Боюсь, кстати Но будем надеяться на лучшее


Пятое следствие законов Мерфи
avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)
Matrix has you...
Re[48]: пояснение о качестве
От: Sheridan Россия  
Дата: 07.08.10 14:32
Оценка:
Приветствую, Pavel Dvorkin, вы писали:


PD> Это опасный критерий.



Целиком и полностью поддерживаю.
avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)
Matrix has you...
Re[12]: Помогает ли Linq сделать код понятнее или быстрее?
От: vitasR  
Дата: 07.08.10 15:18
Оценка:
Здравствуйте, Mamut, Вы писали:

R>>>>LINQ Sum: 915 ms

R>>>>обычный цикл: 134 ms
R>>>>C++ : 61 ms

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


R>>в качестве оценки эффективности реализации Sum на простых запросах приведенный код (даже несмотря на неточность в выводе результатов) вполне адекватен.


M>Он ничем абсолютно не адекватен.


то есть с логикой совсем плохо ;(
тезис: элементарные операции типа Sum в Linq'e реализованы неэффективно по сравнению с обычном циклом
доказательство: две элементарных программы, версия с Linq работает раз в 5 медленнее.

ну и где неадекватность?


M>Кажется, тут умные люди, и все понимают, что при работе с миллионами и десятками миллионов элементов не будет использоваться ни один ни другой подход. Когда разница между O(n) и O(n*n) на наборе данных различается в 10ms (а ну-ка, проверьте кто-нить код из примера на 1000 даблов), то смысла разводить сыр-бор нет вообще.


умные люди понимают, что:
1) задачи с обработкой (и в частности суммированием) миллионов и десятков миллионов не редкость. Особенно если заниматься не примитивом.

2) "обычный" массив на тысячи элементов: один вложенный цикл и вот уже миллионы-десятки миллионов итераций.

3) да, нынче во многих случаях (на ширпотребовско-даунских задачах) с нынешними компами на производительность можно забить — хорошая новость для программистов вида Formoshlep Vulgaris
Беда в том, что программист, привыкший писать бездумно (хуже того, неспособный думать), не напишет нормально там, где это по-настоящему нужно. Хуже того, даже простую задачу по-настоящему "талантливый" программист может превратить в неподьемную для компа. Конкретный пример из недавнего: надо некоторое количество строчек (C++) длиной в несколько десятков символов каждая, слить в одну. Юное дарование пишет что-то вроде: strcat(Buffer, nextString); в цикле. Не царское это дело миллисекунды считать . У него на тестовых примерах с десятками строк все работает прекрасно. Угадайте сколько этот чудо-код стал выполняться в реальной жизни когда кол-во строк перевалило за 10,000 ?? И ведь задача-то элементарная, и количество элементов опять же тысячи, а не десятки миллионов. Короче, человеческая дурь победит любые гигагерцы. что регулярно и происходит.


M> Узкое место в программе наверняка окажется совсем не там.


узкое место в программе в 99% случаев находится по ту сторону монитора . собственно, это я и пытаюсь сказать.
поскольку все уже на второй если не третий круг пошло, интереса к продолжению дискуссии с моей стороны больше нет.
Re[56]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.08.10 15:46
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

I>>У нас раньше выбора вообще не было никакого. Щас конечно тоже не фонтан, но по сравнению с тем что 5 лет назад было небо и земля. Сейча я могу выбрать только мышей десяти разных фирм. Раньше хорошо если 2-3 были.


PD>И что ? Были в БД 3 мыши, стало 10. Это что, требует увеличения быстродействия в 20 раз ?


Игры + смотри свой слив про гугл-мапс. Щас джаваскрипт+флеш спокойно задушат п-100, ибо даже Core2Duo не всегда справляется.
Re[57]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 07.08.10 15:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PD>>И что ? Были в БД 3 мыши, стало 10. Это что, требует увеличения быстродействия в 20 раз ?


I>Игры


Это да. Тут никаких сомнений

>+ смотри свой слив про гугл-мапс.


Я же тебе объяснил, что я просто не о том подумал. Тут мне когда-то Синклер расписывал Гуглмэп и доказывал, что мол на Дельфи это еще 10 лет сделать нельзя будет(имеется в виду клиент в броузере против отдельного приложения на Дельфи). Ну я и написал..

>Щас джаваскрипт+флеш спокойно задушат п-100, ибо даже Core2Duo не всегда справляется.


Да уж. Качественно написано, ничего не скажешь. Для интерпретатора несложного языка не хватает 3 GHz и 2-3 Gb.
With best regards
Pavel Dvorkin
Re[58]: пояснение о качестве
От: FR  
Дата: 07.08.10 17:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да уж. Качественно написано, ничего не скажешь. Для интерпретатора несложного языка не хватает 3 GHz и 2-3 Gb.


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

PowerMac 5400 (180 MHz 603e)      = 890
iMac (266 MHz G3)                 = 4800
Sun (4 x 250 MHz Ultrasparc II)   = 2200 
Sun (1 x 350 MHz Ultrasparc IIi ) = 2600 
Pentium II 266MHz                 = 2821
Pentium III 450MHz                = 5800


Сейчас у меня Pentium E6500 (по современным меркам слабенький) на этот тест выдает 77410.

Что по сути означает что сейчас на питоне вполне можно писать приложения которые 10 лет назад
было необходимо по быстродействию писать на C++.
И при этом пользователи разницы в качестве (как определяешь ее ты) не заметят.
Re[59]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 07.08.10 17:21
Оценка:
Здравствуйте, FR, Вы писали:

FR>Что по сути означает что сейчас на питоне вполне можно писать приложения которые 10 лет назад

FR>было необходимо по быстродействию писать на C++.

То есть 10 лет назад были при качественном написании (на С++) компьютеры того времени вполне справлялись с этой задачей так же, как нынешние компьютеры с многократно увеличенной памятью и частотой могут с ней справиться, если писать даже на Питоне ? Верно. Это вполне подтверждает мою мысль, что при качественном написании для многого вполне хватило бы P-100, ну а коль уж памяти и скорости много — можно тратить понапрасну и писать софт, который работает в 10-20 раз медленнее, чем мог бы.

FR>И при этом пользователи разницы в качестве (как определяешь ее ты) не заметят.


Я ? Скорее мои оппоненты — они по времени реакции определяют. Я же определяю качество совсем иначе
With best regards
Pavel Dvorkin
Re[60]: пояснение о качестве
От: FR  
Дата: 07.08.10 17:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>То есть 10 лет назад были при качественном написании (на С++) компьютеры того времени вполне справлялись с этой задачей так же, как нынешние компьютеры с многократно увеличенной памятью и частотой могут с ней справиться, если писать даже на Питоне ? Верно. Это вполне подтверждает мою мысль, что при качественном написании для многого вполне хватило бы P-100, ну а коль уж памяти и скорости много — можно тратить понапрасну и писать софт, который работает в 10-20 раз медленнее, чем мог бы.


Большинство хороших программ написанных скажем на C++ в теории используя например суперкомпиляцию можно ускорить скажем в несколько а то и в 10 раз. Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации, наверно нужно все бросать и заняться этим?
Кстати скоро могут наступит совсем тяжелые времена если аппаратура окончательно и быстро повернет в сторону многоядерности то
получится такая ситуация у нас 128 ядер а большинство программ могут максимум утилизовать 5 — 6 из них

Ну и по питону. Я например пишу на нем код эквивалентный по функциональности коду на C++ примерно в три раза быстрее. То есть я могу написать
одинаковую по качеству, но в три раза более функциональную программу чем 10 лет назад, а мой конкурент на C++ не может.

FR>>И при этом пользователи разницы в качестве (как определяешь ее ты) не заметят.


PD>Я ? Скорее мои оппоненты — они по времени реакции определяют. Я же определяю качество совсем иначе


Re[61]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 06:25
Оценка:
Здравствуйте, FR, Вы писали:

FR>Большинство хороших программ написанных скажем на C++ в теории используя например суперкомпиляцию можно ускорить скажем в несколько а то и в 10 раз.


Едва ли. Все это именно теория. Доказательства есть ?


>Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации,

Опять едва ли. Intel C++ делает код, по быстродействию сравнимый с кодом на асме.

>наверно нужно все бросать и заняться этим?


Проще купить Intel C++.

FR>Кстати скоро могут наступит совсем тяжелые времена если аппаратура окончательно и быстро повернет в сторону многоядерности то

FR>получится такая ситуация у нас 128 ядер а большинство программ могут максимум утилизовать 5 — 6 из них

Это верно. Более того, пока что работа с многоядерностью более напоминает умелое шаманство, чем нечто такое, что можно применять обычному специалисту, не вдаваясь в детали реализации. Поясню. Вот пишу я заголовок цикла for(int i = 0; i < N; i++) — и не очень вдаюсь, как там это будет реализовано. Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.

FR>Ну и по питону. Я например пишу на нем код эквивалентный по функциональности коду на C++ примерно в три раза быстрее. То есть я могу написать

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

>а мой конкурент на C++ не может.


Почему не может ? Он может написать программу, которая использует эти ресурсы как следует, а не транжирит 70-80% из них. Поэтому он может написать то, что ты написать не можешь вообще.
With best regards
Pavel Dvorkin
Re[62]: пояснение о качестве
От: FR  
Дата: 08.08.10 09:46
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Едва ли. Все это именно теория. Доказательства есть ?


Конечно, все легко гуглится.
Суперкомпиляция делает и алгоритмические оптимизации и выносит все что возможно в compile-time, по сути современные
компиляторы когда оптимизируют вусмерть целые функции заменяя их константой ее и применяют.

>>Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации,

PD>Опять едва ли. Intel C++ делает код, по быстродействию сравнимый с кодом на асме.

Intel C++ уже научился править архитектуру приложений и делать алгоритмическую оптимизацию?

>>наверно нужно все бросать и заняться этим?


PD>Проще купить Intel C++.


Не поможет.
Кстати лет пять назад не на числодробильных алгоритмах интел часто сливал VC.

PD>Это верно. Более того, пока что работа с многоядерностью более напоминает умелое шаманство, чем нечто такое, что можно применять обычному специалисту, не вдаваясь в детали реализации. Поясню. Вот пишу я заголовок цикла for(int i = 0; i < N; i++) — и не очень вдаюсь, как там это будет реализовано. Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.




PD>Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности.


Нет я сейчас с теми же трудозатратами могу написать в три раза лучшую программу чем 10 лет назад.

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


Моя, я уже шесть лет назад писал на питоне, и железнячники лучше шевелились в том числе и для того чтобы мои программы шустрее работали

>>а мой конкурент на C++ не может.


PD>Почему не может ? Он может написать программу, которая использует эти ресурсы как следует, а не транжирит 70-80% из них. Поэтому он может написать то, что ты написать не можешь вообще.


Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.
Re[63]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 11:34
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Едва ли. Все это именно теория. Доказательства есть ?


FR>Конечно, все легко гуглится.

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

Мне не пояснения нужны, а пример того, что эта самая суперкомпиляция хорошо оптимизированную Intel C++ программу ускорила в 10 раз.

>>>Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации,

PD>>Опять едва ли. Intel C++ делает код, по быстродействию сравнимый с кодом на асме.

FR>Intel C++ уже научился править архитектуру приложений и делать алгоритмическую оптимизацию?


>>>наверно нужно все бросать и заняться этим?


PD>>Проще купить Intel C++.


FR>Не поможет.


Опять же доказательства ?

FR>Кстати лет пять назад не на числодробильных алгоритмах интел часто сливал VC.


Он и у меня однажды слил. Делал программу, VC++, оптимизировал, оптимизировал, а в глубине души думаю — вот как сделаю, откомпилирую ICC и скажу заказчику — а можно еще процентов 10-20 получить, если его купите . Наконец сделал все, что мог, установил триал ICC, запустил — 5% проигрыша. Обидно было
Но все это проценты, а не разы. В разы программу , откомпилированную VC++ или ICC — доказательства, пожалуйста. С исходниками

PD>>Это верно. Более того, пока что работа с многоядерностью более напоминает умелое шаманство, чем нечто такое, что можно применять обычному специалисту, не вдаваясь в детали реализации. Поясню. Вот пишу я заголовок цикла for(int i = 0; i < N; i++) — и не очень вдаюсь, как там это будет реализовано. Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.


FR>


А что тут смешного ?

PD>>Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности.


FR>Нет я сейчас с теми же трудозатратами могу написать в три раза лучшую программу чем 10 лет назад.


Я тоже с теми же трудозатратами напишу больше, чем 10 лет назад. Ну хотя бы потому, что компилятор работает быстрее, что он удобнее и т.д. Может, не в 3 раза, не считал. Но это не моя заслуга.

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


FR>Моя, я уже шесть лет назад писал на питоне, и железнячники лучше шевелились в том числе и для того чтобы мои программы шустрее работали


Ты на питоне играешь на том, что тебе нужно в 3, скажем, раза меньше времени, чтобы написать нечто, чем на С++, при том, что программа будет работать в 3, скажем, раза, медленнее, и памяти кушать в 3 раза больше, но рост того и другого все покроет. Таким образом, ты просто воспользуешься тем, что имел место резкий рост ресурсов, позволяющий тебе писать неэффективный код, так как при таких ресурсах этого никто не заметит.
А вот написать программу, которой и нынешних ресурсов мало, ты можешь ? Я мог 10 лет назад, и могу сейчас. Разумеется, это разные задачи, 10 лет назад я за нынешнюю и не взялся бы. А ты мою задачу нынешнюю решить не сможешь, потому что твой питон сделает тебе код, в 3 раза медленнее, чем мой С++ и вылетишь ты с этим кодом в трубу. Ну а пока твои задачи таковы, что можно себе в 3 раза медленнее делать — делай, на здоровье.

>>>а мой конкурент на C++ не может.


PD>>Почему не может ? Он может написать программу, которая использует эти ресурсы как следует, а не транжирит 70-80% из них. Поэтому он может написать то, что ты написать не можешь вообще.


FR>Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.


Опять же смотря где. В той задаче, о которой я чуть выше написал, где надо все нынешние возможности на 100% задействовать — ты мне вообще не конкурент, так как написать такое не в состоянии на своем питоне. Я могу какие угодно условия по времени разработки ставить, не обращая на тебя внимания (но на других С++ — программистов обращать внимание должен )

Вот сейчас у меня как раз такая задача. Некая обработка картинки размером примерно 500 на 500. Делать могу , что хочу, никаких ограничений. Время — меньше 5 мсек. Пока что получается 7-10. Ничего, будет и 5 .
With best regards
Pavel Dvorkin
Re[64]: пояснение о качестве
От: FR  
Дата: 08.08.10 12:01
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мне не пояснения нужны, а пример того, что эта самая суперкомпиляция хорошо оптимизированную Intel C++ программу ускорила в 10 раз.


Суперкомпиляция пока в детских штанишках, так что пока все скорее в теории, что-то минмимально работающее есть только
для рефала и явы http://www.supercompilers.com/white_paper.shtml.

PD>Опять же доказательства ?


Для большинства программ векторизация основной конек интела мало что даст.

PD>Он и у меня однажды слил. Делал программу, VC++, оптимизировал, оптимизировал, а в глубине души думаю — вот как сделаю, откомпилирую ICC и скажу заказчику — а можно еще процентов 10-20 получить, если его купите . Наконец сделал все, что мог, установил триал ICC, запустил — 5% проигрыша. Обидно было

PD>Но все это проценты, а не разы. В разы программу , откомпилированную VC++ или ICC — доказательства, пожалуйста. С исходниками

Так пять лет назад интел похуже был, а VC почти такой же как сейчас. Точно не помню уже, но раза полтора было.

FR>>


PD>А что тут смешного ?


Сама ситуация.

PD>>>Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности.


FR>>Нет я сейчас с теми же трудозатратами могу написать в три раза лучшую программу чем 10 лет назад.


PD>Я тоже с теми же трудозатратами напишу больше, чем 10 лет назад. Ну хотя бы потому, что компилятор работает быстрее, что он удобнее и т.д. Может, не в 3 раза, не считал. Но это не моя заслуга.


Угу больше процентов на 5.

FR>>Моя, я уже шесть лет назад писал на питоне, и железнячники лучше шевелились в том числе и для того чтобы мои программы шустрее работали


PD>Ты на питоне играешь на том, что тебе нужно в 3, скажем, раза меньше времени, чтобы написать нечто, чем на С++, при том, что программа будет работать в 3, скажем, раза, медленнее, и памяти кушать в 3 раза больше, но рост того и другого все покроет. Таким образом, ты просто воспользуешься тем, что имел место резкий рост ресурсов, позволяющий тебе писать неэффективный код, так как при таких ресурсах этого никто не заметит.


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

PD>А вот написать программу, которой и нынешних ресурсов мало, ты можешь ? Я мог 10 лет назад, и могу сейчас. Разумеется, это разные задачи, 10 лет назад я за нынешнюю и не взялся бы. А ты мою задачу нынешнюю решить не сможешь, потому что твой питон сделает тебе код, в 3 раза медленнее, чем мой С++ и вылетишь ты с этим кодом в трубу.


Я как раз могу, сейчас я как-раз в основном пишу на C++. Ну и игродел психику сильно портит, после него оптимизаторство практически неизлечимо

PD>Ну а пока твои задачи таковы, что можно себе в 3 раза медленнее делать — делай, на здоровье.


А как же качество?

FR>>Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.


PD>Опять же смотря где. В той задаче, о которой я чуть выше написал, где надо все нынешние возможности на 100% задействовать — ты мне вообще не конкурент, так как написать такое не в состоянии на своем питоне. Я могу какие угодно условия по времени разработки ставить, не обращая на тебя внимания (но на других С++ — программистов обращать внимание должен )


Угу, но ты почему-то не воспринимаешь что в той задаче про которую вел речь я, ты со своим C++ тоже совершенно не конкурент.
Re[65]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 12:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Суперкомпиляция пока в детских штанишках, так что пока все скорее в теории, что-то минмимально работающее есть только


Вот когда вырастет и покажет, что умеет в 10 раз ускорять, тогда и поговорим. А пока говорить не о чем. А то, что некоторые компиляторы умеют в compile-time цикл for(i=0; i < 10; i++) k+=i; исполнять — это, конечно, очень интересно , но к серьезной разработке имеет очень небольшое отношение.

FR>Для большинства программ векторизация основной конек интела мало что даст.


Иногда дает, иногда нет. Тут порой то же шаманство, что и с потоками.

FR>Так пять лет назад интел похуже был, а VC почти такой же как сейчас. Точно не помню уже, но раза полтора было.


Я для себя резюме простое сделал — полагаться на то, что ICC даст лучшие результаты, не стоит. Хотя проверить всегда надо.

PD>>Я тоже с теми же трудозатратами напишу больше, чем 10 лет назад. Ну хотя бы потому, что компилятор работает быстрее, что он удобнее и т.д. Может, не в 3 раза, не считал. Но это не моя заслуга.


FR>Угу больше процентов на 5.


Может быть.


PD>>Ты на питоне играешь на том, что тебе нужно в 3, скажем, раза меньше времени, чтобы написать нечто, чем на С++, при том, что программа будет работать в 3, скажем, раза, медленнее, и памяти кушать в 3 раза больше, но рост того и другого все покроет. Таким образом, ты просто воспользуешься тем, что имел место резкий рост ресурсов, позволяющий тебе писать неэффективный код, так как при таких ресурсах этого никто не заметит.


FR>Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).


Срочно перехожу на JavaScript. Он, как я понимаю, медленнее всего (если не так — скажи, что там медленнее всего, перейду на него). Пусть производители мне ресурсы увеличивают


FR>Так что это ты пользуешься тем что сделал я





PD>>А вот написать программу, которой и нынешних ресурсов мало, ты можешь ? Я мог 10 лет назад, и могу сейчас. Разумеется, это разные задачи, 10 лет назад я за нынешнюю и не взялся бы. А ты мою задачу нынешнюю решить не сможешь, потому что твой питон сделает тебе код, в 3 раза медленнее, чем мой С++ и вылетишь ты с этим кодом в трубу.


FR>Я как раз могу, сейчас я как-раз в основном пишу на C++.


То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++

PD>>Ну а пока твои задачи таковы, что можно себе в 3 раза медленнее делать — делай, на здоровье.


FR>А как же качество?


Страдает и плачет горючими слезами. Но не могу же я тебе запретить писать некачественно


FR>>>Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.


PD>>Опять же смотря где. В той задаче, о которой я чуть выше написал, где надо все нынешние возможности на 100% задействовать — ты мне вообще не конкурент, так как написать такое не в состоянии на своем питоне. Я могу какие угодно условия по времени разработки ставить, не обращая на тебя внимания (но на других С++ — программистов обращать внимание должен )


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


А вот это еще вопрос. Мне трудно судить, я питона не знаю. В двух словах — что там такое есть, чего в С++ быть не может ? (подчеркиваю, именно так, аргументы вроде "там есть такая навороченная библиотека, какой на С++ ты нигде не найдешь)" — не принимаются.
With best regards
Pavel Dvorkin
Re[66]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.10 12:31
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

FR>>Я как раз могу, сейчас я как-раз в основном пишу на C++.


PD>То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++


Чушь. Числодробилки это далеко не самое главное. Это было актуально еще 10 лет назад.

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

А вот ускорять ввод-вывод, вводить кеширование и тд и тд — здесь уже С++ толком ничем помочь и не может.

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


PD>А вот это еще вопрос. Мне трудно судить, я питона не знаю. В двух словах — что там такое есть, чего в С++ быть не может ?


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

Инструменты для С++ практически отсутствуют — и это факт.

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

Чем мощнее инструменты — тем больше времени высвобождается для высокоуровневых оптимизаций.

Ну а буде где затык — спокойно можно критические участки оформить хоть на С++, хоть на ассемблере.
Re[66]: пояснение о качестве
От: FR  
Дата: 08.08.10 12:42
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот когда вырастет и покажет, что умеет в 10 раз ускорять, тогда и поговорим. А пока говорить не о чем. А то, что некоторые компиляторы умеют в compile-time цикл for(i=0; i < 10; i++) k+=i; исполнять — это, конечно, очень интересно , но к серьезной разработке имеет очень небольшое отношение.


Компиляторостроители вовсю пользуются результатами таких теорий.

PD>Я для себя резюме простое сделал — полагаться на то, что ICC даст лучшие результаты, не стоит. Хотя проверить всегда надо.


Угу.

FR>>Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).


PD>Срочно перехожу на JavaScript. Он, как я понимаю, медленнее всего (если не так — скажи, что там медленнее всего, перейду на него). Пусть производители мне ресурсы увеличивают


На руби из популярных языков именно он рекордсмен

FR>>Я как раз могу, сейчас я как-раз в основном пишу на C++.


PD>То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++


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


FR>>А как же качество?


PD>Страдает и плачет горючими слезами. Но не могу же я тебе запретить писать некачественно




Написал я тут утилитку на OCaml вернее смесь С++ и Ocaml, притом C++ всего одна низкоуровневая функция каталоги
считывает через NtQueryDirectoryFile, в общем грубо она всякую статистику по файловой системе собирает.
Строит в памяти дерево и много много раз по нему бегает разными функциями. И вот на миллионах файлов смотрю жрет
она метров 500 оперативки, в общем не качественно. Решил на C++ переписать убил столько же времени сколько
на первоначальное написание и добился того что стала жрать гиг оперативки.
Да я знаю что убив еще столько же времени я доведу обратно до 500, а убив еще вдвое больше может и до 300.
Но как-то желания соревноватся с GC OCaml'а (который кстати тут недавно ругали) как-то сразу пропало.
В общем наверно я так и буду некачественно писать


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


PD>А вот это еще вопрос. Мне трудно судить, я питона не знаю. В двух словах — что там такое есть, чего в С++ быть не может ? (подчеркиваю, именно так, аргументы вроде "там есть такая навороченная библиотека, какой на С++ ты нигде не найдешь)" — не принимаются.


В любых тьюринг полных языках как и в Греции есть все.
Так что быть может, но вопрос как всегда в цене.
Re[67]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 13:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PD>>То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++


I>Чушь.


Прелесть что за аргумент.

>Числодробилки это далеко не самое главное. Это было актуально еще 10 лет назад.


У кого какие задачи, можно было бы понять.

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


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

I>А вот ускорять ввод-вывод, вводить кеширование и тд и тд — здесь уже С++ толком ничем помочь и не может.


А здесь вообще никто помочь не может. Скорость в/в определяется ОС. А кеширование почему это на С++ нельзя делать ?

I>Теоретически все что на питоне да руби может быть и на ассемблере написано.


Вот уж это вне сомнения. Хотел бы я посмотреть на нечто такое, что теоретически не может быть написано на ассемблере (то есть в командах процессора )

I>Инструменты для С++ практически отсутствуют — и это факт.


Какие ? Для задач построения сайтов — да, но никто сайты на С++ и не пишет.

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


Не согласен. Это может быть верно только в той части, на которую он заточен. Как только надо что-то нетипичное для этого языка сделать — все, плохо. Возьми тот же Linq и попробуй пройди там матрицу не по строкам и не по столбцам, а по диагоналям. Ну а мне все равно на С++.
With best regards
Pavel Dvorkin
Re[63]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 13:46
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А если уже используется ICC, как ускорить код без суперкомпиляции ?


Эта самая суперкомпиляция — скорее абстрактное теоретическое понятие, чем реально действующий механизм.

PD>>Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.


I>Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.


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

Вот, кстати, пример. Лучшие библиотеки для математики — на Фортране. Следует ли из этого что-то в пользу Фортрана или С++ ?
With best regards
Pavel Dvorkin
Re[67]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 14:08
Оценка:
Здравствуйте, FR, Вы писали:

PD>>Вот когда вырастет и покажет, что умеет в 10 раз ускорять, тогда и поговорим. А пока говорить не о чем. А то, что некоторые компиляторы умеют в compile-time цикл for(i=0; i < 10; i++) k+=i; исполнять — это, конечно, очень интересно , но к серьезной разработке имеет очень небольшое отношение.


FR>Компиляторостроители вовсю пользуются результатами таких теорий.


Пусть себе пользуются и цикл выше оптимизируют. Пока я не увижу конкретного рецепта, как я (именно я) могу ускорить пусть не в 10, а хотя бы в 2 раза — все это может быть только любопытным фактом. А вот если дашь мне ссылку на то, как это сделать реально в моей программе — я тебе тройки буду ставить ежедневно до конца года


FR>>>Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).


PD>>Срочно перехожу на JavaScript. Он, как я понимаю, медленнее всего (если не так — скажи, что там медленнее всего, перейду на него). Пусть производители мне ресурсы увеличивают


FR>На руби из популярных языков именно он рекордсмен


Заказчик только меня не поймет.

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

FR>Насчет будущего правда не так радужно новые языки как раз все больше в нишу C++ целят.

И пусть целят. Пока достаточно задействовать 10% тактовой частоты — пусть резвятся. Когда 100% потребуется задействовать — тогда посмотрим.
Чудес же не может быть. C++ — не совсем точно и не совсем верно, но можно назвать языком с нулевым оверхедом. В нем лишнее не делается, а качество кода отличается от идеального только тем, что оптимизатор все же до идеала довести не может, немного хуже. В новых языках есть оверхед — делается то, что можно не делать. JIT- компиляция, вские проверки и т.д. На это время тратится. И это неустранимо. Лучше С++ в этом плане может быть только язык, который так же, как он , дает мне полное управление, но лучше его по качеству. Тут я согласен — синтаксис и семантика С++ отнюдь не идеал.


FR>Написал я тут утилитку на OCaml вернее смесь С++ и Ocaml, притом C++ всего одна низкоуровневая функция каталоги

FR>считывает через NtQueryDirectoryFile, в общем грубо она всякую статистику по файловой системе собирает.
FR>Строит в памяти дерево и много много раз по нему бегает разными функциями. И вот на миллионах файлов смотрю жрет
FR>она метров 500 оперативки, в общем не качественно. Решил на C++ переписать убил столько же времени сколько
FR>на первоначальное написание и добился того что стала жрать гиг оперативки.

Гм... При миллионе файлов и с хранением имени файла (имена каталогов можно хранить один раз, пренебрежем) со средней длиной пусть 30-40 имеем на имена файлов 30-40 Мб. Ну пусть еще оверхед на элемент дерева, байт 16-32, это еще столько же. По идее на 1 миллион файлов можно в 100 Мб уложиться. А больше на что ?
Для 10 миллионов будет 1 Гб, меньше и не сделаешь, если только не позволить себе доступ частями (view на mmf), тут можно и в 64 Кб уложиться, но за счет скорости.


FR>Да я знаю что убив еще столько же времени я доведу обратно до 500, а убив еще вдвое больше может и до 300.


Просто я подозреваю, что ты лишнюю память захватил.

FR>Но как-то желания соревноватся с GC OCaml'а (который кстати тут недавно ругали) как-то сразу пропало.

FR>В общем наверно я так и буду некачественно писать

Пиши
With best regards
Pavel Dvorkin
Re[65]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 14:15
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PD>>Эта самая суперкомпиляция — скорее абстрактное теоретическое понятие, чем реально действующий механизм.


I>Пока что да. Не так давно оптимизирующий компилятор был теоретическим понятием.


Когда будет "нет" — тогда и обсудим. Мне программу писать надо. Если можешь сказать, как мне эту суперкомпиляцию употребить в дело — я тебе благодарен буду, а теоретические вопросы мне сейчас не нужны.

I>>>Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.


PD>>Ну и аргумент. Определять возможности языка наличием или отсутствием библиотек — ну и ну.


I>Библиотеки являются следствием из языка.


Что значит следствием ? Это вообще непонятно. Если же говорить об их наличии, то являются они частью системы программирования или берутся из других источников — какая мне разница. Для меня что вызов strcpy, что вызов GetWindowText — одно и то же.

I>Если для языка нельзя написать хороший инструмент, например, для генерации кода, то естественно и библиотек требующих генерацию кода, никогда не появится.


Ничего не понял. Вроде как такой инструмент компилятором называется.

I>Потому и не надо нести чушь про расходование ресурсов ибо "для других задач"


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

I>Вот в этих "других задач" и пользуй свой С++.


Что я и делаю. А разве я предлагал его использовать для написания сайтов ? Не предлагал и не предложу. У нас и так задач хватает.
With best regards
Pavel Dvorkin
Re[69]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 14:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PD>>У кого какие задачи, можно было бы понять.


I>Кол.во задач растет мягко говоря нелинейно.


Пусть растет как хочет. Задача задаче рознь.

I>Задачи, решение которых экономит миллиарды долларов уже давным давно не решаются на С++.


I>Всё, забудь.


Все, забыл, и закончил с тобой дискуссию. Надоело. Научись сначала корректно дискутировать.
With best regards
Pavel Dvorkin
Re[68]: пояснение о качестве
От: FR  
Дата: 08.08.10 14:32
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

FR>>Компиляторостроители вовсю пользуются результатами таких теорий.


PD>Пусть себе пользуются и цикл выше оптимизируют. Пока я не увижу конкретного рецепта, как я (именно я) могу ускорить пусть не в 10, а хотя бы в 2 раза — все это может быть только любопытным фактом. А вот если дашь мне ссылку на то, как это сделать реально в моей программе — я тебе тройки буду ставить ежедневно до конца года


А представь завтра выходит такой компилятор и все твои программы мгновенно становятся некачественными

FR>>На руби из популярных языков именно он рекордсмен


PD>Заказчик только меня не поймет.


Зато благодарные потомки тебя не забудут

PD>И пусть целят. Пока достаточно задействовать 10% тактовой частоты — пусть резвятся. Когда 100% потребуется задействовать — тогда посмотрим.


Не ты не понял под новыми языками я имел в виду действительно новые, а не шарп с явой и питоном.
Это гуглевский Go или Ржавчина
Автор: Курилка
Дата: 08.07.10
или D (хоть и не совсем новый)
Они и 99% вполне могут задействовать.

PD>Чудес же не может быть. C++ — не совсем точно и не совсем верно, но можно назвать языком с нулевым оверхедом. В нем лишнее не делается, а качество кода отличается от идеального только тем, что оптимизатор все же до идеала довести не может, немного хуже. В новых языках есть оверхед — делается то, что можно не делать. JIT- компиляция, вские проверки и т.д. На это время тратится. И это неустранимо. Лучше С++ в этом плане может быть только язык, который так же, как он , дает мне полное управление, но лучше его по качеству. Тут я согласен — синтаксис и семантика С++ отнюдь не идеал.


Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.

PD>Гм... При миллионе файлов и с хранением имени файла (имена каталогов можно хранить один раз, пренебрежем) со средней длиной пусть 30-40 имеем на имена файлов 30-40 Мб. Ну пусть еще оверхед на элемент дерева, байт 16-32, это еще столько же. По идее на 1 миллион файлов можно в 100 Мб уложиться. А больше на что ?


Там не только имена хранились еще всякая доп. информация типа размера файлов, атрибутов и хешей, набегало около 200 — 300 байт на файл. Ну и файлов было немного больше лимона.

PD>Для 10 миллионов будет 1 Гб, меньше и не сделаешь, если только не позволить себе доступ частями (view на mmf), тут можно и в 64 Кб уложиться, но за счет скорости.


Слишком медленно частями там десятки пробежок нужны.
Re[69]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 08.08.10 15:34
Оценка:
Здравствуйте, FR, Вы писали:

PD>>Пусть себе пользуются и цикл выше оптимизируют. Пока я не увижу конкретного рецепта, как я (именно я) могу ускорить пусть не в 10, а хотя бы в 2 раза — все это может быть только любопытным фактом. А вот если дашь мне ссылку на то, как это сделать реально в моей программе — я тебе тройки буду ставить ежедневно до конца года


FR>А представь завтра выходит такой компилятор и все твои программы мгновенно становятся некачественными


Вообще-то плохо представляю, потому что не понимаю, что он там такое в коде может сделать ? Перенести в compile-time вычисления, которые туда можно вынести — это детские игры. Развернуть циклы с переменной границей — это несерьезно. Машинный код , полученный от С++, близок по качеству коду, написанному на асме хорошим программистом, а уж на асме никаких суперкомпиляторов нет и не предвидится
Понимаешь, нечего тут супероптимизировать. Разве что алгоритм, но это другая песня. При данном алгоритме С++ реализация хороша.

PD>>Заказчик только меня не поймет.


FR>Зато благодарные потомки тебя не забудут




PD>>И пусть целят. Пока достаточно задействовать 10% тактовой частоты — пусть резвятся. Когда 100% потребуется задействовать — тогда посмотрим.


FR>Не ты не понял под новыми языками я имел в виду действительно новые, а не шарп с явой и питоном.

FR>Это гуглевский Go или Ржавчина
Автор: Курилка
Дата: 08.07.10
или D (хоть и не совсем новый)

FR>Они и 99% вполне могут задействовать.

Вот это серьезно. В принципе, я вовсе не адепт именно С++. Язык оставляет желать лучшего. Вот С я действительно люблю — в нем (в рамках того, что в нем есть, если не пытаться в него что-то добавить) все сделано изумительно, ни убавить, ни прибавить. А С++ — монстр, и не очень логичен, и неудачные идеи содержит (множественное наследование хотя бы). Так что если появится язык, который лучше С++ и реально будет использоваться — лично я не против перейти. Я переходил с Алгола на Фортран, с Фортрана на Паскаль, с Паскаля на С++, почему бы на старости лет еще на какой-нибудь язык не перейти ? Но мне для этого нужно, чтобы он был реально используемым, а не маргинальным направлением. Если посмотришь на список языков выше — я всегда переходил на тот язык, который был "в струе" на тот момент.

Ну а еще есть требования заказчика

PD>>Чудес же не может быть. C++ — не совсем точно и не совсем верно, но можно назвать языком с нулевым оверхедом. В нем лишнее не делается, а качество кода отличается от идеального только тем, что оптимизатор все же до идеала довести не может, немного хуже. В новых языках есть оверхед — делается то, что можно не делать. JIT- компиляция, вские проверки и т.д. На это время тратится. И это неустранимо. Лучше С++ в этом плане может быть только язык, который так же, как он , дает мне полное управление, но лучше его по качеству. Тут я согласен — синтаксис и семантика С++ отнюдь не идеал.


FR>Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.


Вообще говоря — дай-то бог.
Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.
With best regards
Pavel Dvorkin
Re[70]: пояснение о качестве
От: FR  
Дата: 08.08.10 16:17
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вообще-то плохо представляю, потому что не понимаю, что он там такое в коде может сделать ? Перенести в compile-time вычисления, которые туда можно вынести — это детские игры. Развернуть циклы с переменной границей — это несерьезно. Машинный код , полученный от С++, близок по качеству коду, написанному на асме хорошим программистом, а уж на асме никаких суперкомпиляторов нет и не предвидится


Там язык пофиг, можно и для асма http://ru.wikipedia.org/wiki/Суперкомпиляция

PD>Понимаешь, нечего тут супероптимизировать. Разве что алгоритм, но это другая песня. При данном алгоритме С++ реализация хороша.


Тык он и оптимизирует именно алгоритм под конкретные данные или группу конкретных данных.

FR>>Не ты не понял под новыми языками я имел в виду действительно новые, а не шарп с явой и питоном.

FR>>Это гуглевский Go или Ржавчина
Автор: Курилка
Дата: 08.07.10
или D (хоть и не совсем новый)

FR>>Они и 99% вполне могут задействовать.

PD>Вот это серьезно. В принципе, я вовсе не адепт именно С++. Язык оставляет желать лучшего. Вот С я действительно люблю — в нем (в рамках того, что в нем есть, если не пытаться в него что-то добавить) все сделано изумительно, ни убавить, ни прибавить. А С++ — монстр, и не очень логичен, и неудачные идеи содержит (множественное наследование хотя бы). Так что если появится язык, который лучше С++ и реально будет использоваться — лично я не против перейти. Я переходил с Алгола на Фортран, с Фортрана на Паскаль, с Паскаля на С++, почему бы на старости лет еще на какой-нибудь язык не перейти ? Но мне для этого нужно, чтобы он был реально используемым, а не маргинальным направлением. Если посмотришь на список языков выше — я всегда переходил на тот язык, который был "в струе" на тот момент.


Это да, но все-таки ты уже пропустил яву/шарп

FR>>Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.


PD>Вообще говоря — дай-то бог.

PD>Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.



Ладно давай закруглятся
Re[70]: пояснение о качестве
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.10 17:07
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вообще-то плохо представляю, потому что не понимаю, что он там такое в коде может сделать ? Перенести в compile-time вычисления, которые туда можно вынести — это детские игры.


Подумаешь, перформанс может на порядки вырасти, мелочовочка

PD>Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.


А linq чем тебе мешает ?
Re[71]: пояснение о качестве
От: Pavel Dvorkin Россия  
Дата: 09.08.10 02:21
Оценка:
Здравствуйте, FR, Вы писали:

FR>Там язык пофиг, можно и для асма http://ru.wikipedia.org/wiki/Суперкомпиляция


Ладно, хватит о ней. Пусть из пеленок выйдет

PD>>Понимаешь, нечего тут супероптимизировать. Разве что алгоритм, но это другая песня. При данном алгоритме С++ реализация хороша.


FR>Тык он и оптимизирует именно алгоритм под конкретные данные или группу конкретных данных.


Ох, плохо я что-то верю.

PD>>Вот это серьезно. В принципе, я вовсе не адепт именно С++. Язык оставляет желать лучшего. Вот С я действительно люблю — в нем (в рамках того, что в нем есть, если не пытаться в него что-то добавить) все сделано изумительно, ни убавить, ни прибавить. А С++ — монстр, и не очень логичен, и неудачные идеи содержит (множественное наследование хотя бы). Так что если появится язык, который лучше С++ и реально будет использоваться — лично я не против перейти. Я переходил с Алгола на Фортран, с Фортрана на Паскаль, с Паскаля на С++, почему бы на старости лет еще на какой-нибудь язык не перейти ? Но мне для этого нужно, чтобы он был реально используемым, а не маргинальным направлением. Если посмотришь на список языков выше — я всегда переходил на тот язык, который был "в струе" на тот момент.


FR>Это да, но все-таки ты уже пропустил яву/шарп


Почему ? Я писал на Яве, писал на шарпе (без linq), мне за это платили. Конечно, я в них лишь дилетань, не более.

FR>>>Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.


PD>>Вообще говоря — дай-то бог.

PD>>Скажу более. Если бы в свое время MS сделала неуправляемую версию C# с хорошим оптимизирующим компилятором, и убрав , конечно, оттуда барское презрение к неуправляемому коду (указатели те же) — я бы предпочел ее C++. Как язык — безусловно лучше. Правда, до 3 версии — пока туда не стали linq пихать. Но его можно и не использовать в конце концов.

FR>


FR>Ладно давай закруглятся


With best regards
Pavel Dvorkin
Re[13]: Помогает ли Linq сделать код понятнее или быстрее?
От: Mamut Швеция http://dmitriid.com
Дата: 09.08.10 07:06
Оценка:
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% случаев находится по ту сторону монитора . собственно, это я и пытаюсь сказать.


Узкое место в программе чаще всего находится не там, где думает программист. Профайлер спасет отца.


dmitriid.comGitHubLinkedIn
Re[12]: Помогает ли Linq сделать код понятнее или быстрее?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.10 08:43
Оценка:
Здравствуйте, gandjustas, Вы писали:

K>>Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?


G>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.


А у меня вышло 160 и 290 мс
Re[13]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.08.10 08:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


K>>>Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?


G>>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.


I>А у меня вышло 160 и 290 мс


Я в цикле сделал i<array.Length
Re[14]: Помогает ли Linq сделать код понятнее или быстрее?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.10 08:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.


I>>А у меня вышло 160 и 290 мс


G>Я в цикле сделал i<array.Length


У меня тож самое. Интересно, почему такая разница с Sum. Что у тебя за проц-фреймворк ? У меня 4й фреймворк, Core 2 Quad Q9300 2.5 гц
Re[15]: Помогает ли Linq сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.08.10 09:02
Оценка:
Здравствуйте, 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 сделать код понятнее или быстрее?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.10 09:07
Оценка:
Здравствуйте, 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 сделать код понятнее или быстрее?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.08.10 09:10
Оценка:
Здравствуйте, 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 сделать код понятнее или быстрее?
От: March_rabbit  
Дата: 09.08.10 13:43
Оценка:
Здравствуйте, 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 сделать код понятнее или быстрее?
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 12.08.10 17:03
Оценка:
Здравствуйте, anton_t, Вы писали:

_>Упорядоченный массив — это массив, в котором все элементы расположены по порядку. Очевидно, что для пустого массива это выполняется.


Заметим, что обратное условие также выполняется Так что это таки вопрос соглашения.
[КУ] оккупировала армия.
Re[14]: Помогает ли Linq сделать код понятнее или быстрее?
От: Vamp Россия  
Дата: 12.08.10 19:33
Оценка:
M>А вот ставить задачи надо правильно. Меня поражает это «вдруг» в рассуждениях. «Вдруг» количество строчек перевалило за 10 000. «Вдруг» количество запросов стало большим.
Vitas совершенно прав, а ты нет. Я лично ускорял программу, в которой такой же, как ты, перец использовал сортировал списки списков копированием. Несколько лет назад там было 10 списков по десять элементов, а спустя пару лет стало сто по сто (условно, порядок именно такой). И все, приплыли — стоп машина, юзеры рвут и мечут, девелоперы в мыле ищут баги и фиксят.
Такой же как ты, наверное, писал — а что тьам считать милисекунды...
Да здравствует мыло душистое и веревка пушистая.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
От: anton_t Россия  
Дата: 13.08.10 02:24
Оценка:
Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, anton_t, Вы писали:


_>>Упорядоченный массив — это массив, в котором все элементы расположены по порядку. Очевидно, что для пустого массива это выполняется.


K>Заметим, что обратное условие также выполняется Так что это таки вопрос соглашения.


Неупорядоченный массив — массив, в котором существуют элементы, расположенные не по порядку. Очевидно, что для пустого массива это не выполняется.
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
От: FR  
Дата: 13.08.10 03:34
Оценка:
Здравствуйте, anton_t, Вы писали:


_>Неупорядоченный массив — массив, в котором существуют элементы, расположенные не по порядку. Очевидно, что для пустого массива это не выполняется.


Математики все еще до нас украли:

Определение 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 сделать код понятнее или быстрее?
От: midcyber
Дата: 13.08.10 04:03
Оценка:
Здравствуйте, Vamp, Вы писали:

M>>А вот ставить задачи надо правильно. Меня поражает это «вдруг» в рассуждениях. «Вдруг» количество строчек перевалило за 10 000. «Вдруг» количество запросов стало большим.

V>Vitas совершенно прав, а ты нет. Я лично ускорял программу, в которой такой же, как ты, перец использовал сортировал списки списков копированием. Несколько лет назад там было 10 списков по десять элементов, а спустя пару лет стало сто по сто (условно, порядок именно такой). И все, приплыли — стоп машина, юзеры рвут и мечут, девелоперы в мыле ищут баги и фиксят.
V>Такой же как ты, наверное, писал — а что тьам считать милисекунды...

Ты как будто через очки в сеточку читаешь =)
Если в ТЗ несколько лет назад было написано 10х10, то это проблема писавшего ТЗ, который не подумал, что скоро надо будет 100х100.
Вот когда будут ресурсы неограниченными — тогда и будем предварительно оптимизировать все, что движется.
А пока — одни будут получать премии за то, что выкатили рабочую версию в срок, а другие — за то, что ускорили потом в 10 раз.
Вроде как, выгодно всем
Re[16]: Помогает ли Linq сделать код понятнее или быстрее?
От: enji  
Дата: 25.08.10 05:32
Оценка:
Здравствуйте, midcyber, Вы писали:

M>Если в ТЗ несколько лет назад было написано 10х10, то это проблема писавшего ТЗ, который не подумал, что скоро надо будет 100х100.

Вы издеваетесь? Более менее нормальное ТЗ — жуткая редкость; детальное ТЗ, где описано макс кол-во элементов — еще большая редкость. Обычно такие моменты оставляют на откуп программиста.

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

M>А пока — одни будут получать премии за то, что выкатили рабочую версию в срок, а другие — за то, что ускорили потом в 10 раз.

M>Вроде как, выгодно всем

Эт да
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.