Венчурное инвестирование и криптовалюта с налогами

[Bitman]

Когда на форумах программистов обсуждают идеи новых проектов, всегда возникает проблема, что отдельному программисту невыгодно делать рискованные проекты, в то время как крупной фирме выгодно. Грубо говоря, если у вас есть проект, который с вероятностью 10% сделает вас миллионером, а с вероятностью 90% вы зря потратите кучу времени – вы заниматься этим не станете, но крупная фирма может запустить 100 таких проектов и на этом зарабатывать. По-научному это называется “нелинейной зависимостью полезности от дохода для мелких игроков” (в теории рационального выбора). А венчурные инвестиции в среднем выгоднее обычных.

Предлагаю две идеи рискованных проектов, связанных с программированием:

► Показать

1) Размножатель кода
Оптимизация кода, например в Delphi, часто сводится к разным вариантам размножения кода, например инлайн функций. А что если кто-то напишет программу, которая берёт полный Delphi код проекта и переписывает его, инлайня все функции кроме рекурсивных, и размножая тела циклов скажем впятеро. Получится код, который, когда его скомпилировать, будет работать быстрее исходного; правда он и размером будет больше, но полагаю это не особо будет критично (сам по себе код, что в текстовом формате что в машинном, занимает заведомо меньше гигабайта).

► Показать

2) Статический аналог Wine
Можно написать статический аналог Wine: программу, которая анализирует чей-то экзешник, обрабатывает и превращает его в исполняемый код для Linux/Mac. Т.е. Вайн делает это динамически, а тут будет статически, можно будет поднастроить компиляцию вручную, и автор такого софта сможет делать компиляции разных программ под заказ.

Так вот про криптовалюты. Я считаю, что мир могут спасти криптовалюты с налогами: если какая-то комиссия с транзакций идёт на фиксированный кошелёк, и общим голосованием можно поменять этот кошелёк. Руководитель такого коина (владелец этого кошелька) будет вкладывать деньги в венчурные проекты и возвращать держателям прибыль.
Я написал эту идею на нескольких форумах программистов плюс на форуме криптовалютчиков, вдруг найдутся люди, которых заинтересует проект и которые засядут за работу. А вы купите такой девелоперкоин, если он появится? Сможете продонатить на его создание?

[Олег К]

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

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

[Bitman]

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

Я на другом форуме предложил размножатель  кода, и мою идею начали хаить. Один написал, что для этого уже существуют LLVM и gcc. Второй написал, что в C++ уже есть размножение кода (называется inlining и loop unrolling). Но я всё-таки не понимаю, как у них размноженный код отлаживается.
Предположим, у нас есть код (привожу пример на Delphi, полагаю тут разберут):

var
i:integer;
count:integer;
arr:array of double;
begin
..
for i:=0 to count-1 do
begin
arr:=arr*2;
end;
end;

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

var
i:integer;
count:integer;
arr:array of double; dcount:integer;
begin
..
dcount:=(count div 5) * 5;
i:=0;
repeat
arr:=arr*2;
inc(i);
arr:=arr*2;
inc(i);
arr:=arr*2;
inc(i);
arr:=arr*2;
inc(i);
arr[i]:=arr[i]*2;
inc(i);
until i>=dcount;
for i:=dcount to count-1 do
begin
arr[i]:=arr[i]*2;
end;
end;

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

[Олег К]

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

Так и не нужно отлаживать второй, отлаживаете первый с выключенной оптимизацией, чтобы машинный код был максимально близок к исходному. А когда все отлажено и работает, включаете оптимизацию и компилятор сразу из первого исходника соберет оптимизированный машинный код. Тем более что эти низкоуровневые по своей природе оптимизации он сделает эффективнее чем при преобразовании исходника в исходник. В вашем примере скорее всего в первом нормальном исходнике компилятор увидит цикл и не просто развернет его, а задействует векторные расширения процессора, так чтобы за такт удваивалось сразу несколько значений(8 с avx2), что гораздо быстрее, чем просто развернуть цикл. А "оптимизации" во втором исходнике, только собьют оптимизирующий компилятор с толку и он может не понять что это за конструкция "перевести" буквально как есть.

[Bitman]

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

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

Тем более что эти низкоуровневые по своей природе оптимизации он сделает эффективнее чем при преобразовании исходника в исходник. В вашем примере скорее всего в первом нормальном исходнике компилятор увидит цикл и не просто развернет его, а задействует векторные расширения процессора, так чтобы за такт удваивалось сразу несколько значений(8 с avx2), что гораздо быстрее, чем просто развернуть цикл.

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

[Н. Светлов]

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

Подозреваю, что вменяемый современный компилятор сразу заменит цикл из примера Bitman'a на умножение arr на 2 в степени count. Причём если из кода понятно, что count не слишком велик, возведение в степень будет реализовано не через вещественную арифметику, а напрямую через установку единицы в бит номер count.

и мою идею начали хаять.

Я, с Вашего позволения, похаю вторую (несильно). Собственно, объектный код один и тот же и в линуксе, и в винде. Разница в системных вызовах. В том, что между вызовами винды и вызовами линукса нужна прослойка-переводчик. В связи с этим задача сводится к тому, чтобы вырезать из Wine кусок, используемый данным объектным кодом, и прилинковать его к этому объектному коду на место системных вызовов винды. В результате если на Вашем компьютере будет пять разных приложений, перелинкованных из винды в линукс, то некоторый код Wine будет присутствовать в файловой системе пятикратно, будучи прилинкованным к к каждому из пяти приложений. Право же, лучше запускать из-под Wine, а ещё лучше (если ресурсы позволяют) — из виртуальной машины, управляемой виндой.

