Ушат помоев в сторону крестолюбов

Ок, претензия снята, там bignum и вправду похоже на лиспе.

Лох! У меня на Джаве быстрее!

Result: 50000000005000000000
Execution time: 777 microseconds

Код: https://gist.github.com/olegchir/825aef1145ae126e8f1f9aaa2936a70c

Анонимус, учти в следующий раз, что за такие шутки бьют лицо утюгом

Отчего же вы тогда так люто говнокодите?

В каком месте я наговнокодил?

Код: https://gist.github.com/olegchir/825aef1145ae126e8f1f9aaa2936a70c

Анонимус, учти в следующий раз, что за такие шутки бьют лицо утюгом

Это не шутки, а суммирование по моим правилам :-) А ты продемонстрировал смену алгоритма :-) Суммируй честно :-)

Я к тому, что ТС хвастался, что его вариант O(1), а кресты гавно.

Да. Потому что в unordered_map под капотом конченная техника по имени open addressing.

Хотя ни один крестофанбой не осилил приподнять занавесу тайны над unordered_map, видимо в силу паталогического неосиляторства.

Поэтому я и прошу - предъяви ассемблер того, что тебе собрал твой компилятор. Я уверен что он тоже сменил алгоритм и складывает по гауссу.

Утюг нагревается, юзернейм, снимай штанишки

Мааааааатерь божья. 57 строк на джаве против one-liner на лиспе и питоне... Как ты на этом пишешь?

Суммирование одного миллиарда 1-х нат. чисел на Питоне на моей машине занимает 27 секунд

Проблема не в питоне, а в тебе. Учись:

def sumN(N):
    return (1 + N) * N / 2

Поэтому я и прошу - предъяви ассемблер того, что тебе собрал твой компилятор. Я уверен что он тоже сменил алгоритм и складывает по гауссу.

Уверен, не уверен, Лисп - высокоуровневый язык :-) По Гауссу там, или не по Гауссу, мне по сараю - это задача компилятора :-) Суть то в том, что тебе пришлось сломать голову, прежде чем до тебя дошло применить метода Гаусса и реализовать его вручную на Java, ты потратил сколько времени? :-) А я на написание loop потратил 5 секунд :-)

Но если тебе нужен ассемблер, на, разбирайся:

    (recover-fn-from-rip)                   ;     [7]
    (testl (% nargs) (% nargs))             ;    [14]
    (jne L221)                              ;    [16]
    (pushq (% rbp))                         ;    [22]
    (movq (% rsp) (% rbp))                  ;    [23]
    (pushq (% save0))                       ;    [26]
    (pushq (% save1))                       ;    [28]
    (xorl (% save0.l) (% save0.l))          ;    [30]
    (xorl (% save1.l) (% save1.l))          ;    [33]
L29
    (movq (% save1) (% arg_y))              ;    [36]
    (movq (% save0) (% arg_z))              ;    [39]
    (movl (% arg_y.l) (% imm0.l))           ;    [42]
    (orl (% arg_z.l) (% imm0.l))            ;    [44]
    (testb ($ 7) (% imm0.b))                ;    [46]
    (jne L70)                               ;    [49]
    (addq (% arg_y) (% arg_z))              ;    [51]
    (jno L84)                               ;    [54]
    (lisp-call  (@ .SPFIX-OVERFLOW))        ;    [61]
    (recover-fn-from-rip)                   ;    [68]
    (jmp L84)                               ;    [75]
L70
    (lisp-call  (@ .SPBUILTIN-PLUS))        ;    [77]
    (recover-fn-from-rip)                   ;    [84]
L84
    (movq (% arg_z) (% save1))              ;    [91]
    (movq (% save0) (% arg_z))              ;    [94]
    (testb ($ 7) (% arg_z.b))               ;    [97]
    (jne L118)                              ;   [101]
    (addq ($ 8) (% arg_z))                  ;   [103]
    (jno L140)                              ;   [107]
    (lisp-call  (@ .SPFIX-OVERFLOW))        ;   [109]
    (recover-fn-from-rip)                   ;   [116]
    (jmp L140)                              ;   [123]
L118
    (movl ($ 8) (% arg_y.l))                ;   [125]
    (lisp-call  (@ .SPBUILTIN-PLUS))        ;   [133]
    (recover-fn-from-rip)                   ;   [140]
L140
    (movq (% arg_z) (% save0))              ;   [147]
    (movq (% save0) (% arg_y))              ;   [150]
    (movq ($ #x1DCD65000) (% arg_z))        ;   [153]
    (testb ($ 7) (% arg_y.b))               ;   [163]
    (jne L173)                              ;   [167]
    (cmpq (% arg_z) (% arg_y))              ;   [169]
    (jle L29)                               ;   [172]
    (jmp L199)                              ;   [178]
L173
    (lisp-call  (@ .SPBUILTIN-GT))          ;   [181]
    (recover-fn-from-rip)                   ;   [188]
    (cmpb ($ 11) (% arg_z.b))               ;   [195]
    (jne L199)                              ;   [199]
    (jmpq L29)                              ;   [201]
L199
    (movq (% save1) (% arg_z))              ;   [206]
    (popq (% save1))                        ;   [209]
    (popq (% save0))                        ;   [211]
    (leaveq)                                ;   [213]
    (retq)                                  ;   [214]
L221
    (uuo-error-wrong-number-of-args)        ;   [228]

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

Проблема не в питоне, а в тебе. Учись:

В тебе :-) По Гауссу можно и на счётах посчитать :-) Речь идёт о том, что числодробильня в Лиспе годится для быстрых расчётов :-)

