Спасибо за исследование.
Только как-то очень хаотично написан раздел про llvm. Что получилось собрать, а что нет? В графики попала wasm версия полученная через asm.js, а упрощённый тест был просто для проверки, что 64 бита возможны? Тогда можно ожидать, что когда всё заработает wasm версия будет в несколько раз быстрее?
А я вот чего не могу понять: все комментарии негативные, комментаторы не согласны со статьёй. Тогда какого… у неё 24 плюса?
Статья — непоследовательное попоулистское повествование с графиками чтобы выглядеть научным. Не рассмотрены никакие другие факторы, не оценены степени их влияния, а по стилю изложения и аргументации не уступает хрен-тв с инопланетянами.
Это твиттер? Тема важная и интересная, но пост из ссылки и приглашения на конференцию — совсем не формат хабра. Было бы очень здорово почитать подробнее. Хотя бы ввели в тему тех, кто хочет покопаться в исходниках и помочь.
GitHub — новомодное явление для новомодных языков. Под новым я понимаю лет 10. C, C++, asm x86, COBOL, FORTRAN и многие другие там представлены очень слабо. Просто потому, что программисты на этих языках часто не пользуются гитхабом. Да и Full Stack Overflow Developer'ов на этих языках нет — не взлетит. Но это не значит, что на этих языках не пишут. Большинство таких языков постепенно вымирает, в том числе из-за того, что не вписались в современный мир, но вымирать они могут ещё десятилетиями и будут востребованы очень долго.
Мне рейтинг IEEE Spectrum видится более реалистичным, нежели TIOBE. Первая десятка тиоба ещё ничего, но дальше сплошные странности. ActionScript, который живее всех живых, и процветает в социалках, не попал даже в топ50, хотя там есть куча экзотики.
Ну и всё равно все эти рейтинги не несут полезной информации. По ним бессмысленно выбирать язык для изучения, будь то первый или десятый изучаемый язык. С качеством языка, зарплатой или сложностью применения рейтинг никак не коррелирует. Так помериться, у кого длиннее популярнее
Это охренительно круто! Сходу понятно не всё, но интерполяция это интересно.
Вопрос не совсем по теме, но давно интересовал. А следует ли из гладкости однозначность представления каждого поворота? В общем случае точно нет, а что здесь? В углах 360 == 0, что иногда неудобно. Имеется в виду, например, такая задача: есть анимация вращения колеса, промежуточные кадры интерполируются по клбчевым, но при переходе через 360 мы интерполируем углы 359 и 0, получая резкий скачок на одном кадре. Понятно, что это легко решается на программном уровне, приводя всё в один отрезок, по сути оперируя углом по модулю 360, но всё же решается ли эта проблема более элегантно?
Ваш метод примеряется, только не с кадрами с разных телескопов, а с серией с одного. То есть берём 1000 кадров с одного и того же телескопа в примерно одинаковых условиях и стекируем. Все качественные любительские снимки так и сделаны. Поднять разрешающую способность стекирование позволяет очень слабо, скорее точнее приблизиться к теоретическому максимум телескопа, зато динамический диапазон поднимает многократно. Да и шум снижает. Это позволяет разглядывать очень тусклые объекты.
Хотя для повышения разрешения тоже применяется. Можете погуглить «вебкаминг планет», когда из видео с обычной вебкамеры получают качественные снимки Юпитера, Сатурна, Марса. И там снимают видео, потому что нужны тысячи и тысячи кадров.
P.S. Посмотрите на астрофоруме, там, кажется, кооперировались для совместного стекинга.
материнские платы чаще всего не поддерживают режим AHCI, а значит, режим «профилактики и самообслуживания» (TRIM) не будет работать.
Не правда, не укрепляйте мифы. Наличие AHCI вовсе не обязательно. TRIM — комманда ATA интерфейса, поэтому она может быть переслана контроллером даже в IDE режиме, даже контроллером, который не умеет AHCI. Я заводил TRIM на Win7 на материнке с мостом ICH9(не R). Да, это медленнее, но всёравно гораздо лучше HDD.
Справедливости ради отмечу, что под линуксом GDC действительно сгенерировал 10 мегабайт. Но gdc сейчас во многом отстаёт, вон и версия языка только 2.066.
Свежий LDC сгенерировал 645 килобайт. Много, но я не пытался ничего ужимать. Думаю, что тут как и у Rust пожмётся выкидыванием лишнего.
Не надо бросаться камнями в D, не проверив на хоть сколько-то актуальной версии. На Win7 64-bit с DMD 2.070.0 helloworld занимает 200 килобайт. Без ключей, без конфигов. Если заморочиться размером, то можно не отставать от C. Вот, например, helloworld в 438 байт: http://forum.dlang.org/thread/qcbicxrtmjmwiljsyhdf@forum.dlang.org
с lvalue gcc говорит, что error: call of overloaded 'bar(int&)' is ambiguous
bar(a);
^
Потому что обе сигнатуры — одно и то же для перегрузок. То есть всё работает, но ошибка совсем не информативна.
P.S. Лучше воспользоваться не =delete, а static_assert (false, «lvalue is not supported»);
Божественно. Особенно радует, что это не экран шаблонного кода, а вполне вменяемые 2 строки. Удачно отделяется концепт с условием от определения самого метода. Всё таки даже без концептов С++11 силён.
Долго соображал над конструкцией typename = std::enable_if_t<...>. Я правильно понял, что это просто безымянный аргумент шаблона для using? А то на первый взгляд выглядит как специальный синтаксис.
С тем количеством динамики, которое заложено в JS и, соответственно, в TS, получится медленнее, чем V8. Не вижу потенциала для ускорения. V8 и так компилит всё, что возможно. Можно попробовать с потерей динамики, то есть в рамках абстракций TS, но не уверен, что это будет достаточно понятно, гибко и быстро.
Вот возможность писать плагины к ноде на D не помешала бы. Это и сейчас возможно, просто не удобно, много рутины на стыке C++ и D.
Вам не верят те, кто тоже компилировал свои проекты и сравнивал. Для веба действительно не так заметно, там больше libevent работает, но имеет смысл проводить более чистый эксперимент. В реальном коде будет что оптимизировать, и тогда выбор компилятора будет вносить существенный вклад.
И всё-таки хочется конкретных опций компилятора (inline, O3, nobounds-check вкл или выкл).
P.S. минус не мой, не подумайте.
Меня тоже вначале удивляло процедурно-функциональное API. Но если понять и принять идею, то фобос очень удобен. Особенно это касается диапазонов (ranges), которые однозначно лучше всего, что я видел в других языках. Может быть поначалу и непонятно, зато отличное соотношение удобство/производительность.
Только как-то очень хаотично написан раздел про llvm. Что получилось собрать, а что нет? В графики попала wasm версия полученная через asm.js, а упрощённый тест был просто для проверки, что 64 бита возможны? Тогда можно ожидать, что когда всё заработает wasm версия будет в несколько раз быстрее?
Статья — непоследовательное попоулистское повествование с графиками чтобы выглядеть научным. Не рассмотрены никакие другие факторы, не оценены степени их влияния, а по стилю изложения и аргументации не уступает хрен-тв с инопланетянами.
всякими глупыми вставкамизачёркнутыми фразами. Очень утомляет и отвлекает.Ну и всё равно все эти рейтинги не несут полезной информации. По ним бессмысленно выбирать язык для изучения, будь то первый или десятый изучаемый язык. С качеством языка, зарплатой или сложностью применения рейтинг никак не коррелирует. Так помериться, у кого
длиннеепопулярнееВопрос не совсем по теме, но давно интересовал. А следует ли из гладкости однозначность представления каждого поворота? В общем случае точно нет, а что здесь? В углах 360 == 0, что иногда неудобно. Имеется в виду, например, такая задача: есть анимация вращения колеса, промежуточные кадры интерполируются по клбчевым, но при переходе через 360 мы интерполируем углы 359 и 0, получая резкий скачок на одном кадре. Понятно, что это легко решается на программном уровне, приводя всё в один отрезок, по сути оперируя углом по модулю 360, но всё же решается ли эта проблема более элегантно?
Хотя для повышения разрешения тоже применяется. Можете погуглить «вебкаминг планет», когда из видео с обычной вебкамеры получают качественные снимки Юпитера, Сатурна, Марса. И там снимают видео, потому что нужны тысячи и тысячи кадров.
P.S. Посмотрите на астрофоруме, там, кажется, кооперировались для совместного стекинга.
Не правда, не укрепляйте мифы. Наличие AHCI вовсе не обязательно. TRIM — комманда ATA интерфейса, поэтому она может быть переслана контроллером даже в IDE режиме, даже контроллером, который не умеет AHCI. Я заводил TRIM на Win7 на материнке с мостом ICH9(не R). Да, это медленнее, но всёравно гораздо лучше HDD.
Свежий LDC сгенерировал 645 килобайт. Много, но я не пытался ничего ужимать. Думаю, что тут как и у Rust пожмётся выкидыванием лишнего.
error: call of overloaded 'bar(int&)' is ambiguous
bar(a);
^
Потому что обе сигнатуры — одно и то же для перегрузок. То есть всё работает, но ошибка совсем не информативна.
P.S. Лучше воспользоваться не =delete, а static_assert (false, «lvalue is not supported»);
Долго соображал над конструкцией typename = std::enable_if_t<...>. Я правильно понял, что это просто безымянный аргумент шаблона для using? А то на первый взгляд выглядит как специальный синтаксис.
Вот возможность писать плагины к ноде на D не помешала бы. Это и сейчас возможно, просто не удобно, много рутины на стыке C++ и D.
И всё-таки хочется конкретных опций компилятора (inline, O3, nobounds-check вкл или выкл).
P.S. минус не мой, не подумайте.