Конкретно этот шейдер написан за пару ночей, он несложный. Но до этого я целый месяц пытался понять, почему не получается вставить код из демки nVidia, и в конце концов просто сделал с нуля так, как сам понял.
Теперь уже честное PCSS, 48 выборок, Poisson Disk. Добавил немножко дизеринга туда, где не хватает выборок. На белом фоне сильно заметно, но с текстурами будет не особо. Была мысль, как сделать переходы плавнее, скрестив две техники, но не получилось, нужно было сделать больше выборок, были артефакты… В данном алгоритме, который на Гифке, моя собственная реализация PCSS, из примера nVidia я взял только координаты для poisson disk, а в остальном разобраться так и не смог (особенно зачем нужны функции ddx и ddy, там так намудрили, что жесть), поэтому сделал вот такой велосипед. Выборки делал через Sampler.Load, по-другому не выходило (Юнити по умолчанию настроил теневую выборку, лукап делать с помощью стандартного Sample не получалось… может быть, работать из-за этого будет чуть медленнее, а может, и нет, у меня вроде нормально отрисовывается). С Cubemap Pointlight тенями такой проблемы не было, там обыкновенные выборки. Пока сделал только под DirectX, а с OpenGL ещё надо повозиться. Также на гифке можно заметить косяки, которые я надеюсь исправить.
[Benchmark]
public int LinkedListFor()
{
var local = linkedList;
int sum = 0;
var node = local.First;
for (int i = 0; i < local.Count; i++)
{
checked
{
sum += node.Value;
node = node.Next;
}
}
return sum;
}
А работает почему-то гораздо быстрее, чем foreach.
В примере не for, а вообще ручное копированое без проверок, но вкрадце — другие ассемблерные команды, которых получается меньше, и они работают быстрее. В C# так сильно не углублялся и даже не знаю, есть ли подобные оптимизации в этом языке, но почему бы и нет?
А зачем вообще вставлять в начало последовательного массива? Кто вообще будет так поступать? Обычно последовательность элементов вообще не имеет значения, перебирать ведь так или иначе придётся сразу все. Насчёт удаления из списка — тут тоже честное удаление не требуется, достаточно прописать в элементе «флаг» deleted=true, и просто пропускать его при переборе, а после N-ного числа удалений, так уж и быть, подчищать их. Ясное дело, что это заковыкистые хитрости, которые усложняют читабельность кода, но уж извините, оптимизации — они такие и есть. Их применяют с умом. И если тестировать самый неудачный вариант применения динамического массива, то какой прок от такого тестирования, если это по сути тест на криворукость?
Реакция после прочтения: «Какого *#$?!». Последняя табличка выморозила даже не тем, что перебор последовательного массива гораздо быстрее перебора связного списка. Как бы так и должно быть, свои плюсы и минусы, свои цели. Вымораживает то, что встроенная в язык команда foreach оказалась в 2 два раза медленнее конструкции for! Как так вообще произошло?! В какой день рухнул мир?! (а уж про Sum() и говорить страшно, только покрутить пальцем у виска)
Я не фанат Винды, она мне попила много крови, и мне тоже нравится Мак (некоторое время работал на нём, сложил представление, хотя дома такового не имею). Подкупает плавность интерфейса и надёжность… в смысле, сторонний софт глючит гораздо реже… всё же в Маках — одно и то же железо (Intel+nVidia), моделей не так уж и много, можно хорошенько протестировать и оптимизировать. И даже несмотря на это, всё же скажу пару слов в пользу Виндоуза. У Виндоуза главная проблема в том, что он установлен на компьютерах самых разных конфигураций, на нём много стороннего софта, ради которого соблюдается обратная совместимость, а это значит, что если кардинально закрыть какие-то дыры в безопасности, то половина программ перестанет работать, поэтому аккуратно и малоэффективно латаются мелкие дырочки в уже имеющейся системе, по этой причине выходят тысячи обновлений, но многие программы не только сами по себе работают нестабильно, но и подрывают работу системы. Очень много зловредных программ — не вирусов, но тормозных рекламных приложений, которых даже антивирусы не ловят, для них нужен другой софт. Наконец, Виндоузом пользуется подавляющее большинство людей, в их числе — криворукие ретарды. Это не 100-процентная отмазка, т.к. те же криворукие ретарды не смогли бы сломать Мак так быстро, как Виндоуз (учитывая недостатки самого Виндоуза, которые тоже есть, что уж там). Но всё-таки я сомневаюсь в том, что, если бы не наглая ценовая политика Эппла, многие выбрали бы именно Мак. Не выбрали бы. На Винде больше игр, старых и новых, на ней отличная обратная совместимость и, наконец, поддержка железа от АМД, и ещё возможность впихнуть в системник столько памяти/видеокарт, сколько захочется, тогда как Маки — это моноблоки не с самым производительным железом.
>> Как хорошо, что я на Маке!
>> Забыл про Life CD, вирусы и прочий гемор. Иногда правда просят винду переустановить или на 10-ку обновить, тогда еще раз убеждаюсь что винда не для работы, а для Гиков
Тупанул с утра. Понял так, что на Маке тоже выскакивают просьбы обновиться до 10 Виндоуза… ужаснулся. Но потом перечитал и понял, что «просят» — в смысле, «знакомые просят».
Мак — это, конечно, хорошо и прекрасно. Рад за вас. Но по поводу переустановок — сочувствую. Переустанавливать винду — это такое мерзкое занятие, очень его не люблю. Предпочитаю поправлять другам систему руками, уходит в худшем случае часок-другой, примерно, как и на переустановку Винды. Но по крайней мере не остаётся осадка, что я поступил не по чести и снёс систему по просьбе человека, который даже эту наитупейшую операцию не может проделать. Несколько раз ну уж очень сильно уговаривали переустановить, так и быть, делал, но чувствовал себя при этом ужасным вандалом и доисторической макакой, которую заставили чинить сантехнику. Хорошо, что в наше время система сама периодически архивирует системный диск
По поводу Теслы и старых типов аккумуляторов есть версия. Видимо, огромный аккумулятор нового поколения с ёмкостью для автомобиля обойдётся слишком уж дорого. Это как покупать SSD для хранения терабайтов кинца.
Вот именно. Я даже больше скажу, сейчас в плане домашних задач вообще подзабили на производительность. Многие пользуются ноутбуками и телефонам только для интернета, но странички так и так грузятся с пингом, так чего заморачиваться. Можно воткнуть процессор в 1 гигагерц, будет работать, и ладно. А в игрушках всё, что можно, перекладывается на видеокарту. Пусть на процессоре всё равно оставляют кое-какие задачи, и при большой частоте кадров процессор тоже нагружается достаточно сильно, но только при условии, что видеокарта способна это число кадров выдавать, и то остаётся какой-то резерв… По поводу конвертации/рендеринга видео, обработке данных и т.д… — процессор тут ну вообще не конкурент. Всё, высказался :)
>> Частоты ядер не растут. Уперлись в технологический предел.
>> память быстрее не становится.
Это можно считать проблемой только при взглядах, устаревших уже лет десять назад. Раньше люди использовали ассемблерные вставки в код, чтобы выжать всё из медленного одноядерного процессора, только об этом и думали. А сейчас для этой же цели используются мютексы, атомарные операции и прочие головоломные штучки, позволяющие использовать как можно бОльший ресурс имеющихся процессорных ядер. Головоломных в плане последствий, подводных камней и всего прочего, для чего нужно применять смекалку. Ассемблерные вставки тоже надо использовать (ради SSE и подобных штук), но польза от этого будет не столь высокой, сколь от распараллеливания, поэтому можно даже и не заморачиваться (хотя лучше, конечно, заморочиться). Короче, проблемы технологического предела известны давно, но сейчас просто стоит думать совсем о другом и жить сегодняшним днём, применяя имеющиеся инструменты и оптимизировать программу так, чтобы ни скорость доступа к оперативной памяти, ни максимальная частота одного ядра не вызывали проблем. Память — да, одна, но у каждого ядра есть собственный кэш, который с годами пухнет и пухнет, а это хороший простор для манёвров.
Вот именно, что React — это в корне новый подход, ради него придётся все старые сайты переделывать.
Чтобы добавить красивую анимашку на классический портал, JQuery — идеальный вариант (хотя сейчас актуальнее анимашки в CSS, влияние JQuery можно свести к минимуму)
Я голосовал за бумажную книгу, т.к. сам люблю именно бумажные книги. По мне, инфа быстре усваивается, когда есть просто бумага, когда нет отвлекающих факторов в виде всяких извещений-оповещений и просто заманчивых иконок. Чем больше хороших книг, тем лучше.
Хотя сам я JQuery уже пользовался, тупо нашёл примеры на форумах и впилил на сайт :) В этом плане всё легко и понятно (JQuery для простоты-интуитивности, видимо, и создан). А глубже копать неохота, есть куча готовых библиотек, в которых достаточно только стили сменить. Так что сам покупать книги по JQuery не стану.
Может, это и в личку стоило послать, как багфикс, но уж слишком пространные у меня тут размышления, поэтому решил оставить у всех на виду. Может, кто-то будет со мной не согласен, предложит свои варианты. Статейка-то хорошая, коротко, по делу, и есть ссылки на более подробную инфу, но тем не менее не нужно недооценивать желание некоторых читателей вырывать из контекста слова, поэтому советую всё же присмотреться к упомянутым мной формулировкам, дабы до некоторых читателей лучше дошёл посыл :)
Придерусь к формулировкам, не более. Не ради критики или собственного ЧСВ, я не собираюсь спорить с автором… вы всё пишете правильно. Просто хочется помочь вам уточнить изложение мыслей в паре мест… сугубо по вашему желанию.
продумайте как можно с минимальным количеством классов, достигнуть максимального результата
Не совсем хорошо написано. Можно ведь вообще сделать один огромный неуклюжий класс, который никуда не сопроводишь и повторно нигде не используешь :) Понятно, что вы имели в виду именно более простую архитектуру, но не в числе классов ведь дело (поменять слово «класс» на «сущность»?). Тем более, далее по тексту у вас высказана противоположная мысль, показывающая, что вы как раз со мной согласны:
Некоторые части функционала можно вынести в отдельные классы, что даст возможность использовать их повторно
Вот-вот, всё же лучше будет больше классов, но лаконичных, типа вспомогательных или интерфейсов, но каждый из них будет независим и прост.
Слишком много параметров в методе (некоторые расчеты можно сделать внутри метода, используя внутренние константы, значения полученные с атрибутов и геттеров)
Как-то конкретно в коде PHP от этого не уйдёшь :( В итоге приходится передавать целые структуры данных в виде ассоциативных массивов, а конкретно — от backend во frontend. Но поскольку у всех элементов backend есть frontend, таких передач данных очень и очень много. Весь frontend на этом зиждется :(
Классы, содержащие одинаковые переменные и методы. Проблему можно решить через создание дополнительного класса)
Этого я вообще не понял, если честно :( Хотелось бы формулировку поточнее. Одинаковые переменные — внутри класса? Или одинаковые в том и в другом классе, и нужно вынести их и из первого, и из второго, в новый третий класс? Ну хоть убейте, не понял :(
Я читал то ли «Чистый код», то ли «Совершенный код», не помню, да и есть ли особая разница. Вещи банальные, но такому любителю, как я, открыли глаза. Как-то до этого я больше задумывался о лихости оптимизаций и хитрости алгоритмов, но когда прочёл, то понял, почему, когда я пытаюсь наваять что-то серьёзное, это тонет в багах и превращается в разлапистое Ктулху.
Хорошо, что у профессионалов слово «рефакторинг» — обыденное и ходовое. Но блин… заглядывал в код к людям, которые зарабатывают этим на жизнь, и возникает ощущение, что слова с делами частееенько расходятся :(
А работает почему-то гораздо быстрее, чем foreach.
http://stackoverflow.com/questions/4544804/in-what-cases-should-i-use-memcpy-over-standard-operators-in-c
В примере не for, а вообще ручное копированое без проверок, но вкрадце — другие ассемблерные команды, которых получается меньше, и они работают быстрее. В C# так сильно не углублялся и даже не знаю, есть ли подобные оптимизации в этом языке, но почему бы и нет?
>> Забыл про Life CD, вирусы и прочий гемор. Иногда правда просят винду переустановить или на 10-ку обновить, тогда еще раз убеждаюсь что винда не для работы, а для Гиков
Тупанул с утра. Понял так, что на Маке тоже выскакивают просьбы обновиться до 10 Виндоуза… ужаснулся. Но потом перечитал и понял, что «просят» — в смысле, «знакомые просят».
Мак — это, конечно, хорошо и прекрасно. Рад за вас. Но по поводу переустановок — сочувствую. Переустанавливать винду — это такое мерзкое занятие, очень его не люблю. Предпочитаю поправлять другам систему руками, уходит в худшем случае часок-другой, примерно, как и на переустановку Винды. Но по крайней мере не остаётся осадка, что я поступил не по чести и снёс систему по просьбе человека, который даже эту наитупейшую операцию не может проделать. Несколько раз ну уж очень сильно уговаривали переустановить, так и быть, делал, но чувствовал себя при этом ужасным вандалом и доисторической макакой, которую заставили чинить сантехнику. Хорошо, что в наше время система сама периодически архивирует системный диск
>> память быстрее не становится.
Это можно считать проблемой только при взглядах, устаревших уже лет десять назад. Раньше люди использовали ассемблерные вставки в код, чтобы выжать всё из медленного одноядерного процессора, только об этом и думали. А сейчас для этой же цели используются мютексы, атомарные операции и прочие головоломные штучки, позволяющие использовать как можно бОльший ресурс имеющихся процессорных ядер. Головоломных в плане последствий, подводных камней и всего прочего, для чего нужно применять смекалку. Ассемблерные вставки тоже надо использовать (ради SSE и подобных штук), но польза от этого будет не столь высокой, сколь от распараллеливания, поэтому можно даже и не заморачиваться (хотя лучше, конечно, заморочиться). Короче, проблемы технологического предела известны давно, но сейчас просто стоит думать совсем о другом и жить сегодняшним днём, применяя имеющиеся инструменты и оптимизировать программу так, чтобы ни скорость доступа к оперативной памяти, ни максимальная частота одного ядра не вызывали проблем. Память — да, одна, но у каждого ядра есть собственный кэш, который с годами пухнет и пухнет, а это хороший простор для манёвров.
Чтобы добавить красивую анимашку на классический портал, JQuery — идеальный вариант (хотя сейчас актуальнее анимашки в CSS, влияние JQuery можно свести к минимуму)
Хотя сам я JQuery уже пользовался, тупо нашёл примеры на форумах и впилил на сайт :) В этом плане всё легко и понятно (JQuery для простоты-интуитивности, видимо, и создан). А глубже копать неохота, есть куча готовых библиотек, в которых достаточно только стили сменить. Так что сам покупать книги по JQuery не стану.
Не совсем хорошо написано. Можно ведь вообще сделать один огромный неуклюжий класс, который никуда не сопроводишь и повторно нигде не используешь :) Понятно, что вы имели в виду именно более простую архитектуру, но не в числе классов ведь дело (поменять слово «класс» на «сущность»?). Тем более, далее по тексту у вас высказана противоположная мысль, показывающая, что вы как раз со мной согласны:
Вот-вот, всё же лучше будет больше классов, но лаконичных, типа вспомогательных или интерфейсов, но каждый из них будет независим и прост.
Как-то конкретно в коде PHP от этого не уйдёшь :( В итоге приходится передавать целые структуры данных в виде ассоциативных массивов, а конкретно — от backend во frontend. Но поскольку у всех элементов backend есть frontend, таких передач данных очень и очень много. Весь frontend на этом зиждется :(
Этого я вообще не понял, если честно :( Хотелось бы формулировку поточнее. Одинаковые переменные — внутри класса? Или одинаковые в том и в другом классе, и нужно вынести их и из первого, и из второго, в новый третий класс? Ну хоть убейте, не понял :(
Хорошо, что у профессионалов слово «рефакторинг» — обыденное и ходовое. Но блин… заглядывал в код к людям, которые зарабатывают этим на жизнь, и возникает ощущение, что слова с делами частееенько расходятся :(