?

Log in

Дважды мудак [entries|archive|friends|userinfo]
Декларативное рулит

Site Meter

[ website | Мой сайт ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Люди, это пизда [май. 3, 2016|03:12 am]
Andy Melnikov
У меня нет других слов. Короче, ещё пару лет назад фейсбук мне показывал в списке потенциальных знакомых какую-то ерунду, и я туда вообще не ходил, и радовался тихо что пароль забыл.

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

Доколе!
Ссылка10 комментариев|Оставить комментарий

Левая развёртка косписков, anyone? [май. 3, 2016|01:30 am]
Andy Melnikov
[Tags|, ]

Код ниже на современном (с arrow functions - это ES5?) джаваскрипте. У натуральных чисел и списков есть, кроме обычного катаморфизма, такая же "штука с алгеброй", но "хитрая", соответствующая левой свёртке:
natCata = (algebra, i) => {

        if (i == 0)
	{
		return algebra(null)
	}
	else
	{
		return algebra(natCata(algebra, i - 1))
	}
}

natCata2 = (algebra, i) => {

	var ret = algebra(null) 
	while (i-- > 0)
	{
		ret = algebra(ret)
	}
	return ret
}
Вот у меня 3 вопроса в связи с этим:
1. Какие ещё структуры обладают этим "левым катаморфизмом"? Должны быть линейными, а ля

data O a = O a (E a) | ONil
data E a = E a (O a) | ENil

и неизоморфными хитрым спискам. Например O a неизоморфен списку из data RR a = OO a | EE a

2. Выразимы ли эти "периодические верёвки" как фиксированные точки функторов? Как вообще выглядит всё это разнообразие верёвок, т.е. какие варианты возможны? вот один, выразимый фиксированной точкой: data XList a b = XCons a (Xlist a b) | XNil b

3. Есть ли дуально "хитрые штуки с коалгеброй", у каких структур данных, и чему они соответствуют.
Ссылка9 комментариев|Оставить комментарий

Новости HNC [апр. 30, 2016|20:36 pm]
Andy Melnikov
[Tags|, , ]

В связи с тем, что в подкаст почти никакой информации об HNC не вошло, надо снова придумать введение.

1. Что такое HNC

HNC - это аналог PureScript для С++, оптимизирующий компилятор из промежуточного языка HN в человекочитаемый С++. На HN можно будет писать вручную, или использовать в качестве бэкенда для более высокоуровневого языка вроде Om.

Ключевые фичи:
1. Человекочитаемость и относительная идиоматичность выходного кода. Сравните выходной Javascript у PureScript и у тех же Elm/Fay/GHCJS.
2. Первоклассный интероп с С++, включая отсутствие чужеродных схем управления памятью (GC, особый аллокатор, подсчёт ссылок и пр)
3. Наличие серьёзного оптимизатора
4. Hackable кодобаза малого размера (до 6к строк).

Основная исследовательская задача - можно ли написать такой оптимизатор из ФЯ, выходной код С++ которого бы проходил ревью человеком, и если нет - насколько можно приблизиться.

С++ выбран как наиболее трудный таргет. Имея рабочую версию для С++, перенацелиться на какой-нибудь Javascript будет просто.

2. Зачем HNC

Борьба с лигаси-кодом на С++. Дописывание компонентов в системы на С++. Быстрое прототипирование для С++. В перспективе расширение идеи на другие языки.

3. Что позволит делать

По задумке, более компактно и с нулевым оверхедом по производительности описывать бизнес-логику в программах на С++. Оставив низкоуровневый код, перекладывающий байтики, на попечении С++ и чистого Си.

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

4. На чём написано

- Хаскель
- атрибутные грамматики UUAG (с атрибутами на хаскеле)
- библиотека HOOPL для написания оптимизаторов
- библиотеки парсинга и структурной унификации (последяя нужна в выводе типов)

5. В каком окружении работает

Компилятор работает везде, где есть GHC 7.10 (Win,Lin,Mac). Программы работают везде, где есть приличный компилятор С++ (MSVC считается приличным). Собственного рантайма и стандартной библиотеки нет. Прикручиваете по FFI нужные типы и функции и вперёд.

6. Писать работающие программы на нем будет можно? Опердени, высоконагруженные сайты с котиками, видеостримминговые серверы, что-нибуть еще?

В первом приближении - можно использовать в проектах, где в коде есть высокоуровневая часть, которую можно было бы написать на Lua, но нельзя, потому что он тормозит (или Lua не нравится, или религия не позволяет - у С++-ников найдется миллион причин разной степени объективности)

7. Какие платформы поддерживает (сможет поддерживать)?

Сможет практически всё. JavaScript, C#/Java, хоть Perl.

8. Какой интероп? Поддержка нативных типов платформы будет?

Пока можно вызывать функции в обе стороны (С++ <-> HN). Типы только нативные для платформы (в HN можно только функции писать - нельзя объявлять типы. Оверхед интеропа сводится к необходимости заворачивать методы в функции, но это ограничение текущей реализации, а не принципиальное.

Ccылки по теме:

https://github.com/nponeccop/HNC/wiki
https://github.com/nponeccop/HNC/wiki/PaperDraft
https://code.google.com/archive/p/inv/
https://code.google.com/archive/p/inv/wikis/Manifesto.wiki
Ссылка5 комментариев|Оставить комментарий

Требуется помощник на зп, парттайм-удаленка в пределах Украины [апр. 24, 2016|10:59 am]
Andy Melnikov
Я тут понял, что без помощника совсем плохо. Судя по DOU, фуллтайм ща 1500-1900, так что $1k для начала выглядит не очень по-жлобски, тем более что прибылей нет и это friends and family funding по сути. В пределах Украины, потому что проще платить.

Задач много разных, если по языкам - это Perl, node.js, C++, Haskell, c перспективой Ragel и Erlang.

Вебня, data mining, распределённые системы, трейдинг. Плюс весь мой опенсорс - https://github.com/nponeccop HNC, vz, n2o.hs.

По распределёнке - там каша из MPI, Event::RPC, gearman, ansible, SFTP и REST.

Data mining - есть система разлепливающая CSV по сотне маленьких CSV согласно правилам, надо аналитические тулзы писать для улучшения правил. В первом приближении хотя бы репорты. Распределёнка - тот же проект. Ragel туда же.

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

По трейдингу - пока надо бенчмаркать REST API площадки и вытягивать исторические данные по цене по тому же API. Там местами Python/Jupyter и C#.

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

Комменты скринятся, предложения по з-п в пределах трёшки можно озвучивать (но сейчас трёшки нету).
Ссылка13 комментариев|Оставить комментарий

Велкам ту риал ворлд [апр. 21, 2016|17:02 pm]
Andy Melnikov
[Tags|, ]

У меня тут внезапно вылез real life вариант задачи swizard. Прямо в продакшене.

3 типа исполнительных устройств:
- A: 6 операций A1-A6
- B: одна операция B
- C: одна операция С

3 типа узлов разной стоимости: A, ABC, AC.

Исполнительные устройства независимы. Т.е. на узлах ABC и AC с более чем одним устройством загрузка одного из устройств не влияет на производительность других.

Все устройства исполняют загруженные в них команды параллельно.

Операции занимают случайное время (но со стационарным распределением). Большое количество операций "насыщает" устройство - т.е. загрузка большего количества операций перестаёт увеличивать скорость. Есть феномен "медленных" операций, не насыщающих устройство. Т.е. насыщение, условно, происходит после загрузки 10 быстрых операций или 100 медленных, причём
быстрота или медленность неизвестна до загрузки в операции в устройство. Представьте, например, что устройство B - это кластер, проверяющий зашифрованное число на простоту. Если идут одни чётные - упираемся во внутренний bandwidth устройства, а если одни произведения
двух близких простых сомножителей - упираемся в процессоры. Но т.к.ключ известен только устройству, мы перед загрузкой сами ничего проверить не можем.

Более того, устройство не умеет сообщать внутренние bandwidth и cpu usage, мы можем о них только догадываться, измеряя время. Например, грузим инструкции, засекаем время исполнения каждой. Если результат инструкции, загруженной 30 секунд назад, не получен - помечаем
инструкцию "медленной". Грузим ещё инструкции, пока "кол-во медленных * X + кол-во неизвестных < Y"

Представьте себе, что узлы - это микросхемы. Изготавливаются с повреждениями, но умеют отключать повреждённые участки. Продаются непроверенными. Соответственно, производительность устройств в узлах индивидуальна. Чипы можно купить, измерить и решить выбросить или оставить. Но оставлять только топовые чипы, а остальные выбрасывать - нерентабельно.

Теперь о вычислениях.

На входе у нас неограниченный поток однотипных задач T.

Представьте, что у нас T - это теоремы, а операции - это стратегии, сводящие одни теоремы к другим.

Общий воркфлоу такой:

Приходит теорема, мы скармливаем её стратегии A5. Она может либо сразу ответить, что типа противоречие, или выдать нам список лемм [A5R] ("A5 Result").

Лемма A1R сводится стратегией A2 к набору лемм [A2R]. И так далее.

Некоторые тривиальные стратегии Sx реализованы "софтварно". Они исполняются мгновенно без загрузки в узлы.

Формализуется композицией монад списка и исключений. Я просто списки для простоты буду использовать.

Всю схему тоже заебусь формализовывать, сделаю только hot path, показывающий использование всех устройств, но не всех инструкций:

S1 :: T -> ([S1R1], S1R2)
A5 :: S1R2 -> [A5R]
A1 :: A5R -> [A1R]
B :: A1R -> ()
C :: S1R1 -> [S1R1]

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

Представьте что мы консультанты по строительству, T - это проект дома с адресом, а наша задача - определить, можно ли построить дом или нельзя. Практически всегда можно.

A - это юридический отдел. B - геологи, а C - занимаются коммуникациями.

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

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

Т.е. каждый отдельный проект проходит последовательно 3 стадии: A -> C -> B.

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

И сложения можно начинать делать только тогда, когда все умножения закончились. Даже те, которые не являются зависимостями.

Отделу А надо выбирать между A5 S1R2 и A1 A5R в очереди. Если B загружен, а простаивает А - имеет смысл делать A5. Если наоборот - имеет смысл делать A1. Ещё надо контролировать количество проектов, застрявших на стадии A - т.е. отдавать приоритет доделыванию существующих проектов. При недогрузе B имеет смысл в первую очередь ставить A1 из проектов с почти готовой стадией A, а не рандомно.
Ссылка22 комментария|Оставить комментарий

navigation
[ viewing | most recent entries ]
[ go | earlier ]