Создатель Python разочарован в Scala

> ЗЫ: делал под виндой, там urandom-а нету, так что через обычный генератор случайных чисел

Ничего страшного. Теперь можете моё задание сделать :)

> Вот как на таком языке hello, world-ы писать, этож из-за программы в 20 символов будет грузиться рантайм на 40 мега, жуть.

Видите ли, на лиспе традиционно не принято писать hello world'ы. Это будет по своей сути ещё хуже, чем микроскопом гвозди забивать.

мы про дороговизну syscall-ов или про объем занимаемой памяти ?

хорошо, пусть будет по-вашему

#include <stdio.h> #include <conio.h> #include <stdlib.h> #include <time.h>

#define SIZE 20 * 1024 * 1024

int main() { unsigned char* data = NULL; size_t i = 0; unsigned __int64 m = 0; FILE* f = NULL;

srand(time(NULL)); data = (unsigned char*)malloc(SIZE); for (i = 0; i < SIZE; i++) data[i] = rand(); for (i = 0; i < SIZE; i++) m += data[i]; m /= SIZE; f = fopen("deriv.dat", "wb"); for (i = 0; i < SIZE; i++) data[i] -= (unsigned char)m; fwrite(data, SIZE, 1, f); fclose(f);

printf("Average value: %d\n", m); _getch();

return 0; }

работать стало действительно быстрее, 0,39 с.

извиняюсь за форматирование

мы про дороговизну syscall-ов или про объем занимаемой памяти ?

хорошо, пусть будет по-вашему

#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <time.h>

#define SIZE 20 * 1024 * 1024

int main()
{
   unsigned char*   data = NULL;
   size_t           i    = 0;
   unsigned __int64 m    = 0;
   FILE*            f    = NULL;

   srand(time(NULL));
   data = (unsigned char*)malloc(SIZE);
   for (i = 0; i < SIZE; i++)
      data[i] = rand();
   for (i = 0; i < SIZE; i++)
      m += data[i];
   m /= SIZE;
   f = fopen("deriv.dat", "wb");
   for (i = 0; i < SIZE; i++)
      data[i] -= (unsigned char)m;
   fwrite(data, SIZE, 1, f);
   fclose(f);

   printf("Average value: %d\n", m);
   _getch();

	return 0;
}

работать стало действительно быстрее, 0,39 с.

> Возможно, libc и занимается буферизацией для fwrite

Что значит "возможно"? :D Занимается, естественно, для того stream I/O и сделан.

> но ваш подход всё равно печален.

Классически написанная прога. Я бы сказал, повеяло духом 80-х :)

> Видите ли, на лиспе традиционно не принято писать hello world'ы. Это будет по своей сути ещё хуже, чем микроскопом гвозди забивать.

дык вот и непонятно какие программы-то на нем писать, hello world'ы значит не принято, обычного софта массового назначения тоже как-то не наблюдается, все больше на С пишут. Видимо все вокруг просто дураки, не знают что можно оказывается на лиспе программы писать, пишут по-старинке на С.

> работать стало действительно быстрее, 0,39 с.

Анонимный брат, а попробуй setvbuf(data, _IOFBUF, 65536)

> Классически написанная прога. Я бы сказал, повеяло духом 80-х :)

спасибо за комплимент

> Анонимный брат, а попробуй setvbuf(data, _IOFBUF, 65536)

есть мнение, что из-за этого повысится объем занимаемой памяти. Задача ведь не стояла сделать программу быстрее, мы тут объемами занимаемой памяти меряемся.

>> Анонимный брат, а попробуй setvbuf(data, _IOFBUF, 65536)

> есть мнение, что из-за этого повысится объем занимаемой памяти.

Конечно, но зато классичность будет соблюдена, а 64К по сравнению с 20М всё равно ничего не значат.

хорошо

#include <stdio.h> #include <conio.h> #include <stdlib.h> #include <time.h>

#define SIZE 20 * 1024 * 1024

int main() { unsigned char* data = NULL; char* io_buff = NULL; size_t i = 0; unsigned __int64 m = 0; FILE* f = NULL;

srand(time(NULL)); data = (unsigned char*)malloc(SIZE); for (i = 0; i < SIZE; i++) data[i] = rand(); for (i = 0; i < SIZE; i++) m += data[i]; m /= SIZE; f = fopen("deriv.dat", "wb"); io_buff = (char*)malloc(65536); setvbuf(f, io_buff, _IOFBF, 65536); for (i = 0; i < SIZE; i++) data[i] -= (unsigned char)m; fwrite(data, SIZE, 1, f); fclose(f);

printf("Average value: %d\n", m); _getch();

return 0; }

быстрее кстати не стало, те же 0,4 с.

опять извиняюсь за форматирование

#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <time.h>

#define SIZE 20 * 1024 * 1024

