forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

В состав GCC одобрено включение языка программирования D, opennews (??), 21-Июн-17, (0) [смотреть все]

опционально отключаемый же, Аноним (-), 21:10 , 21-Июн-17, (1) +7 //

попробуй отключить его для стандартных либ, Аноним (-), 02:12 , 22-Июн-17, (8) +2 //

Давно не следил, но стандартную либу в этом плане правили мроблема с том, что G, Crazy Alex (ok), 10:47 , 22-Июн-17, (26) +2 //

Но зачем, если есть языки с бесплатными слайсами массивов без GC , 11111 (?), 12:32 , 22-Июн-17, (67)

Нет их И быть не может, во всяком случае, в общем виде Либо слайс будет не бес, Crazy Alex (ok), 13:23 , 22-Июн-17, (69)

Есть rust , Алконим (?), 13:59 , 22-Июн-17, (74)

Не оно ни разу Растовская borrow semantics сильно ограничивает использование сл, Crazy Alex (ok), 15:02 , 22-Июн-17, (76) –1

А нахрена его отключать, пиши сразу на сишке D и хорош тем, что это по сути ко, menangen (?), 10:20 , 28-Июн-17, (116) –2 //

Саммоним в тред Главного Эксперта Опенета по Джавве, iZEN-а iZEN, вы-хо-ди , Andrey Mitrofanov (?), 10:54 , 28-Июн-17, (117)

Этот ваш D умеет инклюдить сишные хидеры и использовать оттуда функции и структу, Alex (??), 23:57 , 21-Июн-17, (4) –3 //

Вроде бы умеет, но только сишные без С шаблонов , nc (ok), 00:02 , 22-Июн-17, (5) //

Может использовать сишные и плюснутые библиотеки, как раз переписав хидеры , marco (??), 03:33 , 22-Июн-17, (12) +1 //

Немного устаревшая информация насчёт увесистых Они получались увесистые не пото, Crazy Alex (ok), 12:44 , 22-Июн-17, (68) +1

Мне очень нравится D, но размер исполняемых файлов явно его слабая сторона Shar, Mihail Zenkov (ok), 15:40 , 22-Июн-17, (80) –3

На 32-битной платформе libphobos so занимает 6 мегабайт Учитывая, что это всё ж, Crazy Alex (ok), 16:51 , 22-Июн-17, (83) +2

Минимальный пример D code import std stdio writeln import core sys posix unis, Mihail Zenkov (ok), 20:08 , 22-Июн-17, (87)

Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины тащить пол , Аноним (-), 22:34 , 22-Июн-17, (91) +1

Зачем ориентироваться на худшее, а не на лучшее KolibriOS в 1 5 MB вкладывается, Mihail Zenkov (ok), 11:24 , 23-Июн-17, (95) –2

Потому что важны затраты усилий и риски возникновения ошибок, в том числе в ходе, Crazy Alex (ok), 12:51 , 24-Июн-17, (100)

Не факт Производители по-прежнему хотят минимальной себестоимости К примеру на, Mihail Zenkov (ok), 13:21 , 24-Июн-17, (103)

На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновлен, Crazy Alex (ok), 15:13 , 26-Июн-17, (108) +1
Как я уже сказал - с этим согласен и для десктопных приложений использую D именн, Mihail Zenkov (ok), 17:02 , 26-Июн-17, (110) –1
Сегодня похоже добили баг с ожирением из-за TypeInfo https forum dlang org po, Mihail Zenkov (ok), 20:37 , 26-Июн-17, (111) –1

Дело не в сборщике мусора, там тянется много несколько неожиданных вещей, типа р, glebiao (ok), 13:24 , 24-Июн-17, (104) +1

Нет, так как сишные макросы не умеет и правильно , да и система типов не совпад, Crazy Alex (ok), 00:31 , 22-Июн-17, (6) +7 //

Сделать нормальный модуль с вменяемым API - для чего POSIX API Или kernel-to, Alex (??), 02:40 , 22-Июн-17, (9) +1 //

транслированные хидеры libc и так в комплекте Но как раз сокет - хороший пример, Crazy Alex (ok), 10:42 , 22-Июн-17, (25)

Есть утилиты-трансляторы заголовочных файлов в дишные модули Так дофига биндинг, Zloy (?), 11:42 , 22-Июн-17, (60) +1 //

