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

> Как только вы привидетё мне _реально нужный пример_. И не раньше ;)

Допустим, у нас есть иерархия из кучи классов, наследников класса В, с вирт. функциями. Все наследники (D) по размеру маленькие. Я решаю сделать полиморфизм не вида "D* это В*", а еще и вот так: "D это В" (это будет работать быстрее). Для этого можно сделать юнион из В и всех его производных классов.

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

> И опять же, в языке поддерживающем проперти всё решается легко и правильно ;)

Питон поддерживает битовые поля в виде пропертей?

1. В питоне ессно нет битовых полей ;) Питон скорее всего не годиться для задач, где нужны битовые поля :) заведите [range(1000000)] и посмотрите сколько он съест ;)

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

3. Вы заметили, что то что вы приводите скорее исключение чем правило? да то что нужно решает и без юнионов, пусть с чуть большим гемором?

4. Вы наверно не читали моего исходного утверждения. Я не борюсь с юнионом в сях (хотя охотно променял бы его на чтонить другое). Я борюсь против general purpose languages, которые "Да лечим плохо, зато всех одинаково и бесплатно". Нормальные проперти гораздо лучше решат поставленную вами задачу. Вы не привели пример где нужен _именно юнион_, а не что то другое, более подоходящее, а я просил именно это. Тут вы согласны?

Ой. Плохо протал ваш пример. Не понял, почему у вас юнион здесь будет быстрее? при чём тут размер объекта, если есть виртуальные функции?

> Питон скорее всего не годиться для задач, где нужны битовые поля :)

Вполне годится.

> заведите [range(1000000)] и посмотрите сколько он съест ;)

Причем range к битовым полям? В любом случае, use xrange, Luke.

Я про то, что инт в питоне - это референс что дорого, и референс на биты это ересь. Для того и предлагал померять сколько сожрёт такой массив. Битовыые поля, как мне кажется, нужны в задачах где считают каждый байт и ставка на производительность. И на таких задачх, скорее всего птон не подойдёт. Вынести необходимый код в С - да, возможно. Но тогда и битовые поля останутся в сях.

З.Ы. use Py3000, Luke. В нём range() работает уже нормально :)

> инт в питоне - это референс что дорого, и референс на биты это ересь.Для того и предлагал померять сколько сожрёт такой массив

В Питоне есть куча трюков, позволяющих работать с нормальными int, и array.array('i') жрет ровно столько памяти, сколько и в Си.

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

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

> И на таких задачх, скорее всего птон не подойдёт

На некоторых - да, на некоторых - нет.

> use Py3000, Luke. В нём range() работает уже нормально :)

Py 3.0 пока что не существует в природе, а я пользуюсь тем, что есть. ну а когда Py 3.0 появится, на крайний случай напишем xrange = range

К чему такие сложности, как array.array('i'), если можно просто взять PyPy, и писать на RPython, там за вас unboxing для чисел самостоятельно транслятор сделает :-) Вроде как часть, связанную с RPython там почти до конца допилили (по-крайней мере, если транслировать RPython в C), в отличие от интерпретатора большого питона.

> Не понял, почему у вас юнион здесь будет быстрее?

Я не указал одну специфику. Дело в том, что В тут будет заменяться на D (конкретно -- например в парсере, В это Expr, а D это AdditiveExpr) -- именно для этого юнион, чтобы замена была без деаллокации В, аллокации D, и более того, эта замена вообще может быть сделана in-place через дописывание полей.

> при чём тут размер объекта, если есть виртуальные функции?

Размер при том, что у маленьких объектов будет небольшой оверхед (неиспользуемая память внутри юниона).

Указатель на vtbl здесь будет служить тэгом юниона. Именно поэтому используемый юнион должен быть *не* тэгированный.

А вообще -- я уже писал. Юнион -- это способ сказать компилятору "уймись, я знаю лучше, и даже приведение типа писать не будет".

s/писать не будет/писать не буду/

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

>Юнион -- это способ сказать компилятору "уймись, я знаю лучше, и даже приведение типа писать не будет".

Вот против этого я и воюю. Это значит что язык плохо подходит под задачу (в данном случае можно просто выбрать решение покрасивше).