int main()
{
   unsigned char*   data    = NULL;
   char*            io_buff = NULL;
   size_t           i       = 0;
   unsigned __int64 m       = 0;
   FILE*            f       = NULL;

   srand(time(NULL));
   data = (unsigned char*)malloc(SIZE);
   for (i = 0; i < SIZE; i++)
      data[i] = rand();
   for (i = 0; i < SIZE; i++)
      m += data[i];
   m /= SIZE;
   
   f = fopen("deriv.dat", "wb");
   io_buff = (char*)malloc(65536);
   setvbuf(f, io_buff, _IOFBF, 65536);
   for (i = 0; i < SIZE; i++)
      data[i] -= (unsigned char)m;
   fwrite(data, SIZE, 1, f);
   fclose(f);

   printf("Average value: %d\n", m);
   _getch();

	return 0;
}

> дык вот и непонятно какие программы-то на нем писать, hello world'ы значит не принято, обычного софта массового назначения тоже как-то не наблюдается

Примерно такие:

http://www.franz.com/success/

http://www.lispworks.com/success-stories/index.html

http://www.gnu.org/software/emacs/

> http://www.gnu.org/software/emacs/

оно и заметно, http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/

> оно и заметно, http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/

Что заметно? Что часть имакса написана на Ц? Ну так, это скорее по историческим причинам. Почти все плюшки, которыми ценен имакс написаны на ELisp. Хотите полностью на лиспе, посмотрите на Climacs. Это не принципиально важно, на самом деле.

Кстати, а где у вас второй массив на 10мб, про который в задании говорилось? ;)

> оно и заметно, http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/

Кстати, на чем там jvm написана? Это означает что все жабапрограммы написаны на Ц++? :)

> оно и заметно, http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/

Да как такое не заметить. Интерфейс между программой и юниксом должен быть на Си написан ;) То ли дело Zmacs... А ещё на лисп-машинах такой здоровый рантайм с собой таскать не надо.

> В мире лиспа совершенно другой подход к разработке, в котором рефакторинг не особо нужен (а нужен вообще?)

Лисперы всё делают правильно с первого раза, а требования к прогам на Лиспе никогда не меняются? ;)

> Лисперы всё делают правильно с первого раза, а требования к прогам на Лиспе никогда не меняются? ;)

Нет, требования меняются, а программисты - всё те же косячные люди :) Просто лисповый код проще модифицировать.

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

о!, а там должен быть второй массив на 10 мб ?

> 1) считать из /dev/urandom 10 мегабайт мусора (пусть это Xn, n=1..10M) в память; > 2) посчитать среднее (M=sum(Xn), n=1..10M) и отклонения Dn=|Xn-M| > 3) сплюнуть отклонения в файл, в результате должно получиться ещё 10 мегабайт мусора > 4*) задача со звёздочкой, олимпиадная, самая сложная :) не задавать вопросов типа "а зачем так, а ведь можно по-другому" и тому подобных. Задача сформулиролирована как минимальная из класса задач на вычисления на больших массивах, не решаемых в один проход (в режиме потока). Реальные задачи сложнее, я всего лишь берегу ваши силы. > 5) запустить получившуюся программу под valgrind, чтобы померять выделение оперативной памяти.

нифига не должно быть там 10М дополнительного массива, единственное че я невнимательно читал, там данных всего 10М, что в программе на С позволяет ещё кардинально уменьшить потребление памяти

> о!, а там должен быть второй массив на 10 мб ?

Тогда я не понимаю, откуда должно взяться ещё 10 мб мусора...

> 3) сплюнуть отклонения в файл, в результате должно получиться ещё 10 мегабайт мусора

Поясните, откуда возьмётся мусор?

> Тогда я не понимаю, откуда должно взяться ещё 10 мб мусора...

очень просто, 10М мусора образуется из исходных 10М мусора, каждый элемент которые есть разница между соответствубщим элементом исходного мусора и средним

ЗЫ: кстати, есть мнение что в 10М мусора среднее всегда будет 127, поэтому массивов вообще можно не заводить и данные в памяти не хранить

> ЗЫ: кстати, есть мнение что в 10М мусора среднее всегда будет 127, поэтому массивов вообще можно не заводить и данные в памяти не хранить

Есть мнение, что вышеприведённая сишная программа девиацию неправильно считает, потому что unsigned - unsigned может получиться signed. А в программе будет overflow. Сколько проблем в такой маленькой программе...

А между тем, лисповый (питоновый) программист уже давно всё обсчитал, получил деньги, пропил. А сишный всё продолжает отладку и оптимизацию, ибо первый вариант считает неправильно и работает даже медленнее лиспового ;) О чём в это треде и сообщалось ранее. И не только в этом.

И ещё явного free() не видно. Конечно, ядро всё подчистит, когда процесс убивать будет, но, опять же, потенциальный баг в сишной программе. Для полного счастья ещё работу со строками вставить остаётся... ;)

