Ой

r/reduce conj {}

cpu 20%

На глаз стало быстрее, но все равно недостаточно

Да. Прирост однозначно есть, но незначительный

Нормальная же программа должна обрабатывать такое поле в риалтайм? А то у меня в среднем 3-4 кадра в секунду

Попробовал pmap, почему-то лучше не стало

Сейчас подумал, что это могут быть проблемы отрисовки

каких-нибудь тайп хинтов расставь может возле интежеров в координатах

еще можно (но не уверен) 1 трансдюсер сделать в game-step из r/map и r/filter, чтобы промежуточная коллекция не создавалась

Сравнил разные варианты, самый быстрый это с reducers

Затем пмап, а за ним фор, в конце с мапами вместо форов

https://www.youtube.com/watch?v=iQwQXVM6oiY - в этой презентации кладезь информации на тему “где подкрутить, чтобы быстрее работало"

Спасибо. Ее я уже посмотрю завтра, наверное. Пятый час идет. Надо вздремнуть

(подразумевая, что алгоритм уже не улучшить 🙂 )

Да я даже не знаю что мне тут улучшать. Менять главную структуру данных разве что

А как?..

А. r/map не поддерживает такой функционал. Он требует ровно два аргумента

Расставил типы и применил трансдьюсер с обычным мапом. Ускорение есть, но все еще маленькое, но таким образом трансдьюсер + обычные мапы и фильтры стал быстрее r/ версий

Непонятно почему, но разница от 0 сек до 5 в пользу трансдьюсера

И я выиграл в среднем 1 секунду за ночь

а кста как профайлить код с кложурой? мож есть уже чего готовое?

https://www.yourkit.com/java/profiler/ https://github.com/thunknyc/profile дофига всего есть, на любой вкус и цвет

https://github.com/ptaoussanis/tufte

да, tufte удобная вещь, если надо быстро и просто

интересное интервью со Степановым http://www.stlport.org/resources/StepanovUSA.html

тем самым, который сделал STL для С++

В частности интересно он отзывается об ООП

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights - for the first time in my life programming in a new language did not bring me new insights.

The best way to judge a language is to look at the code written by its proponents. "Radix enim omnium malorum est cupiditas" - and Java is clearly an example of a money oriented programming (MOP). As the chief proponent of Java at SGI told me: "Alex, you have to go where the money is." But I do not particularly want to go where the money is - it usually does not smell nice there.

Короче дядька уже тогда про трансдьюсеры говорил и про то что Рич говорит в части абстракций, функций

>money oriented programming надо запомнить

а С++ это разве не ООП?

Ну, строго говоря ООП это парадигма, а С++ язык с сильным упором на ООП, но на нем можно и в других стилях писать

Степанов как раз STL написал не в ООП стиле

он в интервью как раз и пишет почему ему ООП не нравится совсем

вообще в интервью много интересных мыслей

Я раньше не профайлил программы, правильно понимаю, что я с помощью этого смогу увидеть, где у меня просаживается производительность?

@kgofhedgehogs у тебя же в самой программе нет io, только вычисления

а проц не загружен

тебе надо перестать гадать и понять что именно тормозит

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

в лупе просто

забьет проц?

для профайлинга есть yourkit, но он денег стоит. но базовый профайлинг умеет и visualvm / jmc

Я время замерял без вывода на экран. Проц не забивает. Это 100% не проблема отрисовки

оно одно ядро тока забивает может?

гугли parallel image convolution, наверное

суть та же самая.

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

Эээ, а как-то по-другому можно? Если не делить, то накладные расходы ужасны.

я даже не знаю, как по-другому. может быть тут есть кто-то умный, кто знает.

Я как раз читал сейчас о chunked pmap

Типа пмап мапов

та при чем тут пмапы

ты же одно ядро забить не можешь, так?

или нет? что значит "cpu 17%"?

может это общая загрузка всей системы? Т.е. одно ядро из 4

ага. встречал разные показатели. кто-то при полной нагрузке всех ядер показывает 100% кто-то k*100%

системы не уловил. смотреть надо

смысл в тех чатики то такое бросать

не домохозяйки же!

ну чел спрашивает

Просто я домохозяйка :)

Как освобожусь, скину детальную инфу

> ну чел спрашивает та я ж не виню никого ^_^, разбираемся вот )

Ну. Это значит, что ядро забивает полностью. Как мне сделать так, чтобы забивало несколько ядер?

ну вот тогда надо параллелить, да ) но для начала может проще оптимизнуть то что есть на одном ядре

для этого нужно профилировать

смотреть что жрет

