Google разрабатывает язык Noop для замены Java

> Это невозможно, результат последующей операции зависит от результата предыдущей. Не?

ну почему же невозможно. допустим надо посчитать факториал от X.

первый поток будет считать X*(X-1)*(X-2)...*(X/2), а второй (X/2 - 1)*(X/2 - 2)*...*2*1.

а потом перемножить 2 получившихся числа.

>Что такое миксины, гуглится что-то про рыб?

rsdn.ru/forum/dictionary/1753095.flat.aspx rsdn.ru/forum/cpp/2979214.aspx rsdn.ru/forum/cpp/268100.flat.aspx

>> укажите точнее, а то "многабукаф"

>Бгг. Вопрос, знаешь ли, не самый банальный. Если кратко, то теперь tid не является pid.

мммм.... это модификация ядра или, условно говоря, обёртка над fork()?

>> а информации по реализации posix threads я там не нашёл...

>Ахренеть, Вообще-то там _вся_ информация - о реализации POSIX threads в Linux.

Ну она реализована таки или нет, а то на документе draft написано?

>Если нет сил читать весь документ, осиль только главы 1, 3, 6.

оке, почитаю :)

> Не могу собрать.

>> Не в обиду, но сразу видно, кто маны не читает :-)

Thx. Я в общем-то на C++ и не пишу.

А так очень годно. Безумно быстро. Питон отдыхает.

> У меня фокс проверяет вполне пристойно. Вот только почему-то авторы этих спеллчекеров забывают, что люди не только один язык используют :(

Просто склейте несколько языков вместе. Согласен, это не столько удобно. Я делал так:
http://www.ugolnik.info/?p=478

> На крейсерской высоте жаба/шарп летят со скоростью 0.5-1 C.

ага, если повезёт - со скоростью С, а если не повезёт - в два раза медленнее.

>На питоне я управился за минуту.

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

7 factorial printNl.

И этот язык появился гораздо раньше питона ;)

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

Ну так в ограничения машины и упирается. в 64-битных процессорах максимальное число 2^64 -1 = 18446744073709551615, а всё остальное - махинации, которые можно производить независимо от языка программирования.

>> Однако пойнт в том, что эта конструкция непереносима.

> Да-да-да! Ну Вы же всё правильно понимаете! :)

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

> Рассказываю вам, как пишутся программы, имеющие заданные критерии производительности.

Это не единственный возможный алгоритм. Точно не самый лучший, и, как вы сами отметили в пункте 4, не гарантирующий успешного результата.

>> Если кратко, то теперь tid не является pid.

> мммм.... это модификация ядра

Это модификация ядра.

> или, условно говоря, обёртка над fork()?

IIRC, в Linux нет fork (он является оберткой над clone).

>>Ахренеть, Вообще-то там _вся_ информация - о реализации POSIX threads в Linux.

> Ну она реализована таки или нет, а то на документе draft написано?

Кхм. Реализована ли NPTL? Да, реализована уж несколько лет как.

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

Если ты заметил, что за последние 20-ть лет сложность проектов возросла в разы, при этом сроки (с эквивалентными деньгами) на разработку практически не менялись. GC (как и высокоуровневые языки) был придуман как раз для того, чтобы разработчик больше концентрировался на поставленной задаче, а не на "выделениях" и "подметаниях". Другое дело, что сейчас ни одной нормальной реализации GC нету

> А что там надрачивать?

В том то и дело, что в очередной раз встречая такую указательную галиматью натасканный плюсатник не срет кирпичами. В нем просыпается многомогучий сишник, который не задается таким глупым вопросом почему это не сделано на STL-ных контейнерах.

> Практика показывает, что 'правильные' языки делают для быдла, не умеющего и не желающего думать.

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

> Людей, лепечущих про сложность языка, на котором написана ОС

С - простой язык. Даже слишком.

> думаю стоит проверить - можете плз написать сюда полный пример кода на Java

Я могу попытаться, но с учётом того, что это будет моя первая программа на жабе...

> То есть в жабе запрещено использовать различные деревья?

В смысле запрещено? Если этого требует предметная область - пользуйтесь на здоровье! А если вы собрались делать ассоцмассив - то лучше воспользуйтесь готовым.