Выводы такие. Хвалёный LISP опять лососнул тунца.

Для обсчёта массива данных размером 20 мегабайт программе на LISP потребовалось более 60 мегабайт динамически выделяемой памяти. Тестирование на 40 мегабайтах данных даёт почти 120 метров хипа. Итак, оверхед в три (!!!) раза по памяти по сравнению с программой на С, которая аллокирует ровно 20*1048576 байт, тютелька-в-тютельку. И да, программа на LISP работает процентов на 10-15 медленнее, чем аналог на С.

Что это значит для заказчика? Что LISP-программа по сравнению с С-шной способна на том же оборудовании обсчитать образец данных, меньший в три раза. Или что для эквивалентной (относительно С) работы LISP-программы требуется в три раза больше памяти. "Копейки, которые стоит память" (любимый аргумент жабщиков и компании) в масштабах производства превращается в миллионы долларов, ну никак не перекрывая вторую часть аргумента: "...что дешевле, чем труд программистов". Никаких других экономических и инженерных бенефитов не видно: производительность? LISP-программа медленнее. Читаемость кода? Ололо, "мешанина из овсянки и обрезков ногтей" (С) Ларри Уолл (спасибо tailgunner за поправку). Управляемость, рефакторинг? Не смешите меня. А это всё как раз и есть компоненты того, что называется "эффективностью решения".

С прискорбием приходится признавать, что Лиспу не место на производстве. Как показал эксперимент, Лисп неэффективен на примитивнейшей практической задаче.

Просьба камраду mv не воспринимать всё вышесказанное лично. Вас же я хочу совершенно искренне поблагодарить за участие в эксперименте и в расстановке точек над i.

>Что LISP-программа по сравнению с С-шной способна на том же оборудовании обсчитать образец данных, меньший в три раза. Или что для эквивалентной (относительно С) работы LISP-программы требуется в три раза больше памяти.

Ты дальше своего быдлобука не видишь. А теперь покажи, как ты сишный код отмасштабируешь для "обсчёта" на кластер, если данных станет не 20M, а 200G?

>С прискорбием приходится признавать, что Лиспу не место на производстве. Как показал эксперимент, Лисп неэффективен на примитивнейшей практической задаче.

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

>> Юнион -- это способ сказать компилятору "уймись, я знаю лучше, и даже приведение типа писать не будет".

> Вот против этого я и воюю. Это значит что язык плохо подходит под задачу (в данном случае можно просто выбрать решение покрасивше).

Вот собственно я *расширяю* язык с помощью юниона, и *пользоваться* моим расширением можно будет типобезопасно, несмотря на то, что внутрях там... юнион :-)

Ну почти типобезопасно. Таки надо будет определить константу "макс. размер производного класса", и в плюсах это сделать может и можно автоматически (через шаблоны), но я для начала ее буду просто ручками определять.

Или перловый скрипт напишу для генержки этого юниона.

>Это значит что язык плохо подходит под задачу (в данном случае можно просто выбрать решение покрасивше).

Какие языки позволяют прямо на месте (т.е. без деаллокации и последующей аллокации) из объекта сделать его производный объект?

> просто аллокатор сделать тупой кастомный

Вообще-то это интересная мысль. Но неизвестно, где придется больше ковыряться.

Потом мой подход будет работать, даже если объекты лежат на стэке, а с аллокаторами как?

>быдлобука

Если мой тезис Вас настолько задел, что заставляет быть столь не в меру эмоциональным, то приношу свои извинения.

>А теперь покажи, как ты сишный код отмасштабируешь для "обсчёта" на кластер, если данных станет не 20M, а 200G?

Вы считаете, что на этот вопрос можно ответить, не зная конкретики задачи, в рамках одного поста на ЛОРе? В таком случае придётся считать Вас дилетантом в области HPC. Впрочем, полагаю, что это действительно так, поскольку каждому мало-мальски знакомому с HPC и параллельными вычислениями ясно, что успешность масштабируемого решения зависит в первую очередь от самой задачи (от её "паралеллируемости"), а уж во вторую очередь от технологий. Если рассматривать вышеприведённую задачу, то средствами С (или Fortran), MPI и, возможно, распределённой файловой системы задача решается почти 100% масштабируемо (т.е. с линейным ростом производительности при увеличении вычислительных мощностей).

