В этой ветке речь шла не о том, а о трудностях передачи уровня рекурсии в рекурсивную функцию.
И передавать параметр в хвостовую рекурсию не я собирался :P
Я просто обращаю внимание на то, что этот аргумент не состоятелен, так как такой тип рекурсии легче всех прочих раскрыть вручную. Не касаясь других типов рекурсии.
Если вы не знаете, будет ли развёрнута рекурсия — проще развернуть сразу вручную. Благо делается это тривиально: оборачиваем всё в цикл и перезаписываем значения переменных новыми в конце итерации.
А зачем в хвостовую рекурсию протаскивать глубину, если она будет развёрнута? Если же она развёрнута не будет — то и дополнительный индекс ни на что, кроме максимальной глубины, не повлияет.
Хм. Это уже интересней. Хотя 3 радиатора всё равно на месте. Хотя всё это всё равно увеличивает вес головки и требует более прочной рамы.
Насколько я вижу у этого варианта из плюсов:
— намного проще синхронизация
— нет сложной механики
из минусов
— дополнительный вес на подвесе
— количество цветов ограниченно числом каналов в головке
Насколько я вижу — принцип действия разных. По вашей — 1 головка с несколькими нагревателями для разных нитей и 1м соплом, что позволяет не перепозиционировать печатующую головку при смене цвета.
Здесь же — устройство, разрезающее и сплавляющее несколько нитей в одну цветную. При этом в самом принтере нужен только 1 нагревательный элемент и много много синхронизации. Кстати, довольно очевидная идея, первая (и единственная), что пришла в голову для многоцветной печати одной головкой.
В любом случае, всегда можно попробовать эмулировать рекурсию: создать стек в куче и складывать туда старые значения переменных вместо ухода в глубь рекурсии. Это попрежнему будет есть память, но, по крайней мере, это будет память кучи а не стека.
Почему бы не сделать это на карте? Сейчас там происходит нечто непонятное — выделяются какие-то блоки, возможно просто стандартная подсветка браузера. Что оно символизирует — я так и не понял.
Как мне прокрутить страницу мышью. Скролбар я могу схватить мышью и тягать его вверх-вниз плавно переходя между разными частями страницы. Как сделать аналогичное действие вашим контролом?
От этого никто не застрахован. Стандарт может быть не соблюдён вне зависимости от качества кода. Но всё таки лично для меня при выборе библиотеки из множества вариантов качество кода выступает первым фильтром. Фанатизмом не страдаю, но откровенный говнокод не возьму.
К сожалению нет. Я бы попробовал Skyforge, хотя бы просто из любопытства, что же у вас получилось. Но останавливает меня именно то, что разработчик и паблишер — mail.ru.
Вы пишете отличные технические, соглашусь, но практика с ArchAge показывает, что ничего не изменилось. И это печально.
> Хороший код может содержать больше багов, чем плохой
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
> Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
Я тоже руководствовался этим ответом, но надо бы декомпилировать System.Numerics. Я этого не сделал из-за того, что рефлектор с первого раза неймспейс не подцепил :)
Я пытался параллелить только корень, но это уже даёт 100% загрузку процессора. В идеале, распаралеливание, на 4 потока может дать только 4х кратный прирост.
Узким местом, впрочем, оказалось умножение последнего элемента — при любая финальной комбинация вызывается за 0.54 секунды
Собственно вот (однократная проверка, быстродействие, по наблюдениям, плавает в пределах 5%):
C# использует алгоритм Карацубы для умножения длинных чисел.
Но умножение, как мне показалось, реализовано крайне неэффективно. Собственно, тот же битовый сдвиг даёт прирост скорости почти в 2 раза для финальной операции. Собственно большенство плясок там именно вокруг этого.
Для того, чтобы скомпилировать код можно обойтись одним .NET Framework'ом, но лучше — какую-нибудь Visual Studio с поддержкой C#. Скинуть код смогу только этак в 22:00 МСК
А как этот фреймворк параллелит длинное умножение? Мне просто интересно, откуда 20ти кратный прирост, что я упустил
И не смогли бы вы запустить на вашей машине оригинальный код?
Измерить время можно с помощью System.Diagnostics.Stopwatch. Либо я могу скинуть тестовый код
И передавать параметр в хвостовую рекурсию не я собирался :P
Я просто обращаю внимание на то, что этот аргумент не состоятелен, так как такой тип рекурсии легче всех прочих раскрыть вручную. Не касаясь других типов рекурсии.
То есть — это не часть библиотеки? Тогда я записываюсь в список противников :)
Насколько я вижу у этого варианта из плюсов:
— намного проще синхронизация
— нет сложной механики
из минусов
— дополнительный вес на подвесе
— количество цветов ограниченно числом каналов в головке
Здесь же — устройство, разрезающее и сплавляющее несколько нитей в одну цветную. При этом в самом принтере нужен только 1 нагревательный элемент и много много синхронизации. Кстати, довольно очевидная идея, первая (и единственная), что пришла в голову для многоцветной печати одной головкой.
Вы пишете отличные технические, соглашусь, но практика с ArchAge показывает, что ничего не изменилось. И это печально.
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
Мне на await/async удалось получить ускорение порядка 3.5 раза на 4х ядрах, но там есть пара извращений.
Узким местом, впрочем, оказалось умножение последнего элемента — при любая финальной комбинация вызывается за 0.54 секунды
Собственно вот (однократная проверка, быстродействие, по наблюдениям, плавает в пределах 5%):
2-25000: 00:00:00.2458574 // thread 1
25001-50000: 00:00:00.3246583 // thread 2
finalizing: 00:00:00.5395141
total: 00:00:00.8882113
C# использует алгоритм Карацубы для умножения длинных чисел.
Но умножение, как мне показалось, реализовано крайне неэффективно. Собственно, тот же битовый сдвиг даёт прирост скорости почти в 2 раза для финальной операции. Собственно большенство плясок там именно вокруг этого.
Для того, чтобы скомпилировать код можно обойтись одним .NET Framework'ом, но лучше — какую-нибудь Visual Studio с поддержкой C#. Скинуть код смогу только этак в 22:00 МСК
И не смогли бы вы запустить на вашей машине оригинальный код?
Измерить время можно с помощью System.Diagnostics.Stopwatch. Либо я могу скинуть тестовый код
У меня получилось вот так:
Naive
2,214s
Tree
1,118s
OptimizedThreading
0,273s
Время — среднее за 10 проходов, каких-то исключительных пиков не наблюдалось в отдельных методах
Система — Core i5 2500, Win7 x64
Другими словами — мне дописывать статью, или уже бессмысленно? :)