> памяти питон жрет в среднем меньше чем жаба

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lan...

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

легко могу сравнивать :) неужели ты мне в этом праве отказываешь, на каком основании? или ты не знал что так можно? :)

мне кажется ты забыл капсом дописать "МНЕ ОНИ НРАВЯТСЯЯЯ!!!!!!11адинадин АРРРГГГХХХ!"

хм, думал будет понятно ещё прошлый раз, ну раз непонятно - копаем глубже

struct _GArray
{
  gchar *data;
  guint len;
};

struct _GByteArray
{
  guint8 *data;
  guint	  len;
};

struct _GPtrArray
{
  gpointer *pdata;
  guint	    len;
};

ничего не смущает?

и, как следствие:

GArray* g_array_new(/*blah*/);
GPtrArray* g_ptr_array_new(/*blah*/);
GByteArray* g_byte_array_new(/*blah*/);

здесь тоже ничего не смущает???

shty (24.07.2010 18:22:32)

Я думаю гугль продвигает питон

Gary (24.07.2010 18:22:58)

>>Талмудов. Или ты ещё о чём-то подумал?

Почему не значит? Повторю тебе опять: ты сравнил эзотерическую хрень с языками высокого уровня.

MuZHiK-2 (24.07.2010 18:23:11)

>ты сравнил эзотерическую хрень с языками высокого уровня.

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

Mystra_x64 (24.07.2010 18:27:24)

Роб дело говорит, хоть и попаболь у ЦПЛЮСПЛЮСеров с ЖАВАфилами

paran0id (24.07.2010 18:29:16)

> хоть и попаболь у ЦПЛЮСПЛЮСеров с ЖАВАфилами

и не говори - просто на говно исходят

>>легко могу сравнивать :) неужели ты мне в этом праве отказываешь, на каком основании? или ты не знал что так можно? :)

Можно много чего, но это не означает трезвость ума.

>>ничего не смущает?

Нет, потому что все реализации сделаны на основе GArray. Для удобства использования API. Но никто не мешает тебе все время пользоваться GArray - на здоровье. Только ты, сынок, забыл посмотреть ВСЮ реализацию GArray перед тем, как метанировать. Потому что если бы ты ее посмотрел, то увидел бы, что вся работа идет через другую структуру - общую для всех тобой указанных:

struct _GRealArray
{
  guint8 *data;
  guint   len;
  guint   alloc;
  guint   elt_size;
  guint   zero_terminated : 1;
  guint   clear : 1;
  volatile gint ref_count;
};

>>здесь тоже ничего не смущает???

А что там не так? Повторяю, это всего лишь для удобства API, ты всегда можешь напрямую для всех целей использовать GArray. Никто не запрещает. Так где костыли-то?

MuZHiK-2 (24.07.2010 18:31:58)

>>Если язык умеет больше, например, то и талмуд будет больше. Также зависит от автора (стиля текста). Так тоже не ясно?

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

MuZHiK-2 (24.07.2010 18:34:53)

> ты всегда можешь напрямую для всех целей использовать GArray. Никто не запрещает.

И потерять все проверки компилятора на совпадение типов. Ты вообще не в своем уме, или тупо троллишь?

tailgunner (24.07.2010 18:36:00)

Однако если язык умеет слишком мало, то см. пример с Brainfuck'ом. Сравнивать по размеру талмуда — глупость.

Mystra_x64 (24.07.2010 18:36:13)

> Талму́д (ивр. תָלְמוּד‎, «учение, учёба») — многотомный свод правовых и религиозно-этических положений иудаизма

Евреи не одобряют ваш разговор.

Zubchick (24.07.2010 18:36:16)

Предлагаешь считать бинарные деревья и множества Мандельброта на мобилках? Да ты упоротый!

DNA_Seq (24.07.2010 18:38:42)

>>И потерять все проверки компилятора на совпадение типов. Ты вообще не в своем уме, или тупо троллишь?

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

MuZHiK-2 (24.07.2010 18:39:27)

> volatile gint ref_count;

сборка мусора через подсчет ссылок удивляет

sign (24.07.2010 18:40:21)

> Я же не говорю использовать GArray напрямую там, где УЖЕ используются другие типы. Я говорю о том случае, когда ты на пути первоначального выбора, что использовать.

Хм. Похоже, не в своем.

tailgunner (24.07.2010 18:40:45)

>>Хм. Похоже, не в своем.

Как всегда, аргументированно.

MuZHiK-2 (24.07.2010 18:42:12)

>>сборка мусора через подсчет ссылок удивляет

А что удивительного? В GObject это обычное дело, хотя GArray и не относится к нему.