Как можно догадаться по Вашим словам, Вы считаете, что у Лиспа здесь будет преимущество. Но даже если допустить, что будет достигнута такая же масштабируемость, то кластер под LISP сможет обсчитывать втрое меньше данных и на 10-15% медленнее. Или понадобится кластер, в три раза бОльший. Руководитель проекта рассмеётся Вам в лицо.

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

Уж не говоря о том что этой памяти схавалось именно на задачу - 20 метров. Все остальное схавал лисп.

>Ты уже доказал что производство индустриальной программы на С вообще окупиться, выйдет в разумные сроки или за разумное время?

Доказать этот факт невозможно. Если человек берётся предсказывать время решения сложной индустриальной задачи до начала её решения - этот человек шарлатан. Программирование - это не строительство типовых многоэтажек, тут не работает классический подход.

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

Не берусь утверждать, насколько быстрее будет решена задача благодаря "преимуществам" Лисп как языка. Но точно скажу, где будет проигрыш. Основной аргумент поборников Лисп звучит так: "пока сишники будут клепать свой код, лиспер уже напишет DSL". Забывают только вто что. Писать надо не только DSL и его транслятор, но и рантайм, и дебаггер, и профайлер. Отладка DSL "per se" невозможна. Таким образом, незадачливый LISP-warrior оказывается на перепутье: 1) решать задачу в старом добром императивном стиле, безо всяких DSL, 2) разрабатывать DSL с полной обвязкой (см. выше), 3) писать на "голом" DSL без средств разработки.

Эта ситуация напоминает мне анекдот. Едет богатырь по дороге, встречает камень, а на камне написано: "Пойдёшь направо - п*ды получишь. Пойдёшь налево - п*ды получишь. Прямо поедешь - п*ды получишь." Стоит богатырь, головушку склонил, думу думает, куда поехать. И тут с дерева голос: "Решай давай скорее, а то прямо здесь п*ды получишь!"

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

Я уж не говорю о том, что для Лисп отсутствуют полноценные IDE и возможности рефакторинга. А формулировки задач имеют свойство меняться со временем. В результате код растёт, как снежный ком, наворачиваются всё новые слои, и рано или поздно наступает катастрофа, когда программист признаёт, что для внесения минимальных изменений требуется переписать всё с нуля. Это не мешает лисперам презирать и отрицать IDE "за их ненадобностью".

Пожалуйста, будьте внимательнее. При формулировке задачи (http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3274118) говорилось:

> 4*) задача со звёздочкой, олимпиадная, самая сложная :) не задавать вопросов типа "а зачем так, а ведь можно по-другому" и тому подобных. Задача сформулиролирована как минимальная из класса задач на вычисления на больших массивах, не решаемых в один проход (в режиме потока). Реальные задачи сложнее, я всего лишь берегу ваши силы.

Вы с этой задачей не справились.

>Уж не говоря о том что этой памяти схавалось именно на задачу - 20 метров. Все остальное схавал лисп.

Это неважно. На задачу в целом "зохавывется" памяти ровно в три раза больше, чем исходный массив, при любом размере массива. Для того же самого решения на Си - ровно по размеру массива.

Я ничего не имею против Лисп как такового. Это фундаментальный, математически красивый академический язык. Знакомство с ним рекомендуется в любом случае, как для повышения общей программистской культуры, так и в целях исторических.

Я против возведения Лиспа в культ. Я против бездумного поклонения Лиспу как панацее. Я практик, и желаю донести до сообщества простую идею - практическая ценность Лиспа невелика. Я хочу, чтобы у неофитов не возникало иллюзий насчёт самого языка и самопровозглашённой, дутой "элитарности" лисп-программистов. Филологи тоже изучают мёртвые языки - латынь, древнегреческий, древнеславянский, санскрит - но ни одному из них не придёт в голову провозгласить себя элитой науки, а изучаемый язык - превосходящим все остальные. Это хороший пример для подражания.

> Доказать этот факт невозможно

