Вышла первая версия компилятора D, написанная на D

Не вычитал пост перед отправкой.

long len = fread( buf.ptr, 1, buf.sizeof, stdin );

в сишной версии было int len.

когда размер файла больше 4096

Имелось в виду 4096 строк

тратить время где его можно не тратить это всегда хорошо

Имелось в виду _не_ тратить

Ну в D все-таки не 100% сишный стиль, различия там есть. Просто это облегчает переход на D, но разница все равно есть. Со временем по мере изучения языка человек переходит на более идиоматический код.

Имелось в виду 4096 строк

Это конечно здорово указывать на недостатки, которые уже были сразу указаны под решением. Но зачем? Что вариант на С, что на D не годятся для реальных задач. Объяснить что не так с кодом на D?

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

Тут я позволю себе с вами не согласится. Речь шла о полноценном аналоге кода, в качестве него был приведен урезанный по возможностям и более громоздкий вариант. Так что я вполне справедливо указал на это.

Объяснить что не так с кодом на D?

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

А вот и идиот, давай свой вариант.

За бесплатно код пишут только идиоты :-)

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

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

За бесплатно код пишут только идиоты :-)

Как не зайду на ЛОР - ты тут как тут, так что свое время ты уже совершенно бесплатно тратишь. И твоя фраза про «за бесплатно» не больше чем натужная попытка представить себя чуть важнее чем пустое место.

За бесплатно код пишут только идиоты :-)

А советы сменить C++ и D на C кто дает?

PS. Ваш вариант на чистом C где?

Как-то так:

Вообще-то совсем не так :)

Окай:

writeln( sort( by_line( file( "file.txt" ) ) );

Это мои библиотечные функции, + я использую boehmgc, чтоб не чистить память. Да ее тут и не надо чистить в принципе. Так сойдет? ;)

Адекватное решение будет использовать сортировку слиянием, а не тупо сразу сортировать все скопом.

Согласен.

Кроме того в коде на D так же нет ни одной проверки

Каких проверок именно не хватает на ваш взгляд?

программа вылетит не с сегфолтом, а с исключением, что один хрен никому не нужно

В том то и дело, что сишная версия не вылетает. Вообще. Она отрабатывает, просто выдает _мусор_. А дишная версия выделит столько памяти, сколько нужно и тоже не вылетит. Зато выдаст _верный_ результат. Вот вам и пример convenience, power и efficiency(ну к этому пункту в данном случае можно придраться, конечно, но если в качестве efficiency еще рассматривать productivity, тогда уже не придраться)

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

Не окай. Никто не может скомпилировать и сравнить скорость работы. Думаю, D-шники с удовольствием бы это проделали.

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

Не окай. Никто не может скомпилировать и сравнить скорость работы.

Скорость будет где-то на уровне как раз D. По сути будут те же действия.

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

Не просто, но даже программы на С++, вроде inkscape, его используют. Хотя, конечно, это редкие исключения.

Скорость будет где-то на уровне как раз D.

Бла-бла-бла. Код где?

Каких проверок именно не хватает на ваш взгляд?

Самое простое - на открытие файла.

В том то и дело, что сишная версия не вылетает. Вообще. Она отрабатывает, просто выдает _мусор_.

Ну так это ты так собрал, что оно выдает мусор. А у меня:

test.c:4:5: runtime error: index 4096 out of bounds for type 'char *[4096]'

Бла-бла-бла. Код где?

В библиотеке, ясное дело. А библиотека в репозитории. А репозиторий на приватном сервере.

Код покажите, который можно скомпилировать и запустить.

А если серьезно - а почему скорость должна будет отличаться? Из-за GC? Ну так он есть и в D. При желании и там и там можно им управлять.

А если серьезно

Если серьезно, то о скорости нужно говорить имея на руках результаты замеров правильно работающих программ.

Пока нет работающей программы говорить вообще не о чем.

Если серьезно, то о скорости нужно говорить имея на руках результаты замеров правильно работающих программ.

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