MuZHiK-2 (24.07.2010 18:43:37)

> Как всегда, аргументированно.

Напиши мне выборку элемента из _GRealArray.

tailgunner (24.07.2010 18:43:53)

>>Однако если язык умеет слишком мало, то см. пример с Brainfuck'ом. Сравнивать по размеру талмуда — глупость.

Причем тут мало умеет? Я сравнил языки высокого уровня, брейнфак к ним не относится.

MuZHiK-2 (24.07.2010 18:44:28)

>и да, раз уж ты такой умный, предложи способ написания обобщённого контейнера в Си :) мне это нужно, да

Просто. Береж java.collections, пишешь свой код, компилишь, берешь javap, смотришь полученный байткод, переносишь на C. профит

Karapuz (24.07.2010 18:45:19)

>Я сравнил языки высокого уровня

Ты так говоришь, как будто это что-то меняет.

Mystra_x64 (24.07.2010 18:45:34)

>>Напиши мне выборку элемента из _GRealArray.

GRealArray - это приватная структура, описанная в garray.c, а потому не доступная для работы из вне. Непонятно, где ты собрался ее применять. На ее основе сделаны GArray, GPtrArray и GByteArray.

MuZHiK-2 (24.07.2010 18:46:32)

>>Ты так говоришь, как будто это что-то меняет.

Ты так говоришь, будто писать на асм и жабе - одно и то же.

MuZHiK-2 (24.07.2010 18:47:46)

Ну, не так уж и тонко, на /. 683 коммента уже

Karapuz (24.07.2010 18:48:23)

> GRealArray - это приватная структура, описанная в garray.c, а потому не доступная для работы из вне. Непонятно, где ты собрался ее применять.

Афигеть %) Пациент путается в показаниях. Это ты сказал вот эту глупость:

> ты всегда можешь напрямую для всех целей использовать GArray.

> напрямую

> для всех целей использовать

Я с удовольствием посмотрю, как ты будешь выпутываться :D

tailgunner (24.07.2010 18:50:00)

дело мужик говорит

jtootf (24.07.2010 18:50:48)

а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Вы таки не поняли что дело не в критике glib, она то как раз хорошая, к ней вопросов нет :) критика к тому что приходится писать постоянно кучу подпорок, например Вы видели что происходит внутри gvarianttype (а отнюдь не gvalue как Вы предлагали) - это застрелите меня что там происходит и так со всем и везде

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

ты это, рамсы чёт совсем попутал, давай полегче тут, не дома на диване

struct _GRealArray 
{ 
  guint8 *data; 
  guint   len; 
  guint   alloc; 
  guint   elt_size; 
  guint   zero_terminated : 1; 
  guint   clear : 1; 
  volatile gint ref_count; 
};

во-первых не забыл, просто движение должно осуществляться поступательно

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

вкратце вот такие, я считаю, недостатки у языка си и это мешает мне применять его во многих проектах

shty (24.07.2010 18:50:49)

непомешало бы иметь конструкторы и деструкторы в glib для их динамических объектов а то помимо glib в функции надо освободить ресурсы так еще приходится и следить чтоб вся память из по этих в кавычках динамических структур была освобождена в итоге не код а одно осовождение ресурсов получается

>Один из ведущих инженеров Google

s/Один из ведущих инженеров Google/Один из ведущих быдлокодеров Google

PS ниже эпичная новость: "ffvp8 уделал оригинальный гугловский декодер, будучи еще на довольно раней стадии разработки"

erfea (24.07.2010 18:53:00)

>>Афигеть %) Пациент путается в показаниях. Это ты сказал вот эту глупость:

Ты упоротый что ли? GArray и GRealArray - это две разных структуры. Я ничего не спутал. Ты хоть glib видел в глаза, или так, пометанировать захотелось? Ты можешь при желании использовать GPtrArray и GByteArray, но (!), если тебя в них что-то не устраивает, ты ВСЕГДА для ВСЕХ целей можешь воспользоваться более общим вариантом - GArray. GRealArray был приведен к метанированию о костылях в реализации другого пациента.

>>Я с удовольствием посмотрю, как ты будешь выпутываться :D

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

MuZHiK-2 (24.07.2010 18:54:47)

У инженеров Гугл ЧСВ овер 9000 по умолчанию.

> Ты упоротый что ли?

Я - нет, а ты?

> GArray и GRealArray - это две разных структуры.

Напиши мне выборку элемента любого типа, кроме char, из любого из них.

tailgunner (24.07.2010 18:58:45)

>>а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Используй GArray и не парь людям мозги.

