Романтики.Ру

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

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

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

Bitman писал(а): ↑15.04.2024, 10:02 Получится код, который, когда его скомпилировать, будет работать быстрее исходного; правда он и размером будет больше, но полагаю это не особо будет критично

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

Олег К писал(а): ↑15.04.2024, 19:07 А зачем размножать исходник в исходник, если компилятор сам делает такие оптимизации при переводе исходника сразу в машинный

Я на другом форуме предложил размножатель  кода, и мою идею начали хаить. Один написал, что для этого уже существуют 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;

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

Bitman писал(а): ↑16.04.2024, 15:02 Я совершенно не представляю, как можно отладить второй код, если программист видит в отладчике первый.

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

Олег К писал(а): ↑16.04.2024, 19:17 Так и не нужно отлаживать второй, отлаживаете первый с выключенной оптимизацией, чтобы машинный код был максимально близок к исходному. А когда все отлажено и работает, включаете оптимизацию и компилятор сразу из первого исходника соберет оптимизированный машинный код.

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

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

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

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

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

Bitman писал(а): ↑16.04.2024, 15:02 и мою идею начали хаять.

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

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

Bitman писал(а): ↑15.04.2024, 10:02 А вы купите такой девелоперкоин, если он появится? Сможете продонатить на его создание?

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

Bitman писал(а): ↑16.04.2024, 20:53 вручную провести низкоуровневую оптимизацию опытный человек сможет лучше компьютера.

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

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

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

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

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

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

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

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

Bitman писал(а): ↑17.04.2024, 08:35 Сорри, не понимаю. Как это - умножить arr на 2 в степени count? arr это массив в моём примере.

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

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

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

Bitman писал(а): ↑17.04.2024, 08:35 А как же строительство светлого будущего? Я серьёзно)

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

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

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

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

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

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