Отправлено спустя 3 минуты 18 секунд:

А вы купите такой девелоперкоин, если он появится? Сможете продонатить на его создание?

На оба вопроса ответ «нет». У меня очень высокий уровень неприятия риска. В среднем я скорее не доверяю людям, чем доверяю — особенно тем людям, кто нуждается в моих деньгах. Это не мы такие, это жизнь такая

[Олег К]

вручную провести низкоуровневую оптимизацию опытный человек сможет лучше компьютера.

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

[Bitman]

Подозреваю, что вменяемый современный компилятор сразу заменит цикл из примера Bitman'a на умножение arr на 2 в степени count. Причём если из кода понятно, что count не слишком велик, возведение в степень будет реализовано не через вещественную арифметику, а напрямую через установку единицы в бит номер count.

Сорри, не понимаю. Как это - умножить arr на 2 в степени count? arr это массив в моём примере.

Я, с Вашего позволения, похаю вторую (несильно). Собственно, объектный код один и тот же и в линуксе, и в винде. Разница в системных вызовах. В том, что между вызовами винды и вызовами линукса нужна прослойка-переводчик. В связи с этим задача сводится к тому, чтобы вырезать из Wine кусок, используемый данным объектным кодом, и прилинковать его к этому объектному коду на место системных вызовов винды. В результате если на Вашем компьютере будет пять разных приложений, перелинкованных из винды в линукс, то некоторый код Wine будет присутствовать в файловой системе пятикратно, будучи прилинкованным к к каждому из пяти приложений. Право же, лучше запускать из-под Wine, а ещё лучше (если ресурсы позволяют) — из виртуальной машины, управляемой виндой.

Тоже не понимаю. Размер экзешника в типичном случае 10 MB, такой же размер по идее будет у линуксового исполняемого файла, в чём проблема?

Отправлено спустя 9 минут 40 секунд:

На оба вопроса ответ «нет». У меня очень высокий уровень неприятия риска. В среднем я скорее не доверяю людям, чем доверяю — особенно тем людям, кто нуждается в моих деньгах. Это не мы такие, это жизнь такая

А как же строительство светлого будущего? Я серьёзно)

[Н. Светлов]

Сорри, не понимаю. Как это - умножить arr на 2 в степени count? arr это массив в моём примере.

Покомпонентно. Или я неправильно понял код на Паскале? Я его понял как удвоение каждого компонента массива на каждом шаге. Если в Паскале семантика звёздочки в контексте массива иная, то, значит, я ерунду написал.

Тоже не понимаю. Размер экзешника в типичном случае 10 MB, такой же размер по идее будет у линуксового исполняемого файла, в чём проблема?

Нет, размер линуксового экзешника будет на несколько десятков мегабайт больше за счёт прилинкованных к нему трансляторов системных вызовов Windows в системные вызовы Linux. Впрочем, если сделать попытку вместо использования прослойки-транслятора выковырять из кода все системные вызовы Windows и заменить их кодом, делающим ровно то же самое через системные вызовы Linux, то приращение кода будет меньше (хотя всё равно будет, потому что недостающую функциональность придётся прописывать вновь сгенерированным кодом); но проблема в том, что системные вызовы Windows — это такие себе чёрные ящики, что для всех случаев заранее невозможно предсказать, что и как они сделают в той или иной ситуации. Поэтому поведение переделанной программы наверняка будет отличаться от поведения оригинала, по крайней мере, в некоторых ситуациях. Транслятор надёжнее, хотя, как известно из практики использования Wine, даже он проблему в полной мере не решает.

А как же строительство светлого будущего? Я серьёзно)

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

Донаты тоже могут работать, не спорю. Но я в эти игры не играю. Ну нет у меня аппетита к риску. Совсем.

[skor]

Тоже не понимаю. Размер экзешника в типичном случае 10 MB, такой же размер по идее будет у линуксового исполняемого файла, в чём проблема?

Проблема в том, что Н. Светлов предложил очевидное и стопроцентно реализуемое решение задачи, а вы, видимо, имели в виду хитрое и практически неосуществимое решение

► Показать

Поясню, в чём тут дело.

Николай предлагает статически прилинковывать код библиотек из wine, осуществляющих трансляцию системных вызовов Windows в системные вызовы Linux. Эти библиотеки занимают сотни мегабайт и, соответственно, размер итогового исполняемого файла тоже будет составлять сотни мегабайт. Тем не менее, это вполне рабочее решение.

Вы же, как я понял, предлагаете автоматически переписывать машинный код. Т.е., например, приложение с графическим пользовательским интерфейсом рисует окошки/кнопки/менюшки через Win32 API, и его надо переписать так, чтобы оно рисовало всё то же самое через qt или gtk. Учитывая, что Win32 API устроено существенно по-другому, чем qt или gtk, задача переписывания приложения оказывается крайне нетривиальной.

[solvisor]

Я считаю, что мир могут спасти криптовалюты с налогами: если какая-то комиссия с транзакций идёт на фиксированный кошелёк, и общим голосованием можно поменять этот кошелёк.

Поднимите свою ноду и получайте комиссию с каждой транзакции и тратьте полученный доход на своё усмотрение.