> Другое дело, что сейчас ни одной нормальной реализации GC нету

Ну, если учесть, что GC уже лет пятьдесят, как минимум, а нормальной реализации (по вашим словам все еще нет), то перспективы не радостные :-/

>С - простой язык. Даже слишком.

Так почему его многие так "боятся"?!

[:aString | aString tokenize: ' ']

>> С - простой язык. Даже слишком.

> Так почему его многие так "боятся"?!

Назовите всех поименно.

> 4.2 Выделение памяти под жабой ГОРАЗДО ДЕШЕВЛЕ, чем через malloc. Не в курсе? Бегом читать про перемещающие и генерационные сборщики мусора.

Выделение памяти всегда дорого. Malloc - это очень дорого. Поэтому-то если выясняется, что это - bottleneck проекта, то это оптимизируется. Но для этого надо знать о проблеме, а java-программеры ее игнорируют. Результат - для Java программы типично захватить и удерживать 300M-400M памяти.

> Зачем?! Функциональность модуля должна быть в документации описана. Кроме того, никто не мешает вам нагенерить эквивалент .h файла из жабоисходников каким-то там автодоком. Хедеры не нужны и никогда не были нужны.

Если мне это не нужно, то это не нужно никому. Красивый аргумент. Генерация документации из headers с Doxygen comments занимает несколько секунд, хоть HTML, хоть PDF - это если вы предпочитаете читать с комфортом. Мне достаточно навести мышку на метод и увидеть его полное описание.

>> С++, по сравнению с C, дал возможность применить ООП, не замедляя результат

> То есть, попытались прикрутить высокоуровневые концепции, но язык при этом оставить низкоуровневым. Поэтому-то результат и кошмарен.

Кто (кроме вас) сказал, что результат кошмарен? Если хотите - пишите на высоком уровне, не вдаваясь в детали. Хотите - хоть до Асма спускайтесь. Кто мешает? Ах, да - Java это не может, защищая быдлокодеров от них самих.

> 4.2 Жабокод в среднем существенно короче. Не говоря уже о том, что гораздо читабельнее. А если уж использовать более современные инкарнации, типа C# 4.0, ууу...

Странно - приходилось переписывать куски с Java на C++ - результирующий код всегда короче. Про этот тормоз C# вообще лучше не вспоминать, он еще медленнее, чем Java.

Мы можем долго спорить про удобство языка. Но факт остается фактом. При любых условиях Java программа гарантирована медленнее, разумеется, при использовании одинаковых алгоритмов. Так обьяснит мне кто-нибудь, зачем тормозить систему в несколько раз? Срок разработки проекта на Java (при грамотных программистах, а не индусах) не существенно короче.

> Обьясните - зачем тормозить систему в 2-4 раза (оптимистично)?

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

> У меня в системе обычно нет Java программ

У меня тоже. На десктопе жабе делать нечего.

Зато! У меня есть программы на Python и OCaml. По скорости они летают и память не жрут. Хозяйке на заметку.

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

>Если ты заметил, что за последние 20-ть лет сложность проектов возросла в разы, при этом сроки (с эквивалентными деньгами) на разработку практически не менялись. GC (как и высокоуровневые языки) был придуман как раз для того, чтобы разработчик больше концентрировался на поставленной задаче, а не на "выделениях" и "подметаниях". Другое дело, что сейчас ни одной нормальной реализации GC нету

А почему нету нормальной реализации GC? Ответ прост: концепция простая и хорошая только если смотреть издалека. Посмотрим поближе. Что нужно? выделение памяти и освобождение. Выделение - ладно, просто, тут рассматривать нечего, разве что мелкие оптимизации. А освобождение? Вариант С/С++ - не нужна переменная - освободил память. GC же как определяет нужна переменная или нет, и надо освобождать её память? наверно просматривает кучу данных и метаданных, что уж точно будет намного медленнее, чем просто освободить самому ненужные переменные. И уж особенно такие тормоза будут заметны во всеми любимых больших сферических проектах.

> Ну так в ограничения машины и упирается.

Ограничений у машины два: скорость процессора и объём памяти.

Заморачиваться из-за размера слова - детсад и халтура.