Что будут делать лиспопетушки, когда в комплияторе не обнаружится нужной оптимизации - одному царю известно!

Как что? :-) Как опция, обратятся к такому специалисту, как ты :-)

в unordered_map под капотом конченная техника по имени open addressing.

Ты бенчмарк сделай, а то получится, как с memmove.

Хотя ни один крестофанбой не осилил приподнять занавесу тайны над unordered_map

В Си вообще нету хэш. таблицы. Вот нету и всё.

Хеш. таблицы не нужны.

Есть https://github.com/smparkes/sqlite

Ты жопу с пальцем сравнил, балда. Причём палец внутри жопы.

дядя петя, ты дурак?

Что такое «серьёзная числодробилка»?

Ну хотя бы банальное скалярное волновое уравнение, счетная область 1000х1000х1000 ячеек, числ. схема хотя бы 2го порядка. Параметры среды произвольные, задаются на той же сетке. Источник типа центра расширения, граничные условия PML.

Вот когда напишете такое на CL, или найдете такое на CL, что бы параллельная версия на CPU жрала не больше 20 тактов на ячейку на шаг на ядро - приходите, поговорим. А пока что продолжайте суммировать арифметические последовательности, это как раз задача для Вас и CL;-)

на CPU жрала не больше 20 тактов на ячейку на шаг на ядро

Ничего не путаете? 20 тактов - это перемножить два вектора на avx2.

RAII

Вообще, достаточно подождать пока в расте запилят нормальные аллокаторы и параметризацию дженериков числами (есть rfc, лень искать), и будет жизнь.

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

Это на лиспе avx так тупит?;-)

Или Вы какого размера вектора имеете ввиду?

На асме, вектора из трех даблов, векторное произведение.

На кложе.

user=> (time (reduce + (range 10000000001)))

ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)

Boost::date_time

Веки подыми: Ушат помоев в сторону крестолюбов (комментарий)

Приводить решение задачи B, когда было испрошено решение задачи A - это очень сильно.

Где в скалярном волновом уравнении векторное произведение?;-)

Ну и не 20 а вроде бы шесть без avx - конвейер же. векторизацией будет меньше, но ее довольно сложно в таких задачах делать.

И описанную задачу можно считать на флотах.

Ыыы, да вы даже не читаете, что вам пишут.

Объясни мне, пожалуйста, зачем ты постоянно в C++ код (по твоему мнению) подключаешь заголовочные файлы C?

Точнее даже так: зачем ты выдаешь помесь С и C++ за чистый C++?

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

(кроме умных указателей).

Для shared_ptr тоже, если ты не планируешь его потом хранить.

Ну хотя бы банальное скалярное волновое уравнение, счетная область 1000х1000х1000 ячеек, числ. схема хотя бы 2го порядка
Вот когда напишете такое на CL, или найдете такое на CL

Хахаха :-) А причём тут я? :-) Это задача для окодэмиков с дутыми щеками, а не для каких-то там клоунов смайликов :-)

А пока что продолжайте суммировать арифметические последовательности, это как раз задача для Вас и CL;-)

Ты так ничего и не понял :-) Впрочем, я не удивлён :-) Окодэмики нынче такие :-)

Указатели и ссылки на разных уровнях работают - сырая память* vs объекты. Хаскеллист-то должен это видеть.

* От «сырости», правда, си уже несколько отошел.

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

ч.т.д.

ЗЫ. Ваши неасиляторские рыдания про «окадэмиков» весьма доставляют.

Вы тут при том, что Вы утверждали что лисп для числодробилок лучше чем цпп.

Это ложь :-) Я не утверждал этого, я утверждал, что числодробильня в Лисп *не хуже чем в Java* :-) Вот пруф :-) И кто брехло тогда? :-)

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

Лол :-) Возможности числодробилки в Лиспе я подтвердил банальным суммированием 10 миллиарда нат. чисел :-) Если ты не понял, к чему был тест, то причём тут я? :-)

QED

Мне в крестах больше всего не нравится хаос в стандартной архитектуре и стандартной инфраструктуре

Вот в джаве например, есть стандартная раскладка файлов - конвенции maven). Есть стандартный способ декларативно (а не процедурно привет *make) описывать зависимости без необходимости их скачивать, добавлять-удалять, или еще как-то ими управлять - maven. Есть вполне стандартные способы организовать типичные задачи типа Dependency Injection. Есть четкое понимание о стандартных архитектурах и методах их реализации - каркас веб-приложения на SpringMVC сделанный одним жабокодером будет как две капли воды похож на творение любого другого жабокодера

в C++ творится ПОЛНЫЙ ХАОС. Пыщ пыщ упячка, жывтоне чочо попячсо. Типичное приложение на C++ выглядит как ужасные неструктурированные джунгли говнокодов, в которых без поллитры и марки не разобраться. Огромные файлы-свалки из овердофига классов (авторы объясняют это как «инлайнинги не работают между файлами, а -flto мы не включаем потому что кодим на микроволновке, но мы-то знаем). Где-то 3/4 кода написано самостоятельно (или понатаскано копипастой файлов с лицензией MIT/BSD) потому что авторы тяжело больны NIH синдромом. Сраные велосипедные аллокаторы, написанные наркоманами. Собирается всё через пень колоду, есть cmake но им никто не пользуется по-настоящему, типичную сборку нельзя собрать одной командой - нужно бродить между папками, собирать какие-то ошмётки, копировать их из директории в директорию, снова собирать, и так пока может быть что-нибудь не получится. Половина инструкций говорит скопировать промежуточные ошмётки прямо в /usr ибо иначе не собирается. Словом, ад

Знаешь, что самое удивительное, ты сейчас показываешь всю суть РАН, всего невежества этой шаражки, лицемерия, бахвальства, стоит отдельно отметить, что в демагогии ничем не отличаешься от того анонима, которому ты ответил, что является поводом задуматься, метать бисер-то все горазды, а вот сохранить лицо - нет. Это даже если просто рассматривать твою речь, но ничего, рашка сама себя съест, вместе с тупыми академиками, которые кроме умения слушать свой пердёж и бахвальствовать пред студентами, научились - ничему, стоит сделать отельное отступление и сказать, что не вся академия такая, это правда не решает проблемы с руководством, напыщенностью, выканьем (это спорно), а главное - агрессией, нет ничего удивительного в том, что на митинги в защиту РАН пришла куча мракобесов, чем очень хорошо дополнили картину.

Лох, у меня с циклом и на питоне быстрее. RPython:

import time

def main(args):
    start = time.time()
    s = 0
    for i in xrange(1000000001):
        s += i
    end = time.time()
    print(s, end-start)
    return 0

def target(*args):
    return main, None

$ ./test-c
(500000000500000000, 0.000000)

0.000000 микросекунд. А всё потому, что цикл заоптимизировался в одну единственную, простую и красивую инструкцию моего 64-битного процессора: movabs rax,0x6f05b59f17f6500.

Я не большой фанат C++, но всё, что вы написали - бред и 4.2

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

Твой асм говно.

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

Походу, уже сейчас CMake становится де-факто стандартом. И с такими темпами еще через 3-4 года станет де-юре. Хотя ничего хорошего в этом нет, конечно.

Некоторые используют CMake-овский ExternalProject_Add в качестве менеджера зависимостей. Кому это не нравится, делают свое. Но до какого-то консенсуса как до луны. В этом плане Rust-оманам завидую белой завистью.

И с такими темпами еще через 3-4 года станет де-юре. Хотя ничего хорошего в этом нет, конечно.

Why?

CMake вполне хорош.

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

Всех нужно заставить постепенно перейти на модули :-) Вот где вполне реально построить инфраструктуру :-)

Может так лучше?

Кложурятина 1.8

user=> (defn sum [n] (* (inc n) (/ n 2)))

user=> (time (sum 1000000000))
"Elapsed time: 0.020544 msecs"
500000000500000000

sbcl 1.3.1

* (defun sum (n) (* (1+ n) (/ n 2)))

SUM
* (time (sum 1000000000))

Evaluation took:
  0.000 seconds of real time
  0.000000 seconds of total run time (0.000000 user, 0.000000 system)
  100.00% CPU
  4,050 processor cycles
  0 bytes consed
  
500000000500000000

> (define (sum n) (* (add1 n) (/ n 2)))
> (time (sum 1000000000))
cpu time: 0 real time: 0 gc time: 0
500000000500000000

Why?
CMake вполне хорош.

Субъективные впечатления. Начиная от того, что мне лично нужен кроссплатформенный build-tool, а не генератор makefiles. И заканчивая убогой документацией. Между делом проходя через синтаксис, который придумали люди, покусанные Perl-ом и FoxBase.

А так ещё лучше :-)

(time 500000000500000000)
500000000500000000
took 5 microseconds (0.000005 seconds) to run.

Начиная от того, что мне лично нужен кроссплатформенный build-tool, а не генератор makefiles.

Ну а что мешает рассматривать CMake не по отдельности, а вместе со сборочной тулзой по вкусу?

И заканчивая убогой документацией.

Вот не надо гнать на документацию, она в CMake отличная.

Между делом проходя через синтаксис, который придумали люди, покусанные Perl-ом и FoxBase.

По этому поводу спорить не буду.

Да... модули сильно помогут.

Так после генерации мэйкфайла - добивай дальше скриптами. Это вполне окей, когда прога - не комбайн. Юникс-вэй же.

CMake плох тем, что его нельзя нормально интегрировать с IDE.

С другой стороны есть простой как палка qmake, и очень быстрый и удобный qbs.

Про синтаксис лучше вообще не вспоминать.

Сплошное 4.2 и неосилятлрство какое-то . Особенно про сборку.