Кроме того с разными компиляторами, с разными опциями, на разном железе, с разными данными можно получить результаты очень сильно отличающиеся. И это будет совсем не разница в языках или решениях. Так что не нужно торопиться и бежать что-то мерять.

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

Во-вторых, суть сравнения более высокоуровневого языка с менее высокоуровневым (в данном случае D и C) заключается в демонстрации количества усилий, необходимых разработчику для достижения поставленной цели. Грубо говоря, сколько времени придется потратить на написание кода, сколько ошибок в нем придется исправить и т.д. Уже после этого можно будет сравнивать скорость работы кода. И, вполне может так получиться, что из-за неудачной реализации работы с памятью, а так же наличием большого количества проверок кодов ошибок и пр. низкоуровневый код вполне может оказаться не быстрее высокоуровневого.

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

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

Думаю, что если бы кому-то из отметившихся здесь D-шников дали C-шный код с решением, они бы с удовольствием сравнили бы на своем железе оба решения — C-шное и D-шное. В том числе и с разными опциями компиляции.

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

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

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

Ну да, он где-то таким и будет. Я так и писал. Даже медленнее может быть, если пытаться в лоб «эмулировать» какие-нибудь высокоуровневые вещи. Что в задаче выше не надо делать. И в общем и целом что С, что С++, что D, что Rust, позволяют писать одинаково эффективный код. За разницей в оптимизациях на уровне железа или в необходимости писать больше руками.

Думаю, что если бы кому-то из отметившихся здесь D-шников дали C-шный код с решением, они бы с удовольствием сравнили бы на своем железе оба решения — C-шное и D-шное. В том числе и с разными опциями компиляции.

http://benchmarksgame.alioth.debian.org.

Вот сюда могут пройти все D-шники со своими желаниями померяться.

А уже для решения этой проблемы нужно либо GC, либо лайфтаймы как в Rust, либо использовать shared_ptr.

Либо использовать перемещение.

И в общем и целом что С, что С++, что D, что Rust, позволяют писать одинаково эффективный код.

Я бы, наверное, выстроил бы таким образом: C и Rust (как самые быстрые), затем уже C++ и D. При этом объем кода в программе уменьшался бы, наверное, в обратном порядке (следовательно, так бы уменьшалась и трудоемкость, и повышалась надежность (хотя с Rust-ом не так все однозначно)).

Вот сюда могут пройти все D-шники со своими желаниями померяться.

Вообще-то во времена D1 решения на D там были представлены для многих задач. Уж не знаю как сейчас с этим дело обстоит.

Тем не менее, если бы аноним со смайликами отвечал за свои слова, то было бы интересно увидеть, сколько кода на C ему пришлось бы написать, чтобы показать скорость более высокую, чем из примера из документации к стандартной библиотеке D.

В исходное сообщение, для начала. Потом на числа для q_foreach. Потом опять в исходное сообщение:

Не понимаю, что ты хочешь сказать.

Кто то тащит буст, кто то qt. Какая принципиальная разница между этими двумя людьми?

Бустовые variant/any - header only.

А также breaking changes поменьше.

Вот тут не уверен. Да и честно посчитать будет сложно, учитывая, что в бусте breaking changes на уровне отдельных либ, а в Qt в мажорных версиях много чего переделывают.

Есть предложение на включение в стандарт языка http://wiki.dlang.org/DIP50
Last Modified: 2013-11-10

Или это не значит, что идею забросили/отложили?

C и Rust (как самые быстрые)

Самые минималистичные, скорее. И далеко не всегда это плюс к скорости. К примеру, «встроенный» ООП лучше оптимизируется компилятором, чем реализованный вручную. Этому же способствуют и шаблоны, и CTFE, и продвинутая генерация кода как в D. Но в общем, повторюсь, эти языки схожи тем, что дают нужный контроль и достаточно низкий уровень для написания оптимального кода.