yourkit 15 дней триала имеет )

Устанавливаю

Ну не нам знать! но скорее всего 64 бита )

Так. Профайлер профайлит

Дать ему попрофайлить, затем закрыть программу и смотреть отчет, так?

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

для начала их можно оптимизнуть!

возможно

а может нет

ну парралелизация вполне так себе оптимизация 🙂

времени работы программы*

йеп

к вопросу о распаралеливании и оптимизациям вслепую

Блин. А как его с оптимизировать-то. Надо уменьшать подаваемую коллекцию..

ну можно подумать нужна ли тебе тут такая группировка на каждом тике например или нет

Нужна =( Это ключевой момент расчета следующего шага

подумай!

Нужно ее менять на другую

может кешить можно вычисление

и итеративно к нему приходить

Ну вот клетки есть. У них есть соседи. Функция, на которой всё проседает, это подсчет кол-ва соседей. Узнать как изменится кол-во соседей не просчитав то же самое для клеток вокруг, нельзя. А если просчитать, то получится то, что я и сделал Пойду почитаю об оптимизациях этой игры. Может знающие люди придумали по-лучше моего

ну как это нельзя

у тебя есть AxB поле

и два массива

каждый AxB размером

в одном содержится жива клетка или нет, а в другом сколько у нее соседей

проходишь по первому в один проход и формируешь второй

проходишь по второму и обновляешь первый

все

никаких группировок, никаких аллокаций

Дело в том, что я не храню мертвые клетки Я храню только живые клетки, т.к. их как правило меньшинство

ты хочешь быстро или как ты сейчас? )

Я хочу быстро..

тебя не устраивает перформанс, ты хочешь быстрее

значит тебе нужно подумать как можно сделать не так как ты сделал сейчас, а по другому

вот тут парень линки дает

http://stackoverflow.com/a/40529

тут есть повод подумать о кложе-с интеропе

но там хтрожопенькие штуки предлагают

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

> тут есть повод подумать о кложе-с интеропе не нужно никакого кложаси интеропа тут, нужно просто написать нормально, в кложе достаточно всего для этого

если не уходить в битоебство совсем

Хорошо. Тогда надо мне пересмотреть структуру хранения данных: массив AxB, в котором содержатся цвета клеток, либо false. Нормально?

Цвет клетки это [0xRr 0xGg 0xBb]

Хотя, должен быть способ смешивать цвета храня их интами. Будет лучше, если в массиве будут числа, а не вектора

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

Хорошо. Спасибо большое

1. я бы не стал как то оптимизировать особо структуру одной клетки в начале. {:red 155 :green 155 :blue 155} and :died должно быть достаточно. будет тормозить — оптимизнешь 2. а вот на массивы вместо векторов стоит перейти сразу. иммутабельные структуры не дешевы в модицифкации

3. профайлер — твой помощник!

Хорошо. Не буду преждевременно оптимизировать лишнее

воу воу, сегодня я узнал новое слово “битоёбство"

у меня вопрос, как часто “битоёбство” происходит на фронтенде

то есть clj -> js нормально работает?

кмк это к железу. маски, сдвиги, big endian и тд..

ну если про железо, то это только про С, я вообще про борьбу с производительностью

всё это жанглирование атомами в жс нормально укладывается?

не знаю. вообще будет интересно посмотреть какой на кложе с массивами будет код

речь о массивах шла

а как можно использовать массивы избегая интеропа в java?

это к препу))

вообще там есть обертки кажется вроде make-array

transient кстате не поможет?

вроде на этот случай и есть

>то есть clj -> js нормально работает? на мобайле юзая CLJS + реакт нейтив иногда можно обжечься когда гоняешь CLJS <> js часто, во всяких листах при скроле и прочем

если кложу на ноде гонять. тоже похоже просадки будут при CLJS <> js