Как раз. А ты думаешь с какой целью разрабатывают все эти отличные от С языки? На хрустальном шаре нагадали?

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

Не надо разводить эту бойдень. Вот программа на лиспе. Хочу увидеть аналог на С. Только корректный а не там где забыли все проверить.

>По какой бы дорожке он ни пошёл, сишник обскачет его с лихвой.

Ну да - доказано чтением из урандом.

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

Зато для С их завались.

>А формулировки задач имеют свойство меняться со временем.

О чем следует помнить когда выбираешь такой мегаинструмент как С - насколько просто будет все менять.

>Вы с этой задачей не справились.

Ткните меня где сказано что отклонения надо считать в массив, а потом плевать в файл? Не вижу.

>Это неважно.

Это принципиально важно. Увеличение объема входных данных не увеличивает размер рантайма. Если хело ворлд занимает 10 байт + размер рантайма - то 10x хело ворлд занимает 10*10 + размер рантайма, а не 10*(10 + рантайм).

ТА хоть графологи - при чем тут лисп? Предложение не ограничивалось лиспом - просто решение предложили на лиспе.

>А ты думаешь с какой целью разрабатывают все эти отличные от С языки? На хрустальном шаре нагадали?

Пожалуйста, не передёргивайте. Какое отношение это имеет к исходной посылке? Напомню, речь шла вот о чём:

>>Ты уже доказал что производство индустриальной программы на С вообще окупиться, выйдет в разумные сроки или за разумное время?
>Доказать этот факт невозможно.

По крайней мере, в рассматриваемой области (высокопроизводительные вычисления на больших объёмах данных) С и Фортран пока что не удалось переплюнуть никому.

>Не надо разводить эту бойдень. Вот программа на лиспе. Хочу увидеть аналог на С. Только корректный а не там где забыли все проверить.

Вы снова передёргиваете и уходите от темы. Речь шла о том, что DSL вовсе не является волшебной серебряной пулей, ибо на практике сталкивается с множеством проблем. О какой, кстати, программе идёт речь? О вышеприведённом подсчёте среднего и отклонений? Программа (с проверками) занимает около 20 строк, работает быстрее лисповой и аллокирует хипа ровно по размеру массива (плюс пренебрежимо малые структуры, аллокируемые fopen(), если работать с файлами, а не stdin/stdout).

>Ну да - доказано чтением из урандом.

Вы цепляетесь к несущественным мелочам. /dev/urandom - самая незначительная, незначимая часть программы, данные могли быть взяты откуда угодно.

>Зато для С их завались.

Да, это так. Для С/С++ имеется множество IDE с поддержкой рефакторинга, как коммерческих, так и open source. Из последних - NetBeans и Eclipse.

>О чем следует помнить когда выбираешь такой мегаинструмент как С - насколько просто будет все менять.

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

Либо проигрывают на обоих фронтах, как Лисп.

>Увеличение объема входных данных не увеличивает размер рантайма.

Для нашей задачи, тем не менее, это неверно. При увеличении массива до 40 мегабайт памяти отжирается уже почти 120 мегабайт.

Засим вынужден откланяться на несколько часов.
Если у Вас будут интерес и силы, пожалуйста, подкорректируйте вышеприведённую программу на LISP, чтобы аллокировался только один массив. И проверьте аллокацию хипа на 10, 20 и 40 мегабайтах, а то и на бОльшем количестве контрольных точек. Спасибо.

>Речь шла о том, что DSL вовсе не является волшебной серебряной пулей, ибо на практике сталкивается с множеством проблем.

На какой практике? Чтения из урандом? Хочу видеть реализацию на С без всяких дслэй вот такого DSL "SELECT * FROM mytable WHERE...". Вот вам и DSL и практика.

>Программа (с проверками) занимает около 20 строк

Значит сюда вместится.

>Вы цепляетесь к несущественным мелочам. /dev/urandom - самая незначительная, незначимая часть программы, данные могли быть взяты откуда угодно.

Урандом тут нерелевантен - просто доказывать... как это "проблемы DSL на практике" размером хипа от меода подсчета отклонений по массиву данных - это гениально просто.