> в 64-битных процессорах максимальное число 2^64 -1 = 18446744073709551615,

Ах ты йоп ты. А как же на 16-битных процессорах раньше? Что, только до 65535 считали, дальше никак?

Сишные быдлокодеры заколебали уже. Никакой теоретической подготовки.

> Это не единственный возможный алгоритм. Точно не самый лучший,

Обоснуйте.

> как вы сами отметили в пункте 4, не гарантирующий успешного результата.

Всегда можно придумать невыполнимую задачу.

>Смолток проприетарен до последнего бита

Вы о реализациях? http://smalltalk.gnu.org

> Ах ты йоп ты. А как же на 16-битных процессорах раньше? Что, только до 65535 считали, дальше никак?

Ну и до скольки ты досчитал на 16-битном процессоре? С каких это пор размер машинного слова не ограничение? Ну и если объём памяти - ограничение, то жабу можно выкинуть.

> Так почему его многие так "боятся"?!

C - очень простой. C++ - очень сложный. Первым можно пользоваться, вторым не стоит. Понятно?

> C - очень простой. C++ - очень сложный. Первым можно пользоваться, вторым не стоит. Понятно?

Конечно, ооп - ещё та фигня. и вместе с С++ надо выкинуть всё остальное ООП, начиная с C# и Java...

Так почему его многие так "боятся"?!

Вот не далее как в пятницу правил mod_fcgid, ничего страшного нет. Вполне доступный сишный код. Понравилось. Сегодня на одном ноде в продашен запустили.

> Результат - для Java программы типично захватить и удерживать 300M-400M памяти.

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

> Мне достаточно навести мышку на метод и увидеть его полное описание.

Хорошая Java-IDE это умеет.

> Странно - приходилось переписывать куски с Java на C++ - результирующий код всегда короче.

Действительно странно.

>В том то и дело, что в очередной раз встречая такую указательную галиматью натасканный плюсатник не срет кирпичами. В нем просыпается многомогучий сишник, который не задается таким глупым вопросом почему это не сделано на STL-ных контейнерах.

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

> А освобождение? Вариант С/С++ - не нужна переменная - освободил память.

А если у вас данные хранятся НЕ в переменной, как вы их будете освобождать?

>> Это не единственный возможный алгоритм. Точно не самый лучший,

> Обоснуйте.

На LOR-е стало принято что-то обосновывать и доказывать? Давненько меня здесь не было :)

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

>> как вы сами отметили в пункте 4, не гарантирующий успешного результата.

> Всегда можно придумать невыполнимую задачу.

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

>Нет, не так же. У неё есть вот:

>http://java.sun.com/javase/6/docs/api/java/math/BigInteger.html

>Кому интересно - могут написать правильный факториал сами, я щас немного занят.

биг_инта пока нет в бусте, но сторонний прикручивается за секунду.

Факториал на c++:

http://pastebin.ca/1572771

Выхлоп:

factor<float>(30)=2.65253e+32

0.05

factor<double>(30)=2.65253e+32

0.06

factor<BigInteger>(30)=265252859812191058636308480000000

24.77

Числа с точкой - время 1000000 вычислений в секундах. Бигинт на 50000% тормознее. Так и весь питон на столько же тормознее плюсов.

Thx. Я в общем-то на C++ и не пишу.

Есть еще вариант с использованием expression templates. Я не заморачивался с заданием произвольного типа для n, но тем не менее:

#include <iostream>
#include <iomanip>

template<typename T, unsigned int n> struct Factorial;

template<typename T> struct Factorial<T, 0> { static const T value = 1; };
template<typename T> struct Factorial<T, 1> { static const T value = 1; };
template<typename T, unsigned int n> struct Factorial { static const T value = n * Factorial<T, n-1 >::value; };

int main(int, char**)
{
        ::std::cout << ::std::setprecision(64) << Factorial<long double, 15>::value << ::std::endl;
        return 0;
}

Фишка в том, что значение факториала вычисляется на этапе компиляции. Отсюда самая высокая скорость вычисления факториала на этапе выполнения :-)))))

Но ограничено всё точностью long double.

> Ну и до скольки ты досчитал на 16-битном процессоре?