Лучше всё же написать, что примерно каждый первый надо руками дочищать, так как , Crazy Alex (ok), 12:31 , 22-Июн-17, (66) +1

Хорошая новость , gustav (?), 00:44 , 22-Июн-17, (7) –6
для полного фарша в GCC ещё Limbo добавить и будет совсем конанично и да, ржавы, Спайк (?), 03:19 , 22-Июн-17, (11) –6 //

Ждём gcc-rust -D, anonymous (??), 04:54 , 22-Июн-17, (13) +2 //

Уже есть https www opennet ru opennews art shtml num 38576, Аноним (-), 07:45 , 22-Июн-17, (14) –7 //

вот этот коммит мне нравится - - https gcc gnu org git p gcc git a patch h, X4asd (ok), 11:34 , 22-Июн-17, (58) +5
Ну вот примерно так и GDC в 2011-м был - , Crazy Alex (ok), 12:28 , 22-Июн-17, (65)

гццуст, Zloy (?), 11:43 , 22-Июн-17, (61) –1 //

GC-crust же джи си краст CODE jargon GC G C from LISP te, Andrey Mitrofanov (?), 13:37 , 22-Июн-17, (71) +1

- Сильно , Вареник (?), 07:56 , 24-Июн-17, (97) –1

Многие вещи в Go взяты из Limbo А Go сейчас - последний язык в этой цепочке Ne, nc (ok), 07:45 , 22-Июн-17, (15) –3

Кому интерфейсы с С нужны могут взять https github com Syniurge Calypso он , Аноним (-), 08:39 , 22-Июн-17, (16) –4 //

Класс Вот этом может взлететь , Вареник (?), 08:00 , 24-Июн-17, (98)

GNU-бюрократия затормозила прогресс на шесть лет, Нанобот (ok), 08:50 , 22-Июн-17, (17) –7 //

gcj выкинули наконец патчи free pascal только для gcc 4 3 Камрады _борются_ , Andrey Mitrofanov (?), 09:20 , 22-Июн-17, (18) –8
Там основной была синхронизация разработки с DMD GDC LDC долго сильно отставали, Crazy Alex (ok), 12:27 , 22-Июн-17, (64) +1 //

а сейчас GDC LDC по поддержке фич и качеству генерируемого кода на сравнимом, J.L. (?), 15:18 , 22-Июн-17, (77) //

Для ознакомления на простеньком проекте - вообще всё равно какой из них брать, о, Crazy Alex (ok), 16:55 , 22-Июн-17, (84) +4
Если нужны все самые свежие фичи сиюминутно закомиченные в мастер ветку 8212 , Аноним (-), 22:38 , 22-Июн-17, (92) +2
dmd генерит не самый оптимальный код ldc значительно лучше но до последнего врем, glebiao (ok), 13:17 , 24-Июн-17, (101)

Добавьте, что по самому качеству кода компилятора dmd первый - в нём, как правил, Crazy Alex (ok), 15:16 , 26-Июн-17, (109)

Поскольку FSF не любит C , то, может, полюбит D Идея для Gtk шников - переписа, Аноним (-), 10:40 , 22-Июн-17, (24) –5 //

Идея отличная Но на дишечке итак делается dlangui, проще тогда уже его доводить, Zloy (?), 11:45 , 22-Июн-17, (62) –3 //

dlangui делается одним человеком, это любительский проект Gtk же штука покрупнее, Pinkie (?), 15:31 , 22-Июн-17, (79) –1 //

Я бы сказал, что Gtk - штука сильно покрупнее, чем вообще надо для GUI А что пиш, Crazy Alex (ok), 15:42 , 22-Июн-17, (82)

У dlin_hui название лучше , Аноним (-), 19:04 , 22-Июн-17, (85) –2

Гномеры уже активно на Rust переползают, так что вряд ли , Александрик (?), 12:00 , 22-Июн-17, (63) –2 //

откуда инфа , Аноним (-), 03:07 , 24-Июн-17, (96) //

http lmgtfy com q gnome rust, Аноним (-), 21:33 , 12-Июл-17, (118) –1

Тут не только и не столько в расстановке кроватей проблема , Аноним (-), 13:59 , 22-Июн-17, (73) –1

Как-то натыкался на такой проект D программы быстро собираются поэтому вполне , анонимбр (?), 14:06 , 22-Июн-17, (75) +2 //