В свое время была вот такая новость: тыц. Если Samsung как-то материально поддерживал разработку Servo, то это нехило, вообще-то говоря.

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

Ну вот поверхностное гугление дало такой результат: http://www.fastcompany.com/3027664/under-the-hood-of-mozillas-new-multi-core-...

In total, six Mozilla engineers are working on Servo almost full-time, with other part-timers in the organization. Over a dozen engineers at Samsung do another chunk of the work, and the number of contributors is growing.

Может эти спецы из Samsung-а непосредственно в язык не контрибутят, но работа над главным проектом для Rust-а в Mozilla, движком Servo, это уже немало.

Как не зайду на ЛОР - ты тут как тут, так что свое время ты уже совершенно бесплатно тратишь.

Так то время на развлекуху, а то код :-)

И твоя фраза про «за бесплатно» не больше чем натужная попытка представить себя чуть важнее чем пустое место.

Нет, не угадал :-)

А советы сменить C++ и D на C кто дает?

Тот, кто знает, что классические методы работают отлично и нет надобности приделывать к телеге реактивный двигатель :-)

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

Это теория :-). И если ей следовать, то эти жалкие языки можно выкинуть на помойку, ибо в сравнении с Lisp они просто серо-бледные поганки, в т.ч. по критерию «количества усилий, необходимых разработчику для достижения поставленной цели». :-) А вот с т.з. практики, на сегодняшний день, C - это тот язык, который является языком для решения любых задач - начиная от написания таких вещей, как libevent и NGINX, заканчивая ОС и СУБД, заканчивая драйверами. И такого недоразумения, как цепепе вообще бы не было бы по определению, если бы не C, потому что всё в цепепе сводится к вызовам C :-)

Тот, кто знает, что классические методы работают отлично

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

Не говоря уже о том, чтобы делом подтвердить свои же советы.

Код покажите, улыбчивый дурачок вы наш.

Вот как раз перемещение там не поможет. Речь шла изначально о преимуществах immutable для расшаривания структуры между потоками без дополнительных усилий за счет гарантий, что ни 1 поток не сможет поменять её. Перемещение поможет только если данные нужны одному потоку, но в этом случае и иммутабельность не нужна.

Речь шла изначально о преимуществах immutable для расшаривания структуры между потоками без дополнительных усилий за счет гарантий, что ни 1 поток не сможет поменять её.

Дык, потом разговор перешёл на время жизни.

Лайфтаймы были упомянуты в том контексте, что с ними просто не получится написать код, в котором возможно обращение к уже уничтоженному объекту (если не извращаться), ошибка будет уже на этапе компиляции, а не в OOPS в рантайме.

не знаю. скорее, обсуждают, пока руки не дойдут.

Это, не к ночи помянута, 1С какая-то.

нет

что технический английский - это не rocket science, а средство передвижения, и этим ограничимся, ок?

Вы невнимательно прочитали комментарий. Есть известная психологическая фишка, что правильно выбранная знаковая система может сильно сократить время восприятия и снизить число ошибок. Вас же не удивляет, что в мат. записи $\sum_{y=-1}^1000 \sin(x)y$ воспринимается быстрее и нагляднее, чем та-же фраза, записанная словами?

Здесь аналогично, записывая ключевые/стандартные слова/фразы принятой латиницей, а содержательную часть отличающейся кириллицей (на родном языке --- это важно), сокращаем число ошибок. За счёт особенностей обработки текста мозгом (не машиной! :) )

станет. тут УЖЕ легче. причём, что принципиально, СИЛЬНО (шаблоны в D, фактически, ничем не отличаются от регулярного текста)

Можете привести пример шаблона в D, в котором нет static if-а, и при этом D-шный шаблон кардинально проще аналогичного C++ного?

Ну хорошо. берём общедоступный и легкопроверяемый пример:

https://github.com/D-Programming-Language/dub.git

исходников du -sh source 808K source

из них явных шаблонов grep -r «template» ./source | wc -l 61

на сборку В ОДИН ПОТОК на машине с iCore5 и 8Гб ОЗУ с РАМ диска (/tmp на tmpfs) ушло

time ./build.sh Generating version file... Running ldmd2... /opt/ldc2-0.16.1-linux-x86_64/bin/../import/std/range/package.d(925): Deprecation: function std.algorithm.iteration.splitter!(«a == b», string, string).splitter.Result.back is deprecated - splitter!(Range, Range) cannot be iterated backwards (due to separator overlap). /opt/ldc2-0.16.1-linux-x86_64/bin/../import/std/range/package.d(935): Deprecation: function std.algorithm.iteration.splitter!(«a == b», string, string).splitter.Result.popBack is deprecated - splitter!(Range, Range) cannot be iterated backwards (due to separator overlap). DUB has been built as bin/dub.

You may want to run sudo ln -s /dev/shm/D/bin/dub /usr/local/bin now. 7.13user 0.32system 0:07.45elapsed 99%CPU (0avgtext+0avgdata 1383340maxresident)k 0inputs+0outputs (0major+370078minor)pagefaults 0swaps

7.13 секунды, это при том, что скрипт сборки обращается к гиту на предмет файла версии и т.п.

Собственно, выполнение ldmd2 заняло 6.53 сек. В ОДИН ПОТОК. на LLVM/ldc2.

Та же самая сборка

dmd --version DMD64 D Compiler v2.069.1 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

заняла

3.28user 0.27system 0:03.56elapsed 99%CPU (0avgtext+0avgdata 957172maxresident)k 16inputs+0outputs (1major+267531minor)pagefaults 0swaps

Из них чистая сборка (время только dmd) заняло 2.15 сек. В ОДИН ПОТОК.

808K исходников о 61 явном шаблоне (плюс вызовы станартной библиотеки, конечно) (признак инстанцирования шаблона ("!") встречается grep -r -e"\!" ./source | wc -l

2053 раза )

Предлагаю выдыхать.

слёту нет, надо придумать или поискать общеизвестный код. думаю, подойдёт абсолютно любой пример :)

Т.е. пруфов нет. Т.е. понятно, что C++ вам в принципе не нравится. Поэтому и шаблоны D выглядят привлекательно, хотя по сути там лишь форма записи другая.

PS. Если под «общеизвестным кодом» понимается что-нибудь из Boost-а или STL, то это не есть адекватные примеры. Т.к. там очень специализированный код, да еще и обремененный поддержкой старых компиляторов.

Т.е. пруфов нет.

я на работе :)

на досуге подумаю — будут.

Если под «общеизвестным кодом» понимается что-нибудь из Boost-а или STL, то это не есть адекватные примеры.

это почему же? как раз пример высокопрофессионального подхода.

да еще и обремененный поддержкой старых компиляторов.

лишнее можно о проигнорировать

Т.е. понятно, что C++ вам в принципе не нравится.

Не так. Нравится. Особенно, целевые библиотеки (типа Eigen3, например. Это же чудо!).

Не нравится, что время разработки существенно больше, чем на более продуманных (специально не говорю --- высокоуровневых) альтернативах, типа D, C#. ПРичём от кривизны рук / попавидности головы. это не зависит.

я на работе

Упс... Т.е. на работе вы D не используете?

это почему же? как раз пример высокопрофессионального подхода.

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

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

Тут есть два важных слова: сборка мусора. Разработка для многих прикладных областей на языках с GC много проще и быстрее, чем на C++.

Что вовсе не означает, что шаблоны C++ — это «ужас-ужас», а шаблоны D на порядок лучше оных в C++.

Упс... Т.е. на работе вы D не используете?

скажем так, экспериментирую

Тут есть два важных слова: сборка мусора.

да, конечно. но не только.

чисто синтаксический аспект + особенности языка дают очень приличный негативный (по времени разработки) эффект.

особенности языка

Какие именно? Если не писать на C-шном подмножестве C++, то с чем сложности?