Я в детстве радостно колбасил программы на паскале для 286-й тачки. Там был отличный 32-битный тип longint. Да что там! Почитайте описание ассемблера 8086; там вполне себе были инструкции для работы с 32-разрядными целыми.

> С каких это пор размер машинного слова не ограничение?

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

Ну и в чём хранятся данные? В астральном пространстве?

> А почему нету нормальной реализации GC?

А кто сказал, что GC не совершенствуется? Конечно по эффективности, он врядли догонит классический delete, но ради скорости разработки приходится чем-то жертвовать. В противном случае, если мыслить как некоторые, нужно нафиг выкинуть C++, ибо он по производительности уступает Cи, а Cи, в свою очередь, уступает ASM'у. В своё время тоже кричали, "Нафиг нужны тормознутые языки высокого уровня, когда есть быстрый ASM, где управление ресурсами 100% лежит на совести разработчика" ;)

>Ну, если учесть, что GC уже лет пятьдесят, как минимум, а нормальной реализации (по вашим словам все еще нет), то перспективы не радостные :-/

Вообще вряд ли на многопроцессорной системе гц будет тормозить, а большую часть времени выполняться параллельно. Это жаба тормозит. Хотя и современные плюсы не быстрее, например, кде4( наверное единственный крупный сипп проект) с костылями над с++ - qt4 и kdelibs тормозит( и отзывчивость плохая) даже чуть больше чем жаба, хотя может по памяти и выигрывает.

>Не несите чушь. Я С++ ни с чем не сравнивал. Я просто попросил реализацию факториала.

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

> Так что пункты о пересмотре алгоритмов должны следовать еще до пункта "написание самого простого варианта".

Зачем?

> Числа с точкой - время 1000000 вычислений в секундах. Бигинт на 50000% тормознее. Так и весь питон на столько же тормознее плюсов.

Я правильно понял - ты сравниваешь _приближенное_ вычисление факториала в плавающем формате, и _точное_ - в целочисленном формате, и на основании этого делаешь выводы о сравнительной скорости Си++ и Питона?

у меня КДЕ4 не тормозит. ЧЯДНТ?

>Malloc - это очень дорого.

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

>> Так что пункты о пересмотре алгоритмов должны следовать еще до пункта "написание самого простого варианта".

> Зачем?

Затем, зачем используют языки высокого уровня вместо ассемблера -- чтобы трахаться меньше.

> Ну и в чём хранятся данные? В астральном пространстве?

Ну смотрите. У вас есть некоторая структура ABC. У вас есть функция foo, которая возвращает ABC, и функция bar, которая принимает ABC аргументом.

В случае GC-языка вы можете просто написать bar(foo()), и у вас после выполнения этой комбинации автоматически подчистится и промежуточная ABC, и все её вложенные структуры.

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

А представьте случай, когда две переменные ссылаются на одну и ту же структура данных. Одна из переменных вам "не нужна" - вы что, удалите структуру? Ну тогда знакомьтесь: Mr. Dangling Pointer к вашим услугам.

> Хотя и современные плюсы не быстрее, например, кде4( наверное единственный крупный сипп проект) с костылями над с++ - qt4 и kdelibs тормозит( и отзывчивость плохая) даже чуть больше чем жаба, хотя может по памяти и выигрывает.

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

>> С каких это пор размер машинного слова не ограничение?

>Ну для ограниченного сишного быдлокодера, который толком теории программирования не знает и фантазией не обладает - конечно ограничение.

ну допустим ограничение не в 64 бита, но оно всё равно есть. А уж преодоление таких ограничений можно прикрутить к любому языку. А если в языке как бы нет такого ограничения, значит оно просто скрыто от пользователей, НО ОНО ВСЁ РАВНО ЕСТЬ! так же когда переведётся код на машинный язык - будут те же костыли. Только в С++ они не встроены в язык, и их можно достать отдельно, а в питоне они встроены. разницы минимум.

> что они по умолчанию передаются по ссылке

Передается все по значению. Но все переменные - ссылки на изменяемые и неизменяемые объекты. Поэтому передается только копия ссылки.

Хотелось бы знать чем вас это не устраивает.