>Да, это так. Для С/С++ имеется множество IDE с поддержкой рефакторинга, как коммерческих, так и open source. Из последних - NetBeans и Eclipse.

Которые почему-то забыли написать на С. Не секут они про размеры хипа и методы обгона коммон лиспа.

>либо, наоборот, хорошо рефакторируемы, но неэффективны (как Java).

О жабе - ниже.

Ниже это тут - реализация на Scala/Java:

import java.io._

object Calc {
  def mem = println("total:" + Runtime.getRuntime.totalMemory +
          ", free: " + Runtime.getRuntime.freeMemory +
          ", max:" + Runtime.getRuntime.maxMemory +
          ", allocated: " + (Runtime.getRuntime.totalMemory - Runtime.getRuntime.freeMemory))

  def doit(size: Int) = {
    println("for " + size)
    val data = new Array[Byte](size)
    val file = new RandomAccessFile("/dev/urandom", "r")
    file.read(data)
    file.close
    var ave = data.foldLeft(0)(_ + Math.abs(_)) / size
    val fos: FileOutputStream = new FileOutputStream("deviavtion")
    for (x <- data) fos.write(Math.abs(x) - ave)
    fos.close
    mem
  }

  def main(args: Array[String]) = for (i <- 0 to 5) {
    doit(0xA00000 + (i * 0x100000))
    System.gc
    println("postgc")
    mem
  }
}

Параметры запуска: -Xmx16M

Как видно программа постоянно увеличивает размер массива на 1 мегабайт. Результат:

for 10485760
total:15863808, free: 4358376, max:16711680, allocated: 11505432
postgc
total:15863808, free: 15589432, max:16711680, allocated: 274376
for 11534336
total:15863808, free: 3147208, max:16711680, allocated: 12716600
postgc
total:14749696, free: 14476624, max:16711680, allocated: 273072
for 12582912
total:14749696, free: 1674648, max:16711680, allocated: 13075048
postgc
total:10846208, free: 10585168, max:16711680, allocated: 261040
for 13631488
total:16711680, free: 2001184, max:16711680, allocated: 14710496
postgc
total:5181440, free: 4920456, max:16711680, allocated: 260984
for 14680064
total:16711680, free: 813904, max:16711680, allocated: 15897776
postgc
total:5181440, free: 4920688, max:16711680, allocated: 260752
for 15728640
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Ограничение стоит на весь хип ждя скалодабы 16 метров - что и 
показывает max. Как видно выделенная память растет ровно на мегабайт с
 каждой итерацией - и когда доросли до предела разрешенного хипа - 
получили втык от JVM - то есть потребление памяти ровно тютелька в 
тютельку - и эти фантазии про "в 3 раза". Надо будет 200 метров - 
будет схавано 200.

>Как видно выделенная память растет ровно на мегабайт с
каждой итерацией - и когда доросли до предела разрешенного хипа -
получили втык от JVM - то есть потребление памяти ровно тютелька в
тютельку - и эти фантазии про "в 3 раза". Надо будет 200 метров -
будет схавано 200.

Справедливости ради:

# ps ax|grep java
...
17634 pts/7 Sl+ 5:19 /usr/lib/jvm//sun-jdk-1.6/bin/java -Xmx384m -Xms128m -server -agentlib:yjpagent -classpath /opt/yjp-5.1.2/lib/yjp.jar:rrd4j-2.0.1.jar:jbforth.jar:bsf.jar:bsh-2.0.jar:jyth on.jar:c3p0-0.9.1.jar:mysql-connector-java-5.0.6-bin.jar:javolution.jar:javax.se rvlet.jar:org.mortbay.jetty.jar:commons-logging.jar:jsr166x.jar:l2jserver.jar l2f.gameserver.GameServer

Однако:

# top -b -n1|grep 17634
17634 l2j 20 0 1076m 644m 350m S 4 25.4 5:22.48 java