>>критика к тому что приходится писать постоянно кучу подпорок, например Вы видели что происходит внутри gvarianttype (а отнюдь не gvalue как Вы предлагали) - это застрелите меня что там происходит и так со всем и везде

Где эти подпорки? Если ты называешь подпорка то, что в glib прикрутили ООП - то это твои проблемы, что ты не осилил ООП и тебе хочется быдлокодить на крестах и джабе.

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

Ты так и не объяснил, в чем заключается костыльность данной реализации. Почему другие работают и не говорят о нехватке каких-то ресурсов?

MuZHiK-2 (24.07.2010 18:59:33)

>>непомешало бы иметь конструкторы и деструкторы в glib для их динамических объектов а то помимо glib в функции надо освободить ресурсы так еще приходится и следить чтоб вся память из по этих в кавычках динамических структур была освобождена в итоге не код а одно осовождение ресурсов получается

Беги на жабу.

MuZHiK-2 (24.07.2010 19:00:46)

>>Я - нет, а ты?

Нет, а ты?

>>Напиши мне выборку элемента любого типа, кроме char, из любого из них.

Она уже 10 лет назад была написана - посмотри в исходниках glib g_array_index ().

MuZHiK-2 (24.07.2010 19:03:46)

Да ее можно сделать вообще на чем угодно.

Проблема в том, что мне нужен язык, у которого есть такая сущность как память. У явы, например, нет. У Плюсов с stl тоже ее нет. И как тут жить?

У erlang, кстати, тоже, как и у haskell.

catap (24.07.2010 19:09:21)

неужели не понятно, что использовать glib не всегда возможно?

какие то взаимоисключающие параграфы ни о чём - пропускаем

костыльность в чём? - в костылях,а в чём же ещё

когда Вы поучаствуете в написании достаточно большого проекта на си с нуля в котором нельзя будет использовать GPL/LGPL код и всё это будет в условиях существенно ограниченного времени (а так оно так практически всегда), то я верю что у Вас таких вопросов больше возникать не будет

shty (24.07.2010 19:09:48)

>будто писать на асм и жабе - одно и то же.

Не угадал. goto start

Mystra_x64 (24.07.2010 19:10:23)

>>неужели не понятно, что использовать glib не всегда возможно?

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

>>костыльность в чём? - в костылях,а в чём же ещё

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

>>когда Вы поучаствуете в написании достаточно большого проекта на си с нуля в котором нельзя будет использовать GPL/LGPL код и всё это будет в условиях существенно ограниченного времени (а так оно так практически всегда), то я верю что у Вас таких вопросов больше возникать не будет

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

MuZHiK-2 (24.07.2010 19:14:56)

>>Не угадал. goto start

Зациклился? Не переживай, бывает.

MuZHiK-2 (24.07.2010 19:17:36)

а что, есть какая-то разница?

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

нужно эти 3 показателя иметь сбалансированными :) и замедлять разработку путём выбора неправильного ЯП - это называется ССЗБ

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

а если нет нужного велосипеда - что тогда? а я скажу - сидеть и есть кактус, надеясь что успеешь

shty (24.07.2010 19:27:18)

Петросян, перелогиньтесь.

Mystra_x64 (24.07.2010 19:27:26)

>ниже эпичная новость: "ffvp8 уделал оригинальный гугловский декодер, будучи еще на довольно раней стадии разработки"

Очевидно же, в гугле просто не занимались преждевременной оптимизацией, а писали код, который хоть както декодирует VP8

А вот когда они перепишут его на Go.....

Karapuz (24.07.2010 19:27:27)

ты сравнил языки программирования по объему талмудов, а это есть глупость

> А вот когда они перепишут его на Go.....

самому не смешно?

>И этот специалист возьмет ваш код, покачает головой, поцокает языком и скажет "не-не-не, мне дешевле переписать это все с нуля, чем оптимизировать отдельные участки"

Согласен. Я этот отрывок запостил как ржаку над всей этой руби-викой. Как вообще можно писать программу не имея перед собой плана или алгоритма, оптимизирующего работу.. Так только на руби наверно и пишут :)

unt1tled (24.07.2010 19:36:38)

tailgunner> И нас всех спасет Go?

Goсподу-у-у помолимся-а-а, братия-а-а.

sdio (24.07.2010 19:38:11)

Не дезинформируйте людей: это не гугл дал оценку, а Роб Пайк.

smh (24.07.2010 19:39:33)

>> И нас всех спасет Go?

> Goсподу-у-у помолимся-а-а, братия-а-а.

ЛММ не даст нас в обиду, спасет от маразматика Пайка и его дебильного кролика %)

tailgunner (24.07.2010 19:41:14)