Там даже без интеропа должно быть не очень круто. Код который генерится Clojure Compiler`ом на advanced optimisation ломает оптимизации в V8.

И это сильно влияет? Т.е. на сколько проседает в итоге, на 1%, на 10%, на 100% ?

а это общепризнанный факт? весьма серьезное заявление в свете следующего релиза closure-compiler который научиться читать imports. И с того момента можно будет переезжать с webpack на figwheel

Эта тема активно сейчас обсуждается в cljs-dev

ну может Closure компилятор то делает все ок и чуваки из гугла знают что такое V8, но вот ClojureScript компилятор генерит и впрям не супер просто код, я хз

хотя я такое тоже первый раз слышу

http://blog.cognitect.com/blog/2017/1/31/state-of-clojure-2016-results

а кто что ищет/ожидает увидеть в результатах опроса?

The most interesting story here is the rise in three areas:

React Native - 18% (new choice this year)
Electron - 11% (new choice this year)
AWS Lambda - 9% (vs 5% last year)

да они там в когнитекте сами офигевают от того, где и как clojurescript используется. Они в него даже не инвестируют нормально (Нолен сидит датомик пилит), а он растет, как сорняк

вчера даже инстаграмм про RN написал

даже? это же фб 🙂

про RN вообще не удивительно - это ж покрытие целых двух новых платформ. кложа - бэкэнд, скрипт - фронтэнд, и теперь мобилы

ну типа да, fb, но всё равно от fb очень мало RN хайпа просачивается мне в эфир

https://twitter.com/cognitect/status/828987018923368448

про Вазу

Я все еще с оптимизациями. Нет ли очевидных путей ускорить вот этот код?

это копипаста из clojure.core?

Нет, мой код

ой сори не

Это исправленный под мои нужды group-by, так что ты от части прав

а ок, а то я смотрю persistent transient

дак если под одно ярдо оптимизировать не выходит то чо насчет других простаивающих ядер? парралелить не хочешь?

Просто это group-by был самым нагруженным местом в моей программе, теперь вместо него нагружен group-by-first-up-to-n

ыы

ну т.е. выигрыш то есть в итоге или просто название функции теперь другое?

Мне тут верно сказали, что дерьмовый алгоритм лучше не параллелить, а переписать. Поэтому перед тем как его переписать и параллелить, я еще пытаюсь спасти его

Выигрыш 3 секунды. Всего программа работает до 7 секунд

тебе тут много чего могут сказать - 420 человек в чатике 🙂

Но мнение я поддерживаю

а ну ок, тогда копай дальше

Параллелить это же с помощью go блоков и chan?

Просто я думал, что есть какой-нить мультипроцессорный мап, который сам всё за меня сделает

эм, ну можно конечно и так. Т.е. если для фана то можно core.async еще притащить и разобраться с ним, но это может занять время

Мне как проще, легче и читабельнее бы

на если уж легче и проще то я б сначала подкачал матчасть - как люди решают эту задачу, как ее паралелят, какие есть алгоритмы

core.async может усложнить проект, я помнится на первых порах больше мучался с ним

опять же это если цель проще - если для фана то лучше самому подумать 🙂

я вкурил core.async наверно через месяц тока ага(

Матчасть справляется быстрее моего алгоритма и без параллеления

может быть взять claypoole, он простой понятный, позволяет рулить pool-executors

а что значит "работает до 7 секунд"?

какой размер поля у тебя? какой начальный сид?

со своей сравню

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

700х700 плотно расставленные рандомные три цвета клеток, есть пробелы. Рассчет следубщего поколения сейчас в среднем 5 секунд

это один проход всего поля 5 секунд?

а, ты еще цвета смешиваешь

цвета это самая меньшая проблема

а сколько рандомных клеток сначала? есть координаты?

Ща

(let [world (random-rgb-cells [0 700] [0 700])]
  (time
    (game-step
      world
      blend-colors
      {:birth      [3]
       :keep-alive [2 3]}
      [-25 725]
      [-25 725])))

Закинуть координаты клеток?

так тут же в размере сида - самый сок

давай в личечку

Оке

и или покажи сорс random-rgb-cells

привет

а можно нубский вопрос по реакту?

у меня есть компонент "одометр", который показывает число и меняется как цифры в казино

я хочу его реактифицировать

как это сделано? в методе рендер пустой див. в didMount стоит включение этого стороннего компонента. в didUpdate стоит вызов изменений

чтобы он крутился

и всё вроде работает. 1) я не понимаю, почему, когда я в исходный див сделал непустым, положив туда число с текущим значением одометра, он не сбрасывает каждый раз по вызову метода рендер внутреннее состояние компонента.

https://github.com/adamrneary/react-odometer/blob/master/index.js

componentDidMount: function(){
     this.odometer = new Odometer({
      el: this.getDOMNode(),
      value: this.props.value
    });
  },
  componentDidUpdate: function() {
   this.odometer.update(this.props.value)
  },
  render: function() {
    return React.DOM.div()
  }

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

2) я пошёл дальше, и зачем-то повторил в методе рендер всю внутреннюю разметку этого стороннего не-реакт плагина. в этот момент только начинаются жалобы от реакта "cannot find element with id=77", из чего я заключаю, что реакт наконец возмущён тем, что его разметку компонента кто-то грохнул, и он не может произвести правильно дифф.