Скрипты с типизацией и с ООП Да ну к черту вас , Аноним (-), 15:19 , 22-Июн-17, (78) +2 //

Ты с джавой перепутал ООП здесь не страшнее, чем в том же питоне Можно и в чис, Crazy Alex (ok), 15:40 , 22-Июн-17, (81) +1 //

В скрипте не нужно ооп, типизация и python Либо вы не совсем понимаете значение, Аноним (-), 19:12 , 22-Июн-17, (86) –2

В скрипте на пять строк - не нужно хотя не мешают В чём нибудь вроде скрипта , Crazy Alex (ok), 02:48 , 23-Июн-17, (93) +2

на D есть такой замечательный проект, поддержка программирования в скрипотовом с, glebiao (ok), 13:20 , 24-Июн-17, (102) //

Python - это сильно не первый сорт , поэтому очень зря ориентиро на него , Аноним (-), 21:15 , 24-Июн-17, (105)

И что первый PowerShell , glebiao (ok), 22:11 , 24-Июн-17, (106) –1
Если Python не первый сорт для клея, то я даже не знаю что тогда , Аноним (-), 22:22 , 26-Июн-17, (112) –1

Разве что нюхательного , Led (ok), 22:39 , 26-Июн-17, (113)

Скрипты можно и на Си писать, если уж так хочется - tcc , dq0s4y71 (ok), 20:25 , 22-Июн-17, (88) +1 //

Можно Но жутко неудобно и полно страданий, Pinkie (?), 21:54 , 22-Июн-17, (90) –1 //

Попробуйте Pike Это как раз для писать скрипты на Си , . (?), 03:31 , 23-Июн-17, (94) –2

Ты его используешь Поделись впечатлениями , funny.falcon (?), 08:23 , 24-Июн-17, (99)

Опоздали Есть Nim и использует GCC как надстройка по умолчанию не дожидаясь вклю, DV60 (?), 20:55 , 22-Июн-17, (89) –3
А как решается вопрос о совмещении 1005000 компиляторов в одном Я не техническу, Вячеслав (??), 22:13 , 25-Июн-17, (107) –1 //

Назови хотябы 35 широкоиспользуемых компилируемых языков, Твой классный руководитель (?), 00:33 , 27-Июн-17, (114) +1 //

Это сделать не получится - потому что, наверное, большая часть их ещё не создана, Вячеслав (??), 08:42 , 27-Июн-17, (115) –2

Сообщения [Сортировка по времени | RSS]

12. "В состав GCC одобрено включение языка программирования D" +1 +/–

Сообщение от marco (??), 22-Июн-17, 03:33

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

Ответить | Правка | Наверх | Cообщить модератору

68. "В состав GCC одобрено включение языка программирования D" +1 +/–

Сообщение от Crazy Alex (ok), 22-Июн-17, 12:44

Немного устаревшая информация насчёт увесистых. Они получались увесистые не потому, что тянут сборщик мусора, а потому что shared libraries не использовали. Как минимум для линукса было пофикшено пару лет назад: https://stackoverflow.com/questions/31366010/why-d-program-e...

Ответить | Правка | Наверх | Cообщить модератору

80. "В состав GCC одобрено включение языка программирования D" –3 +/–

Сообщение от Mihail Zenkov (ok), 22-Июн-17, 15:40

