Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>>>На C++ это будет удобно (читай надо писать свой аллокатор)? CC>>>Да. G>>Ты все еще веришь что каждый программист на С++ способен написать аллокатор? CC>Я способен. CC>А ты веришь, что каждый программист может написать .NET runtime или .NET framework? Но кто то его написал а остальные пользуются.
Ты сравниваешь теплое с мягким, .NET FW — универсальное средство, а тут речь идет о специализированном аллокаторе на C++.
G>>>>Фактически это будет удобно только на С. CC>>>И С++ G>>Не выдавай желаемое за действительное CC> Ты мне будешь рассказывать что и как в С++?
Ты сам влез в разговор и пытаешь доказать непонятно что.
Я и так знаю что ты можешь написать аллокатор, и также знаю, что большая часть местных приплюснутых этого сделать не смогут.
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
K>Это плохой код. Хорошая практика — это писать с использованием комбинаторов из стандартной библиотеки. Для ml-подобных языков правильным решением будет, например, такое
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, Вы писали:
FR>>Ну и мирок твой куда-то в сторону перла вытягивается
SC>Зачет-незачет. Мирок не мой, а ваш, профессор, и куда он там вытягивается, вам виднее.
Сам ты нудный я еще шутник.
Re: Помогает ли Linq сделать код понятнее или быстрее?
В данном случае не помогает из-за недостатка подходящего комбинатора в стандартной комплектации; там вообще слишком мало комбинаторов, и названия не у всех интуитивны.
Разве ж это не просто и понятно? "Последовательность элементов возрастает, если для всех пар смежных элементов предыдущий элемент меньше или равен следующему". Это буквальная запись на языке программирования предыдущего предложения. Программа приближается к естественному языку. Вместо подробностей конкретного способа решения задачи (таких, как цикл обхода массива, временная переменная, выход из цикла по выполнению условия), из которых смысл производимых действий приходится реверсивно восстанавливать, ты непосредственно этот смысл выражаешь в коде.
Насчет быстрее — это другой вопрос. Это до такой степени банально, что мне даже странно про это говорить. Давно уже всем известно, что главный параметр, требующий оптимизации в программировании — это затраты на разработку, и если было бы иначе, то и самого дотнета бы не существовало. Таких программ, в которых требуется оптимизировать каждый участок кода, просто не бывает. С точки зрения теории алгоритмов с этим кодом все нормально, так как сложность у него ровно такая же, как и у цикла.
Собрался ставить минус? Да сам иди в жопу!
.
Re: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, 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 сделать код понятнее или быстрее?
Здравствуйте, 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 сделать код понятнее или быстрее?
Что же, это хорошо и тогда тем более. Но поддержка mmf не может быть лучше чем в Win API — просто через него все идет. Судить, впрочем, не буду — не знаком с питоном.
FR>Тем более по скорости питон уже бьет и C++ и яву http://www.rsdn.ru/forum/flame.comp/3902202.flat.aspx#3902202
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Pavel Dvorkin, Вы писали:
G>>>На C# это будтет удобно? PD>>Есть там поддержка mmf или нет? MM>Да есть, есть: MemoryMappedFile Class.
Ну вот и отлично. Хотя и забавная реализация — сделать полтора десятка overload методов на 2 функциях Win API — это уметь надо!
With best regards
Pavel Dvorkin
Re[18]: Помогает ли Linq сделать код понятнее или быстрее?
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[19]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, 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[20]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, gandjustas, Вы писали:
G>Ты уже забыл с чего начался разговор? G>Итак есть потенциально бесконечный поток данных и надо его как-то обрабатывать. G>Можно обрабатывать как последовательность (с помощью Linq), не сохраняя в памяти, потому что сохранять в памяти это лишние затраты.
Ох! Ну когда вы наконец поймете, что Ваш linq строит промежуточные структуры, которые вы не видите, и они занимают место. Чудес не бывает.
Не согласен ? OK. На тебе задачу — принять откуда угодно массив и отсортировать его. Хоть с linq, хоть императивно, хоть духом святым. Только, как ты сказал, не сохраняя массив в памяти . Дисковой тоже, конечно.
G>Ты же сказал что можно зарезервить большой кусок и коммитить при необходимости для минимизации затрат (оставим обсуждение характеристик такого подхода за кадром). Это значит что надо все создаваемые объекты размещать в этой области.
и метод map позволяет отмэппить любой кусок файла — так же, как в Win32. После чего туда можно писать.
G>Я же тебе сказал что это кроме как в C будет очень тяжело сделать. Ты начал спорить и привел не относящийся к делу кусок на java.
Ты просил показать кусок на Яве, где я эти channel использую. Я тебе привел. Я не телепат, чтобы знать, что именно тебе надо
G>Кстати резерв большого куска и коммит по необходимости сродни работе GC.
Точнее, GC может выделить память таким почти образом (но все же не через mmf, а через VirtualAlloc), ну а все остальное к делу не относится.
G>>>Моя конкретная мысль: исполнитель доволен, заказчик доволен — значит это была хорошая работа.
PD>>Ну а моя конкретная мысль — если исполнитель доволен тем, что пользуясь некомпетентностью заказчика, всучил ему продукт низкого качества, и при этом заказчик доволен, так как не знает, какого качества тут можно достигнуть, если сделать как следует — это и есть халтура.
G>Вообще-то почти любой заказчик знает чего он хочет, особенно к концу проекта.
Неспециалист в какой бы то ни было области не может знать, что в ней возможно. Он может лишь принимать то, что ему сделают специалисты или "специалисты". А когда таких "специалистов" много и все они делают одинаково "качественный" продукт — неспециалисту крайне трудно понять, что это халтура.
With best regards
Pavel Dvorkin
Re[21]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, 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[22]: Помогает ли Linq сделать код понятнее или быстрее?
PD>Неспециалист в какой бы то ни было области не может знать, что в ней возможно. Он может лишь принимать то, что ему сделают специалисты или "специалисты". А когда таких "специалистов" много и все они делают одинаково "качественный" продукт — неспециалисту крайне трудно понять, что это халтура.
Неспециалисту очень легко понять, что то халтура. У нас заказчики просто оперируют понятиями «неудобно» и «медленно». Все. Этого достаточно
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну вот и отлично. Хотя и забавная реализация — сделать полтора десятка overload методов на 2 функциях Win API — это уметь надо!
Ввиду отсутствия значений аргументов по-умолчанию, это обычная практика для дотнета — плодить комбинаторные комбинации одной и той же перегрузки ф-ии с разным кол-вом и составом аргументов.
Re[20]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну вот и отлично. Хотя и забавная реализация — сделать полтора десятка overload методов на 2 функциях Win API — это уметь надо!
V>Ввиду отсутствия значений аргументов по-умолчанию, это обычная практика для дотнета — плодить комбинаторные комбинации одной и той же перегрузки ф-ии с разным кол-вом и составом аргументов.
Я знаю. Просто забавно — сколько можно методов сделать на базе всего-то 2 функций.
Ты мне будешь рассказывать что и как в С++?