10551 93.3 2.5 135952 26236 pts/2 Sl+ 06:55 0:05 /usr/lib/jvm/java-1.6.0.u6-sun-1.6.0.u6/bin/java -Xmx16M -cp /opt/dev/scala/lib/sbaz.jar:/opt/dev/scala/lib/sbaz-tests.jar:/opt/dev/scala/li b/scala-compiler.jar:/opt/dev/scala/lib/scala-dbc.jar:/opt/dev/scala/lib/scala-l ibrary.jar:/opt/dev/scala/lib/scala-swing.jar -Dscala.home=/opt/dev/scala -Denv.classpath= -Denv.emacs= scala.tools.nsc.MainGenericRunner Calc


26M резидентной памяти из них 16 под управление JVM.

> Причиной является слишком сложная система типов Scala

У поциэнта прогресс. Наконец-то дошло, что "изобретать велосипеды из руды" (с) не нужно.

Лично я в Джаве не разочарован. :))))

Это значит, надо на эту Скалу посмотреть обязательно. Наверное, дельная вещь.

"Шарик, ты дурак!" (c)

Из 60 метров 40 сразу после загрузки занято окружением (рантайм, компилятор). И если лисповая программа работает всего на 10-15% медленнее сишной, то это просто смерть для си. К сожалению, на 10-15% медленнее может работать разве что SBCL, да и то, не во всех случаях.

Давайте я вам теперь задачку дам: программа в рантайме считывает из файла в строку программу и выполняет её, изменяя окружение.

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

> Ты дальше своего быдлобука не видишь. А теперь покажи, как ты сишный код отмасштабируешь для "обсчёта" на кластер, если данных станет не 20M, а 200G?

Начнёт использовать MPI? И чем ему Лисп тут поможет? :)

> Как можно догадаться по Вашим словам, Вы считаете, что у Лиспа здесь будет преимущество. Но даже если допустить, что будет достигнута такая же масштабируемость, то кластер под LISP сможет обсчитывать втрое меньше данных и на 10-15% медленнее. Или понадобится кластер, в три раза бОльший. Руководитель проекта рассмеётся Вам в лицо.

Как верно было замечено, всё зависит от сложности задачи. Для лиспа решаемая сложность гораздо выше, потому что лисп банально выше уровнем.

И посмотрите, на конец, на распределение памяти! Из выделенных данных непосредственно под массивы отведено 20 мб. Если вы считаете, что си тут на белом коне, то гляньте на ваш процесс pmap'ом: полный размер адресного пространства со всеми библиотеками и будет являться эквивалентом тому, что вы за выделенные данные в лиспе приняли ;)

> чему такие сложности, как array.array('i')

Это совсем не сложно.

> можно просто взять PyPy, и писать на RPython

Текущий PyPy медленнее CPython и вообще еще не вышел из экспериментальной стадии.

> Да, это так. Для С/С++ имеется множество IDE с поддержкой рефакторинга, как коммерческих, так и open source. Из последних - NetBeans и Eclipse.

Я вас огорчу, но лучше Emacs + Slime я среды разработки вообще не видел. И про рефакторинг, тем более коммерческий, вообще промолчу. В мире лиспа совершенно другой подход к разработке, в котором рефакторинг не особо нужен (а нужен вообще?). Из ваших постулирований абсолютно ясно, что к лиспу вы никакого отношения не имеете, так что давайте не будете прикрывать анонимностью своё невежестно?

собственно программа на С

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

#define SIZE 20 * 1024 * 1024

int main()
{
   unsigned char*   data = NULL, item = 0;
   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++)
   {
      item = data[i] - (unsigned char)m;
      fwrite(&item, 1, 1, f);
   }
   fclose(f);

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

	return 0;
}

памяти 21020К, вместе со всеми длл-ками 22604К, работает 2,5 с.

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

Неужели программист на Си не знает, как кошмарно дОрог каждый syscall? Возможно, libc и занимается буферизацией для fwrite, но ваш подход всё равно печален.

в случае с С вместе с длл-ками кстати считать не совсем корректно, т.к. общие длл-ки типа kernel32.dll ntdll.dll msvcrt.dll они в памяти пожизни находятся и только отображаются в адресное пространство процесса. Т.о. дополнительная память на каждый процесс не тратится. В случае же лиспа видимо на каждый процесс по 40 мегов отожрется. Вот как на таком языке hello, world-ы писать, этож из-за программы в 20 символов будет грузиться рантайм на 40 мега, жуть.