Мне очень нравится D, но размер исполняемых файлов явно его слабая сторона. Shared libraries не спасает: размер поставки (bin+phobos.so) будет еще больше, чем для статики. Потребление памяти для простых приложений в любом случае очень сильно завышено (в сравнении с C).
ИМХО основная проблема, что по-прежнему линкер не может выкинуть основную массу мертвого кода. Где-то было обсуждение этой проблемы, но сходу ссылку не найду.
Есть еще страница (http://digger.k3.1azy.net/trend/), на которой отслеживалась тенденция размера исполнимых файлов в зависимости от версии, но что-то у меня она ошибку выдавать стала.

Ответить | Правка | Наверх | Cообщить модератору

83. "В состав GCC одобрено включение языка программирования D" +2 +/–

Сообщение от Crazy Alex (ok), 22-Июн-17, 16:51

На 32-битной платформе libphobos.so занимает 6 мегабайт. Учитывая, что это всё же общий рантайм, я никакой проблемы не вижу ни для чего кроме каких-нибудь сборок OpenWRT.
Насчёт потребления памяти - в первой паре тестов, которые мне попались, всё вполне прилично: https://github.com/kostya/benchmarks и https://togototo.wordpress.com/2013/08/23/benchmarks-round-t.../
Надо бы ещё поискать, но как-нибудь потом.

Ответить | Правка | Наверх | Cообщить модератору

87. "В состав GCC одобрено включение языка программирования D" +/–

Сообщение от Mihail Zenkov (ok), 22-Июн-17, 20:08

Минимальный пример:
D:
import std.stdio : writeln;
import core.sys.posix.unistd : usleep;
void main() {
    writeln("test");
    usleep(10000000);
}

C:
#include <stdio.h>
#include <unistd.h>
void main() {
    printf("test");
    usleep(10000000);
}
Размер бинарника (после strip): C - 5.4K, D - 312.6K.
Потребление памяти:
Private  +   Shared  =  RAM used       Program
412.0 KiB + 147.5 KiB = 559.5 KiB       test_d
68.0 KiB  +  68.0 KiB = 136.0 KiB       test_c
Для больших программ разница будет несущественна. А вот когда пишешь небольшие системные утилиты - как-то жирновато.

Ответить | Правка | Наверх | Cообщить модератору

91. "В состав GCC одобрено включение языка программирования D" +1 +/–

Сообщение от Аноним (-), 22-Июн-17, 22:34

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

Ответить | Правка | Наверх | Cообщить модератору

95. "В состав GCC одобрено включение языка программирования D" –2 +/–

Сообщение от Mihail Zenkov (ok), 23-Июн-17, 11:24

> Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины
> тащить пол гига жвм, но чтобы из-за 300 кб у кого-то
> проблемы возникали...
Зачем ориентироваться на худшее, а не на лучшее? KolibriOS в 1.5 MB вкладывается. Rockbox (почти полностью на C) - 500-600 KB. Я не понимаю почему простой вывод строки на экран должен весить столько же. На uC я могу написать драйвер LCD и вывод на него на C и это будет меньше 1 KB.
ИМХО при таком раскладе системное программирование (а также IoT и прочий embedded) так и останется на C.
> Кстати, попробуйте с -betterC компилировать, для любителей микробинарей как раз делался.
Да, но это уже будет не D, а именно better C.

Ответить | Правка | Наверх | Cообщить модератору

100. "В состав GCC одобрено включение языка программирования D" +/–

Сообщение от Crazy Alex (ok), 24-Июн-17, 12:51

Потому что важны затраты усилий и риски возникновения ошибок, в том числе в ходе поддержки. Для эмбеда - это одно соотношение ввиду слабости применяемого железа (кстати, судя по всему это скоро свой эффект потеряет). Для "большого" программирования - совсем другое, там пара сотен килобайт - совершенно копеечная цена за удобство.
Кроме того, ваше сравнение вообще некорректно - я не думаю, что на C вы напишете драйвер для LCD в 1кб, используя стандартную библиотеку, тем более - десктопную. Максимум - что-то вроде musl.
P.S. Не знаю, чем вы там собирали, но при сборке вашего примерчика для 32-х бит dmd 2.0.74.0 я получил бинарник в 18376 байт, по top virt/res/shr= 9432/3706/3620. Динамическая линковка, разумеется.
Сишный пример вышел 6932 байта,  2156/512/460. Разница, конечно, есть, но отнюдь не такая катастрофичная, как в вашем примере. И тоже динамика, статика весит 720168 байт.

Ответить | Правка | Наверх | Cообщить модератору

103. "В состав GCC одобрено включение языка программирования D" +/–

Сообщение от Mihail Zenkov (ok), 24-Июн-17, 13:21

> Для эмбеда - это одно соотношение ввиду слабости применяемого железа (кстати, судя по всему это скоро свой эффект потеряет).
Не факт. Производители по-прежнему хотят минимальной себестоимости. К примеру на новых плеерах Sansa памяти на порядок меньше, чем на старых, тоже с новыми китайскими SoC (RKnano*). На роутерах/модемах/etc тоже незаметно бурного роста свободных ресурсов. Опять же - рост производительности пагубно сказывается на времени автономной работы (при одном и том же технологическом процессе).
Только на смартфонах идет бурный рост, так как гигабайты и ядра вполне неплохо можно впаривать обывателям.
> Для "большого" программирования - совсем другое, там пара сотен килобайт - совершенно копеечная цена за удобство.
Согласен, поэтому все равно свои проекты пишу на D.
Sucless сообщество тоже когда-то рассматривало D - удобнее C и нет переусложненности C++, но по-прежнему они пишут проекты на C: st - 59K, dwm - 38.7K.
> P.S. Не знаю, чем вы там собирали, но при сборке вашего примерчика
> для 32-х бит dmd 2.0.74.0 я получил бинарник в 18376 байт,
> по top virt/res/shr= 9432/3706/3620. Динамическая линковка, разумеется.
dmd-2.072, 32 бита, статика. О размере динамики нет смысла говорить без учета libphobos.so, так как полученный бинарник без нее не работоспособен.

> Сишный пример вышел 6932 байта,  2156/512/460. Разница, конечно, есть, но отнюдь
> не такая катастрофичная, как в вашем примере. И тоже динамика, статика
> весит 720168 байт.
А для gdc все будет еще печальнее.
ИМХО на самом деле проблема может оказаться гораздо серьезнее: сейчас нет крупных библиотек для D, кроме phobos. Но что будет потом, когда они появятся? Не будет ли этой же проблемы, но в другом масштабе?

Ответить | Правка | Наверх | Cообщить модератору

108. "В состав GCC одобрено включение языка программирования D" +1 +/–

Сообщение от Crazy Alex (ok), 26-Июн-17, 15:13

На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновление проблематично, можно себе позволить потратить больше на разработку и оптимизацию, отбив удешевлением устройства. На десктопе/сервере выгоднее потратить ресурсы железа, но выгадать в скорости/качестве/стоимости разработки (тут уж кому что важнее). Вот об этом соотношении речь.
Ну вот сишная статика у меня вышла 700 кб, стрип не забывал, так что какие-то странные разногласия у нас.
Для gdc - да, будет печальнее, он вообще слегка отстаёт от остальных двух. Я так понимаю - в последнее время стало лучше.
Но всё же я не понимаю этой боязни шаред либ - это ж амортизированные расходы получаются,  если мы считаем, что D таки будет применяться - выходит совсем мелочь, учитывая, что 6 мегабайт сейчас и так совершенно незаметны на десктопе.
Насчёт дубущих библиотек - полагаю, особо резкого роста размера не будет. Здесь скорее есть какой-то минимум, а дальше нарастание идёт довольно плавно. Хотя может кто-то совсем с шаблонами заиграется, конечно... Но такие проблемы логично решать по мере поступления, причём чаще - в плане архитектуры самой библиотеки.

Ответить | Правка | Наверх | Cообщить модератору

110. "В состав GCC одобрено включение языка программирования D" –1 +/–

Сообщение от Mihail Zenkov (ok), 26-Июн-17, 17:02

> На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновление проблематично,
> можно себе позволить потратить больше на разработку и оптимизацию, отбив удешевлением
> устройства. На десктопе/сервере выгоднее потратить ресурсы железа, но выгадать в скорости/качестве/стоимости
> разработки (тут уж кому что важнее). Вот об этом соотношении речь.
Как я уже сказал - с этим согласен и для десктопных приложений использую D именно поэтому.
> Ну вот сишная статика у меня вышла 700 кб, стрип не забывал,
> так что какие-то странные разногласия у нас.
Это косяк glibc. Но ее как раз выгоднее использовать как shared, так как она используется практически всеми приложениями. Phobos наоборот - будет использовать одно-два приложения, так что выигрыша от shared не будет, скорее наоборот.
Если взять musl (http://www.etalabs.net/compare_libcs.html) то статика будет около 13K. Для D к сожалению пока ничего подобного нет.
> Но всё же я не понимаю этой боязни шаред либ - это
> ж амортизированные расходы получаются,  если мы считаем, что D таки
> будет применяться - выходит совсем мелочь, учитывая, что 6 мегабайт сейчас
> и так совершенно незаметны на десктопе.
Да, просто не люблю необоснованных затрат.
> Насчёт дубущих библиотек - полагаю, особо резкого роста размера не будет. Здесь
> скорее есть какой-то минимум, а дальше нарастание идёт довольно плавно. Хотя
> может кто-то совсем с шаблонами заиграется, конечно... Но такие проблемы логично
> решать по мере поступления, причём чаще - в плане архитектуры самой
> библиотеки.
ИМХО dead code elimination должен работать максимально эффективно на уровне компилятора/linker'а, не требуя тучи #ifdef (или его эквивалентов).

Ответить | Правка | Наверх | Cообщить модератору

111. "В состав GCC одобрено включение языка программирования D" –1 +/–

Сообщение от Mihail Zenkov (ok), 26-Июн-17, 20:37

> Для gdc - да, будет печальнее
Сегодня похоже добили баг с ожирением из-за TypeInfo (https://forum.dlang.org/post/qswoxnddbowkzpqqhcow@forum...). Возможно теперь разрыв между gdc и dmd сократится.
H. S. Teoh говорит, что жирность phobos связана с чрезмерной зависимостью модулей друг от друга (https://forum.dlang.org/post/mailman.2794.1496351236.31550.d...), но я по-прежнему не понимаю: почему компилятор не может сам определить мертвый код?

Ответить | Правка | Наверх | Cообщить модератору

104. "В состав GCC одобрено включение языка программирования D" +1 +/–

Сообщение от glebiao (ok), 24-Июн-17, 13:24

> быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как
> тянут сборщик мусора.
Дело не в сборщике мусора, там тянется много несколько неожиданных вещей,
типа рантаймовой поддержки интроспекции и т.п. имхо, с этим можно мириться: скорость И простота разработки + скорость исполнения, перевешивают недостаток толстоватых бинарников.
При динамической линковке, размер бинарника вовсе не получается катастрофическим.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	12. "В состав GCC одобрено включение языка программирования D"	+1 +/–
	Сообщение от marco (??), 22-Июн-17, 03:33
	Может использовать сишные и плюснутые библиотеки, как раз переписав хидеры. Для гиков можно использовать в коде ассемблерные вставки. Программы компилируются очень быстро, да и по быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как тянут сборщик мусора.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "В состав GCC одобрено включение языка программирования D"	+1 +/–
	Сообщение от Crazy Alex (ok), 22-Июн-17, 12:44
	Немного устаревшая информация насчёт увесистых. Они получались увесистые не потому, что тянут сборщик мусора, а потому что shared libraries не использовали. Как минимум для линукса было пофикшено пару лет назад: https://stackoverflow.com/questions/31366010/why-d-program-e...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "В состав GCC одобрено включение языка программирования D"	–3 +/–
	Сообщение от Mihail Zenkov (ok), 22-Июн-17, 15:40
	Мне очень нравится D, но размер исполняемых файлов явно его слабая сторона. Shared libraries не спасает: размер поставки (bin+phobos.so) будет еще больше, чем для статики. Потребление памяти для простых приложений в любом случае очень сильно завышено (в сравнении с C). ИМХО основная проблема, что по-прежнему линкер не может выкинуть основную массу мертвого кода. Где-то было обсуждение этой проблемы, но сходу ссылку не найду. Есть еще страница (http://digger.k3.1azy.net/trend/), на которой отслеживалась тенденция размера исполнимых файлов в зависимости от версии, но что-то у меня она ошибку выдавать стала.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "В состав GCC одобрено включение языка программирования D"	+2 +/–
	Сообщение от Crazy Alex (ok), 22-Июн-17, 16:51
	На 32-битной платформе libphobos.so занимает 6 мегабайт. Учитывая, что это всё же общий рантайм, я никакой проблемы не вижу ни для чего кроме каких-нибудь сборок OpenWRT. Насчёт потребления памяти - в первой паре тестов, которые мне попались, всё вполне прилично: https://github.com/kostya/benchmarks и https://togototo.wordpress.com/2013/08/23/benchmarks-round-t.../ Надо бы ещё поискать, но как-нибудь потом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "В состав GCC одобрено включение языка программирования D"	+/–
	Сообщение от Mihail Zenkov (ok), 22-Июн-17, 20:08
	Минимальный пример: D: import std.stdio : writeln; import core.sys.posix.unistd : usleep; void main() { writeln("test"); usleep(10000000); } C: #include <stdio.h> #include <unistd.h> void main() { printf("test"); usleep(10000000); } Размер бинарника (после strip): C - 5.4K, D - 312.6K. Потребление памяти: Private + Shared = RAM used Program 412.0 KiB + 147.5 KiB = 559.5 KiB test_d 68.0 KiB + 68.0 KiB = 136.0 KiB test_c Для больших программ разница будет несущественна. А вот когда пишешь небольшие системные утилиты - как-то жирновато.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "В состав GCC одобрено включение языка программирования D"	+1 +/–
	Сообщение от Аноним (-), 22-Июн-17, 22:34
	Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины тащить пол гига жвм, но чтобы из-за 300 кб у кого-то проблемы возникали... Кстати, попробуйте с -betterC компилировать, для любителей микробинарей как раз делался.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "В состав GCC одобрено включение языка программирования D"	–2 +/–
	Сообщение от Mihail Zenkov (ok), 23-Июн-17, 11:24
	> Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины > тащить пол гига жвм, но чтобы из-за 300 кб у кого-то > проблемы возникали... Зачем ориентироваться на худшее, а не на лучшее? KolibriOS в 1.5 MB вкладывается. Rockbox (почти полностью на C) - 500-600 KB. Я не понимаю почему простой вывод строки на экран должен весить столько же. На uC я могу написать драйвер LCD и вывод на него на C и это будет меньше 1 KB. ИМХО при таком раскладе системное программирование (а также IoT и прочий embedded) так и останется на C. > Кстати, попробуйте с -betterC компилировать, для любителей микробинарей как раз делался. Да, но это уже будет не D, а именно better C.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	100. "В состав GCC одобрено включение языка программирования D"	+/–
	Сообщение от Crazy Alex (ok), 24-Июн-17, 12:51
	Потому что важны затраты усилий и риски возникновения ошибок, в том числе в ходе поддержки. Для эмбеда - это одно соотношение ввиду слабости применяемого железа (кстати, судя по всему это скоро свой эффект потеряет). Для "большого" программирования - совсем другое, там пара сотен килобайт - совершенно копеечная цена за удобство. Кроме того, ваше сравнение вообще некорректно - я не думаю, что на C вы напишете драйвер для LCD в 1кб, используя стандартную библиотеку, тем более - десктопную. Максимум - что-то вроде musl. P.S. Не знаю, чем вы там собирали, но при сборке вашего примерчика для 32-х бит dmd 2.0.74.0 я получил бинарник в 18376 байт, по top virt/res/shr= 9432/3706/3620. Динамическая линковка, разумеется. Сишный пример вышел 6932 байта, 2156/512/460. Разница, конечно, есть, но отнюдь не такая катастрофичная, как в вашем примере. И тоже динамика, статика весит 720168 байт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "В состав GCC одобрено включение языка программирования D"	+/–
	Сообщение от Mihail Zenkov (ok), 24-Июн-17, 13:21
	> Для эмбеда - это одно соотношение ввиду слабости применяемого железа (кстати, судя по всему это скоро свой эффект потеряет). Не факт. Производители по-прежнему хотят минимальной себестоимости. К примеру на новых плеерах Sansa памяти на порядок меньше, чем на старых, тоже с новыми китайскими SoC (RKnano*). На роутерах/модемах/etc тоже незаметно бурного роста свободных ресурсов. Опять же - рост производительности пагубно сказывается на времени автономной работы (при одном и том же технологическом процессе). Только на смартфонах идет бурный рост, так как гигабайты и ядра вполне неплохо можно впаривать обывателям. > Для "большого" программирования - совсем другое, там пара сотен килобайт - совершенно копеечная цена за удобство. Согласен, поэтому все равно свои проекты пишу на D. Sucless сообщество тоже когда-то рассматривало D - удобнее C и нет переусложненности C++, но по-прежнему они пишут проекты на C: st - 59K, dwm - 38.7K. > P.S. Не знаю, чем вы там собирали, но при сборке вашего примерчика > для 32-х бит dmd 2.0.74.0 я получил бинарник в 18376 байт, > по top virt/res/shr= 9432/3706/3620. Динамическая линковка, разумеется. dmd-2.072, 32 бита, статика. О размере динамики нет смысла говорить без учета libphobos.so, так как полученный бинарник без нее не работоспособен. > Сишный пример вышел 6932 байта, 2156/512/460. Разница, конечно, есть, но отнюдь > не такая катастрофичная, как в вашем примере. И тоже динамика, статика > весит 720168 байт. А для gdc все будет еще печальнее. ИМХО на самом деле проблема может оказаться гораздо серьезнее: сейчас нет крупных библиотек для D, кроме phobos. Но что будет потом, когда они появятся? Не будет ли этой же проблемы, но в другом масштабе?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	108. "В состав GCC одобрено включение языка программирования D"	+1 +/–
	Сообщение от Crazy Alex (ok), 26-Июн-17, 15:13
	На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновление проблематично, можно себе позволить потратить больше на разработку и оптимизацию, отбив удешевлением устройства. На десктопе/сервере выгоднее потратить ресурсы железа, но выгадать в скорости/качестве/стоимости разработки (тут уж кому что важнее). Вот об этом соотношении речь. Ну вот сишная статика у меня вышла 700 кб, стрип не забывал, так что какие-то странные разногласия у нас. Для gdc - да, будет печальнее, он вообще слегка отстаёт от остальных двух. Я так понимаю - в последнее время стало лучше. Но всё же я не понимаю этой боязни шаред либ - это ж амортизированные расходы получаются, если мы считаем, что D таки будет применяться - выходит совсем мелочь, учитывая, что 6 мегабайт сейчас и так совершенно незаметны на десктопе. Насчёт дубущих библиотек - полагаю, особо резкого роста размера не будет. Здесь скорее есть какой-то минимум, а дальше нарастание идёт довольно плавно. Хотя может кто-то совсем с шаблонами заиграется, конечно... Но такие проблемы логично решать по мере поступления, причём чаще - в плане архитектуры самой библиотеки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	110. "В состав GCC одобрено включение языка программирования D"	–1 +/–
	Сообщение от Mihail Zenkov (ok), 26-Июн-17, 17:02
	> На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновление проблематично, > можно себе позволить потратить больше на разработку и оптимизацию, отбив удешевлением > устройства. На десктопе/сервере выгоднее потратить ресурсы железа, но выгадать в скорости/качестве/стоимости > разработки (тут уж кому что важнее). Вот об этом соотношении речь. Как я уже сказал - с этим согласен и для десктопных приложений использую D именно поэтому. > Ну вот сишная статика у меня вышла 700 кб, стрип не забывал, > так что какие-то странные разногласия у нас. Это косяк glibc. Но ее как раз выгоднее использовать как shared, так как она используется практически всеми приложениями. Phobos наоборот - будет использовать одно-два приложения, так что выигрыша от shared не будет, скорее наоборот. Если взять musl (http://www.etalabs.net/compare_libcs.html) то статика будет около 13K. Для D к сожалению пока ничего подобного нет. > Но всё же я не понимаю этой боязни шаред либ - это > ж амортизированные расходы получаются, если мы считаем, что D таки > будет применяться - выходит совсем мелочь, учитывая, что 6 мегабайт сейчас > и так совершенно незаметны на десктопе. Да, просто не люблю необоснованных затрат. > Насчёт дубущих библиотек - полагаю, особо резкого роста размера не будет. Здесь > скорее есть какой-то минимум, а дальше нарастание идёт довольно плавно. Хотя > может кто-то совсем с шаблонами заиграется, конечно... Но такие проблемы логично > решать по мере поступления, причём чаще - в плане архитектуры самой > библиотеки. ИМХО dead code elimination должен работать максимально эффективно на уровне компилятора/linker'а, не требуя тучи #ifdef (или его эквивалентов).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. "В состав GCC одобрено включение языка программирования D"	–1 +/–
	Сообщение от Mihail Zenkov (ok), 26-Июн-17, 20:37
	> Для gdc - да, будет печальнее Сегодня похоже добили баг с ожирением из-за TypeInfo (https://forum.dlang.org/post/qswoxnddbowkzpqqhcow@forum...). Возможно теперь разрыв между gdc и dmd сократится. H. S. Teoh говорит, что жирность phobos связана с чрезмерной зависимостью модулей друг от друга (https://forum.dlang.org/post/mailman.2794.1496351236.31550.d...), но я по-прежнему не понимаю: почему компилятор не может сам определить мертвый код?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "В состав GCC одобрено включение языка программирования D"	+1 +/–
	Сообщение от glebiao (ok), 24-Июн-17, 13:24
	> быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как > тянут сборщик мусора. Дело не в сборщике мусора, там тянется много несколько неожиданных вещей, типа рантаймовой поддержки интроспекции и т.п. имхо, с этим можно мириться: скорость И простота разработки + скорость исполнения, перевешивают недостаток толстоватых бинарников. При динамической линковке, размер бинарника вовсе не получается катастрофическим.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору