LINUX.ORG.RU

Существует ли язык высокого уровня, который устойчиво быстрее C?

 ,


0

1

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

Понятно что существует ассемблер, программу на котором можно сделать настолько быстрой, насколько это вообще возможно для данной машины за счёт контроля каждого байтика, но речь не о нём — я говорю о языке высокого уровня, который полностью абстрагируется от машины, так чтобы программа на нём могла быть скомпилирована на любой машине и для любой ОС.

Так вот, возможно ли сделать такой язык? Если да, то в каком направлении копать?

А может уже существуют такие языки, просто из-за популярности C на них мало кто пишет, поскольку всплывают проблемы совместимости с существующей базой уже готового кода?

★★★★★

Ответ на: комментарий от anonymous

Это не С

Поправка: это не стандартный С. Но на практике typeof широко применяется.

anonymous
()
Ответ на: комментарий от anonymous

Ты отвечай кокнретно на вопрос - применение и назначение.

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

Посмеялся.

Имелся ввиду стандартный для Linux, если что.

anonymous
()
Ответ на: комментарий от anonymous

Это не С

Мнение твоё меня не волнует. Он там чисто форфан.

А это дважды вызванный strlen для одной и той же строки. Царь ненастоящий!

О боже, о боже, давайте поможем ламерку посчитать кол-во strlen() - их там 3.

Ну и что с того, что их 2? Все говнякают, а мне нельзя?

anonymous
()
Ответ на: комментарий от anonymous

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

Ты не ответил. Ты привёл пример и слился как с первым, так и со вторым.

Теперь ты пытаешься съехать на «ждать» - это единственное, что ты можешь. Мне не нужно твоё «не ждать» - «не ждать» никакого отношения не имеет к твоим крестам и куллленивости.

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

Имелся ввиду стандартный для Linux, если что.

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

anonymous
()
Ответ на: комментарий от anonymous

Теперь ты пытаешься съехать на «ждать»

Это ты сам себе придумал. Я просто не стал отвечать на твое предположение. Получатель сам решает, что ему делать. В этом и смысл, что у него появляется выбор, т.к. все промежуточные функции не вызывают подвисание. К примеру, у объекта есть какое-либо свойство, которое надо получать у сервера, тогда я просто кладу в поле ленивое значение и возвращаю через обычный геттер. И это все, я не думаю о том, что мне надо кому-то что-то сообщать, что мне надо синхронизовать получение значения, если его попытаются взять из нескольких тредов. Что мне надо запускать вычисления и выписывать какие-то абстракции на абстракциях, как обычно любят предлагать для организации параллельных вычислений. А где-то наверху я просто вызываю:

let items = function_with_probably_lazy_result();
unwrap_async( items, fill_view );

Если items не ленивое значение - функция вызовется сразу. Если ленивое - посчитается в отдельном треде и функция вызовется после вычислений.

Мне не надо код - мне надо конкретную задачу, для решения которой твоя ленивость нужна

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

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

Он есть в LSB. Это что касается стандарта. От него зависит, например, rpm. Это что касается «гуйни для домохозяек».

anonymous
()
Ответ на: . от anonymous

Высер дебилоидов.

единственная на сегодняшний день кроссплатформенная библиотека, умеющая рисовать нормально выглядящую графику. кстати, выходит, что нормальных средств для клепания гую и сишки и не осталось: на андроиде про сишку забыли, на винде тоже (там теперь дотнет и всем сишка никому не интересна), на яблоплатформах objc и swift, а на линукс декстопном — Qt (у гтк уж больно вырвиглазно выглядят интерфейсы на hidpi мониторах).

выходит, что гуй рисовать на сишке, в общем-то, и нечем.

Что это?

Unreal Engine 4 — самый лучший, на сегодняшний день, игровой движок, и, естественно, самый популярный. конкурентов у него нет.

next_time ★★★★★
()
Ответ на: комментарий от next_time

на линукс декстопном — Qt

Ну ниче себе, какое наглейшее 4.2. Конечно на ЛОРе же никто линукс не видел.

anonymous
()
Ответ на: комментарий от next_time

Зато ты проговорился, что никому кюте не впилось как выясняется. Что ж так? Такой расчудесный кроссплатформенный тулкит не нужен никому кроме горстки прибабахнутых кадыйешнеков. И те скорее по историческим причинам за него держатся.

anonymous
()
Ответ на: комментарий от anonymous

Не про string, а про вектор, но суть та же:

Не поленился я - посмотрел это дерьмо - это же просто смешно. Это не бенчмарки - это дерьмо. Это не вектора - это дерьмо.

Уровень где-то в районе помойки, мб даже ниже.

anonymous
()
Ответ на: комментарий от next_time

нормально выглядящую графику

Культи-то? Нормальную графику? Я под столом!!!

на андроиде про сишку забыли

Ондроед — говно, которое только мудакам нужно!

на винде тоже

та же гадость.

выходит, что гуй рисовать на сишке, в общем-то, и нечем

OpenGL.

anonymous
()
Ответ на: комментарий от anonymous

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

Зачем это синхронизировать? Форфан?

Если items не ленивое значение - функция вызовется сразу.
spawn(for(list) spawn(use_callback_on_release = items) or lock) - проблема?

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

Апдейт твоего свойства должен кто-то инициировать - это значит, что либо ты читаешь свою фигню ещё раз и должен 100% спросить другу сторону - т.е. никакой ленивости, либо другая сторона инициирует апдейт и выпиливается/апдейтится из твоего контекста это уже в обработчике сети.

Причем данных очень много, они разные и между ними много связей.

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

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

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

У тебя там трупута полтора килобайта, учитывая уровень твоего кода - тут и треды не нужны.

Код получается почти таким же как однопоточный.

Ну я примерно понял что ты там наделал.

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

Он есть в LSB. Это что касается стандарта. От него зависит, например, rpm. Это что касается «гуйни для домохозяек».

Мне это не интересно. Что там и где есть - rpm не имеет никакого отношения к «стандартам», да и срал я на стандарты.

anonymous
()
Ответ на: комментарий от anonymous

Тебе уже говорили, что ты С++ не знаешь? ;) Используй reserve

Без сопливых знаю и про reserve и про гарантии выделения памяти одним куском для basic_string и вектор, и про трюкачество со swap, чтобы память высвободить и про другие познания на уровне зубрилки задрота-кодера, обладая которыми большинство цепепешников тешится мыслью, что они крутые хакеры :-)

anonymous
()
Ответ на: комментарий от next_time

Царь.

Это всё уровень домохозяек - там всё дело не в коде, а в api и его доступности. Сам по себе qt написан на си с классами в большей степени.

Вообще весь С++ - это про api, ибо никто из крестовиков код не пишет в подавляющем большинстве.

Qt

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

Я сижу всю жизнь на кедах и кути - жопа болит. Кути без кед - вырвиглазное дерьмо.

Ах да, на кути нет даже вменяемого калькулятора. Юзаю гномский - выглядит илитней, чем кеды пятые - пердит бай боже. http://rghost.ru/8mQYwKNCt/image.png - просто идеально.

UE4

Помойка для домохозяек. Ценен свой гуйнёй, а про гуйню для домохозяек я всегда говорил, что кресты тут вне конкуренции.

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

Если бы я не мог ничего написать сам - я бы сам ваял на крестах, собственно как это и делал раньше, ибо качество либ и вообще сишное комьюнити и код - это просто ад, погибель и садомия.

anonymous
()
Ответ на: комментарий от next_time

единственная на сегодняшний день кроссплатформенная библиотека

Не нужно. Маздай нужен только для домохозяек и максимум как игропускалка. И то - это заслуга не маздая.

на андроиде про сишку забыли

Там и про кресты забыли. Кусок дерьма.

на винде тоже

Для домохозяек.

на яблоплатформах objc

Это сишка.

swift

Мёртворождён.

а на линукс декстопном — Qt

кде.

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

Это сколько - 120? Это никому не надо.

выходит, что гуй рисовать на сишке, в общем-то, и нечем.

У меня почему-то калькулятор рисуется без проблем. Тем более гуй никому не нужен.

Гуй пишут домохозяйки, а на чём они его пишут - всем насрать.

Unreal Engine 4 — самый лучший, на сегодняшний день, игровой движок, и, естественно, самый популярный. конкурентов у него нет.

А зачем он мне нужен? Он нужен школьникам.

Глянул на список игры - кроме биошока - всё мусор для школьников.

anonymous
()
Ответ на: комментарий от anonymous

А для типичных случаев стратегия basic_string самая эффективная

Типичные случаи - это перекладывание кипричиков? :-) Ты это называешь программированием? :-) Тогда понятно, почему вас бомбит когда кто-то пишет свой код, который ваша братия называет «велосипедом» :-)

anonymous
()
Ответ на: комментарий от anonymous

Уровень где-то в районе помойки, мб даже ниже.

Ну да, куда практикам из facebook до теоретиков с LOR>

anonymous
()
Ответ на: комментарий от anonymous

Тогда понятно, почему вас бомбит когда кто-то пишет свой код, который ваша братия называет «велосипедом» :-)

Тебя макнули в твой код, потому-что он тормозной, и без вариантов будет медленнее str::string. На С можно и нужно работать эффективно со строками, но это не твой случай. Потому и не тебе судить на эту тему.

anonymous
()
Ответ на: комментарий от anonymous

Тебя макнули в твой код, потому-что он тормозной, и без вариантов будет медленнее str::string.

Задачи сделать код быстрее basic_string я перед собой не ставил :-)

На С можно и нужно работать эффективно со строками

Ясное море :-) Тоже мне, открыл глаза :-)

anonymous
()
Ответ на: комментарий от anonymous

Без сопливых знаю и про reserve и про гарантии выделения памяти одним куском для basic_string и вектор, и про трюкачество со swap, чтобы память высвободить и про другие познания на уровне зубрилки задрота-кодера, обладая которыми большинство цепепешников тешится мыслью, что они крутые хакеры :-)

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

anonymous
()
Ответ на: комментарий от anonymous

самые базовые вещи в этих языках, оказывается, удел задротов и зубрилок.

Зубрилко, это ты basic_string'овский reserve() называешь «базовой вещью цепепе»? :-) Бугага :-)

anonymous
()
Ответ на: комментарий от anonymous

Зубрилко, это ты basic_string'овский reserve() называешь «базовой вещью цепепе»? :-) Бугага :-)

А что для тебя базовое? Коровка говорит «Муууу»? Если ты не способен догадаться, что в С++ такая функциональность должна присутствовать, и никогда не просматривал весьма скудный набор методов, то зачем ты вообще что-то пытаешься говорить на эту тему? Нравится позориться и показывать свое неспособие?

anonymous
()
Ответ на: комментарий от anonymous

А что для тебя базовое?

Это тебя надо спросить про «базовое» :-) Ну раз уж ты это сморосил в контексте basic_string<>::reserve, значит, это имеет к этому гомну прямое отношение :-)

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

Упоролся что-ли? :-) Иди поспи :-)

Нравится позориться и показывать свое неспособие?

Нравится развлекаться :-)

anonymous
()
Ответ на: Царь. от anonymous

Ах да, на кути нет даже вменяемого калькулятора. Юзаю гномский

Мухаха! Царь не осилил bc и юзает кулькулятор для первоклассниц. Ну ты и днище, царидзе :-)

anonymous
()
Ответ на: комментарий от anonymous

И как ты собираешься элементарный синус посчитать в bc без геморроя? Никак!

Разве что запускать bc не напрямую, а через обертку, которая будет правильные функции добавлять. А то ведь по умолчанию даже константы pi нет… А если понадобятся другие, более редкие константы (та же постоянная Планка, заряд электрона или какая-нибудь эпсилон_нулевая)?

anonymous
()
Ответ на: комментарий от anonymous

Кстати, пользую октаву в качестве каркулятора. Чего и всем советую. Это не кастрат вроде bc, и не ублюдок вроде galculator, а отличный полноценный каркулятор, кторый и графики может нарисовать при необходимости.

