Добавил в сравнение еще Джаву и Петон ....

[orleanz]

$ gtime ./first +RTS -K512M -RTS
23333331666668
3.55

$ gtime python first.py
23333331666668
2.38

$ gtime node first.js
23333331666668
0.20

$ gtime java first
23333331666668
0.11

https://projecteuler.net/problem=1

Хаскель:
isgood n = if (n `mod` 3 == 0) || (n `mod` 5 == 0) then True else False
result = sum $ filter isgood [1..999]
main = do print result

Петон:
res = 0
for x in range(1,10000000):
if x % 3 == 0 or x % 5 == 0:
res += x
print(res)

Джаваскрипт
var res = 0;
for (var i = 1; i <= 9999999; i++) {
if (i % 3 == 0 || i % 5 == 0) {
res += i;
}
}
console.log(res);

Джава
public class first {
public static void main(String[] args) {
long res = 0;
for (long i = 1; i <= 9999999; i++) {
if (i % 3 == 0 || i % 5 == 0 ) {
res += i;
}
}
System.out.println(res);
}
}

Comments

[sli1234.livejournal.com]

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

[orleanz.livejournal.com]

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

[sli1234.livejournal.com]

9999999 укладывается в 32 бита

[thesz.livejournal.com]

Вы -O3 включили ли?

[orleanz.livejournal.com]

так, сейчас вообще какой-то сюр пошел - сегодня после компиляции все работает гораздо быстре, 0.7 сек против 3.5 секунд вчера.

причем сначала я компилил командой

ghc -O2 -rtsopts -with-rtsopts=-K512M first.hs

а потом просто

ghc first.hs

и результаты такие же, опять 0.7 сек вместо вчерашних 3.5 сек...

Вообще ничего не понимаю