> Есть мнение, что вышеприведённая сишная программа девиацию неправильно считает, потому что unsigned - unsigned может получиться signed. А в программе будет overflow. Сколько проблем в такой маленькой программе...

есть мнение, что в данном случае абсолютно пофиг, хотя конечно лучше char таки поставить, да. Но результат от этого не зависит

> А между тем, лисповый (питоновый) программист уже давно всё обсчитал, получил деньги, пропил. А сишный всё продолжает отладку и оптимизацию, ибо первый вариант считает неправильно и работает даже медленнее лиспового ;) О чём в это треде и сообщалось ранее. И не только в этом.

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

> И ещё явного free() не видно. Конечно, ядро всё подчистит, когда процесс убивать будет, но, опять же, потенциальный баг в сишной программе. Для полного счастья ещё работу со строками вставить остаётся... ;)

ну free да, согласен, добавить не мешает, хоть в данном случае и абсолютно пофиг

Есть мнение, что для числодробительных задач лучше использовать OCaml. Он хоть с типами осторожнее работает, а также за памятью следит. И абстрагироваться от low level'а побольше даёт.

> это почему это первый вариант неправильно работает, все правильно работает,

Докажите математику, что 1 - 2 = 254.

> это че-то меня прожженые лисперы начали вдруг упрекать типа syscall-ов много.

У меня работа связана, в том числе, с сисколлами ;)

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

Тебя, наверное, удивит, но в стандарте языка есть функция disassemble ;)

> но, опять же, потенциальный баг в сишной программе.

Ну вот передергивать не надо %)

> Ну вот передергивать не надо %)

А я не передёргиваю :) Можно таким же макаром утверждать, что segfault - это не ошибка, ядро же OOPS не выдаёт.

> Докажите математику, что 1 - 2 = 254.

причем тут это, результат в результирующем файле правильный и это главное

> Тебя, наверное, удивит, но в стандарте языка есть функция disassemble ;)

в стандарте языка лисп ?

> И абстрагироваться от low level'а побольше даёт.

то про "абстрагироваться", то про сисколлы, не поймешь тебя её богу

> в стандарте языка лисп ?

Да. http://www.lispworks.com/documentation/HyperSpec/Body/f_disass.htm На реализациях лиспа, имеющих компилятор в машинный код, disassemble выдаёт дизассемблированный код. На реализациях с байткодом и виртуальной машиной выдаёт читабельное представление байткода.

> то про "абстрагироваться", то про сисколлы, не поймешь тебя её богу

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

> Да. http://www.lispworks.com/documentation/HyperSpec/Body/f_disass.htm На реализациях лиспа, имеющих компилятор в машинный код, disassemble выдаёт дизассемблированный код. На реализациях с байткодом и виртуальной машиной выдаёт читабельное представление байткода.

надо же. Не зря все-таки 40 мега расходуются, вот даже дизассемблер там есть

>> Ну вот передергивать не надо %)

> А я не передёргиваю :)

Передергиваешь :) Ни один Си-прогер в своем уме не станет встраивать куда-то содержимое функции main, как раз из-за обычая писать в ней такие вещи.

> Можно таким же макаром утверждать, что segfault - это не ошибка

Я не понял, причем тут segfault, но он тоже не всегда ошибка (и ты об этом наверняка знаешь ;))

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

ну тут согласен, про эффективность надо думать всяко

А оно не собралось всё ещё в первой генерации?

> Писать надо не только DSL и его транслятор, но и рантайм, и дебаггер, и профайлер

Вообще-то всё перечисленное - это сам Лисп. Писать надо только транслятор DSL в Лисп, а остальное уже есть.

Ну да тебе этого не понять, ты явно ограниченный.

> Я уж не говорю о том, что для Лисп отсутствуют полноценные IDE и возможности рефакторинга.

Дурак. REPL - самая полноценная IDE по определению, а уж возможности рефакторинга Лиспа в рантайме не позавидует только такой же элитарный Smalltalk, остальные нервно курят.

>> Докажите математику, что 1 - 2 = 254.

>причем тут это, результат в результирующем файле правильный и это главное

С поциентом всё ясно...

> Я практик, и желаю донести до сообщества простую идею - практическая ценность Лиспа невелика

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

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

В реальных практических задачах лиспер ВСЕГДА уделывает сишника, обратного за всю историю человечества не наблюдалось ни разу.

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

лол, однозначно

Ещё один студентошкольник? Гуляй мимо, детко.

> В реальных практических задачах лиспер ВСЕГДА уделывает сишника, обратного за всю историю человечества не наблюдалось ни разу.

Правильно. Поэтому мы все сейчас пишем на Лиспе %)

> В реальных практических задачах лиспер ВСЕГДА уделывает сишника, обратного за всю историю человечества не наблюдалось ни разу.

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