anonymous
()
Ответ на: комментарий от anonymous

Нахрен мне эта помойка без вменяемого поля ввода? Он умеет в вменяемый hex, битопы?

anonymous
()
Ответ на: комментарий от anonymous

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

А что означают буковки bc ты не знаешь, да? Ну погугли ещё, лол!

anonymous
()
Ответ на: комментарий от anonymous

И как ты собираешься элементарный синус посчитать в bc без геморроя?

А тут ты и вовсе эпично обосрался.

anonymous
()
Ответ на: комментарий от anonymous

А если понадобятся другие, более редкие константы (та же постоянная Планка, заряд электрона или какая-нибудь эпсилон_нулевая)?

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

anonymous
()
Ответ на: комментарий от anonymous

А вот фиг!

Где ты в октаве гуйню видел? Там же CLI чистый!

anonymous
()
Ответ на: комментарий от anonymous

Угу. Что мне писать-кому отвечать? Всем ответил.

anonymous
()
Ответ на: комментарий от DarkEld3r

А какие-то планы на эту тему вообще имеются?

Не слышал. Надо ждать модулей, после них вероятно эта тема станет актуальной.

anonymous
()
Ответ на: комментарий от DarkEld3r

А какие-то планы на эту тему вообще имеются?

Рассуди логически :-) Какие такие могут быть планы та эту тему в языке, где очарованы шаблонами, на которых построена увесистая часть стандарта - STL? :-)

anonymous
()
Ответ на: комментарий от next_time

Оффтоп

Видели, например, как фаерфокс не умеет в hidpi.

А пример можно того, где он не умеет?

mamboo ★★
()

Неплохо вы тут упоролись. Так и подмывает напомнить:

может быть таки уже пора прекращать принимать такие вещества?

nezamudich ★★
()
Ответ на: комментарий от next_time

Видели, например, как фаерфокс не умеет в hidpi. Фаерфокс — не на Qt.

Это для тебя главный критерий что-ли? Тогда вали на гейось, хрена ты тут забыл? Фраерфокс и не должен уметь никакие хидпи, это дело тулкита. Портируют на гытыка3 (если не уже) и будет уметь. Уж точно никто в здравом уме не станет кюте натягивать на глобус. Несмотря на все потрясения с гомном3 чистых кюте приложений как было три калеки, так и осталось. Никто как видишь не хочет связываться с монолитной цепепе-какахой, даже смена лицензии этому дерьму не помогла.

anonymous
()
Ответ на: комментарий от anonymous

Портируют на гытыка3 (если не уже) и будет уметь.

У GTK+3 и GNOME3 своеобразные представления об «уметь в HIDPI». Qt и KDE в этом плане намного лучше, как по-мне... были, по крайней мере.

mamboo ★★
()
Ответ на: комментарий от mamboo

Первым делом нужно задаться вопросом: а нахер нужно это хидпи (т.е. масштабирование, если я правильно распарсил вашу маркетню)? Если оно так позарез нужно, что прям кушать не могешь, нужно задать себе второй вопрос: а нахер мне такому модному хипстору с таким красивеньким мониторчиком вообще линупс? И перестать уже быть латентным наконец.

anonymous
()
Ответ на: комментарий от anonymous

Царь.

такому модному хипстору с таким красивеньким мониторчиком вообще линупс

Ты не понял - на мониторчиков нет хидпи. Там от силы 100-120, если накатить 4к на 27, то будет 150 - это так же не хидпи.

Хидпи - это для нищих недобитков, типа на 5дюймовой помойке захреначиили 3к - вот тебе и хидипи. А так у бомжей 11-13дюймовая помойка с 2-3к - типичный булшит для нищих. Вот и нищая обезьяна покупает какой-то помойкабук чтоб на паре сидеть, а на монитор к нему бабок нет - вот и сидит с 11-13помойки и пишет в интернетах куллстори про «мелкие иконки».

anonymous
()
Ответ на: комментарий от nezamudich

Нахрен нужен синус в радианах? =D

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.