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

Да вот этот довод звучит убедительно. У сей действительно есть проблема с фрагментацией памяти. И обходится он крайне тяжёлыми методами

это не самый часто возникающий эффект, но он есть

т.е. это говорит больше об импелементации чем о языках

просто это может быть сильно времязатратнее

просто это может быть сильно времязатратнее

Да есть такое дело))

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

ну там реализация кривая была сначала

так то там haskell обогнал rust в конце концов

но ту реализацию, что была в конце никто в здравом уме писать не будет

хотя питон в 2 раза и наивная обошла

нормальная сравнимая с растом

Ну наверное ребята из раста не сильно может старались. По идее то к раста больше возможностей для оптимизаций

не нормальная 1.1/1.2 от сишки

так то там haskell обогнал rust в конце концов

насколько я помню, там для vector fusion нужна была отдельная библиотека, когда в расте это по-дефолту было?

Andy ну вроде у них на канале особо идей не было

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

там из-за того, как проходятся данные нельзя было временные структуры делать

но все равно основной бонус там от того, какой размер буффера

https://m.habr.com/post/323106/ вот кстати про питон си и раст) можно не читать , а только в конце табличку посмотреть. Правда офтопик , хаскела там нету

так что так себе - бенчмарк malloc и write

Спасибо за подробные пояснения

Всем спокойной ночи

спокойной, обращайся ещё если вопросы будут

да даже ocaml быстрее питона будет...

А вот это странно. Я имею ввиду, что вообще вроде окамл побыстрее хаскела даже вроде

не должен бы

Если не вылизывать код на C / Haskell, то последний может оказаться быстрее ещё и из-за ленивости, т.к. не будет лишнее считать.

Например, надо посчитать f(x, y), причём использование 'y' зависит от значения 'x'. В C придётся считать оба, а в Haskell второй будет вычислен по необходимости

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

Но питон жи тоже во что-то там компилируется. И ещё использует оптимизированные библиотеки на си

компилируется в байт-код, который интерпретируется. компиляция — это не волшебство, делающее всё быстрее

Ещё есть всякий PyPy же, который дикая смесь jit и суперкомпиляции.

Ещё есть всякий PyPy же, который дикая смесь jit и суперкомпиляции.

Откуда там суперкомпиляция?

Обычный tracing JIT

Агрессивные оптимизации - это не суперкомпиляция

Я когда про агрессивные оптимизации слышу, вспоминаю Contra III. Там в самом начале была фраза: we must fight them aggressively.

Я когда про агрессивные оптимизации слышу, вспоминаю Contra III. Там в самом начале была фраза: we must fight them aggressively.

(спешно ищет mp3 с главной темой Контры)

Вообще интересно как трюффелёвые питоны по перфомансу с PyPy

никак вродь, змея в трюфелях еще не оч работоспособна

и тут оффтопик

Неделя без оффтопа в основном чате обернулась неделей оффтопа в обоих чатах

да ладно, только капелька

жалко, статистика не считает сколько онтопика в абсолютных цифрах

В абсолютных цифрах зато можно сказать, что в чате стало тихо, @combot не даст соврать

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

Нужно изменить тактику. Задавить оффтопик продуктивным общением по делу.

data Human a = Age a | Dead на хаскеле можно пофилософствовать о жизни и смерти)

Нужно изменить тактику. Задавить оффтопик продуктивным общением по делу.

Это бесполезно, пока в чате не будет какого-нибудь сообщества, поддерживающего опенсорсный проект на хаскеле

Неделя без оффтопа в основном чате обернулась неделей оффтопа в обоих чатах

А какой второй чат еще есть?

data Human a = Age a | Dead на хаскеле можно пофилософствовать о жизни и смерти)

Кстати, как в этом случае ограничить множество допустимых типов a ? Чтобы можно было подставлять чиселки, но нельзя было подставлять что-то другое ?

Кстати, как в этом случае ограничить множество допустимых типов a ? Чтобы можно было подставлять чиселки, но нельзя было подставлять что-то другое ?

(Num a => Human a)

А поподробнее можно, пожалуйста?

Кстати, как в этом случае ограничить множество допустимых типов a ? Чтобы можно было подставлять чиселки, но нельзя было подставлять что-то другое ?

ну я сначала написал: data Human Int = Age Int | Dead но линтер ругнулся.

а тут инт не нужен возле Human

{-# LANGUAGE RankNTypes #-} data Human a = Alive (Num a => a) | Dead

а тут инт не нужен возле Human

Ага, нужно сделать тип Fix Human и исползовать его как нумералы Пеано.

(Num a => Human a)

вот так что ли? class Num a => Human a where data Human a = Age a | Dead

42 :: Human * 27

весело будет

квадратнолюди

data Human = Age Int | Dead ?

вот так что ли? class Num a => Human a where data Human a = Age a | Dead

Ну нет, я имел в виду, что там где юзаешь Human ставишь ограничение на a. burn : Num a => Human a -> Human a

{-# LANGUAGE RankNTypes #-} data Human a = Alive (Num a => a) | Dead

Но так оч красиво

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

Ну нет, я имел в виду, что там где юзаешь Human ставишь ограничение на a. burn : Num a => Human a -> Human a

понятно

вообще обычно так и делают

а то потом захочется сделать какой-нить traverse и не получится

вообще обычно так и делают

Как?

как ты написал

Нужно изменить тактику. Задавить оффтопик продуктивным общением по делу.

начинай

опять к недооформленным вопросам по парсерам

вот у меня есть текст fooo foo!bar "qoobidooh foo!bar"

так.. пока писал вопрос исчерпался

но на всякий случай вот foo!bar и foo это токены, но у foo!bar ещё нужно доразбирать, нужно сказать, что там есть части [foo, !bar]

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

А какой второй чат еще есть?

@haskell_learn

пасиб

но на всякий случай вот foo!bar и foo это токены, но у foo!bar ещё нужно доразбирать, нужно сказать, что там есть части [foo, !bar]

А у тебя foo!bar и foo !bar это одно и то же или нет?

парсер этого не знает

Вообще без синтаксиса ответить однозначно нельзя

т.е. это потом человек решит

т.е. foo это или литерал или ссылка

foo!bar точно ссылка