Обновить
-1
Deomid Ryabkov@rojer

Firmware geek

9
Подписчики
Отправить сообщение
Tamarin обрабатывает javascript примерно в 5 раз быстрее чем Gecko.
о чём говорить, когда люди покупают говно в банках на вес золота?
BSD у нас, а на западе в основном линукс.
> продолжающемуся соперничеству «кремниевых» гигантов.

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

совершенно правильно. если вы, студия, пишете компонент для заказчика, просто лицензируете его под GPL и передаёте вместе с исходниками.
> В этом случае GPL запрещает коммерческие разработки
естественно.
потому что то, что вы описываете:
> производить не-GPL продукты, которые используют API и являются внедряемыми в GPL-приложения.

называется "хапнуть и рубить бабло". взять GPL продукт, написать к нему свой кусочек и наживаться на нём, ничего не давая взамен. GPL совершенно осознанно это запрещает. в этом и состоит весь смысл GPL.
> А чем лучше? Тем что в одну строку можно код написать? А в другом в 2, 3, 10? Ерунда это все.
ok, давай писать всё прямо в машинных кодах. ведь все эти "языки программирования" - ерунда, не так ли? ну ладно, на машинных кодах - брутально. давай на ассемблере. ну да, то что ты пишешь в одну строчку на XXX, на ассемблере будет 200 строчек. ну так это же ерунда, так? нет, не ерунда. человек может оперировать ограниченным объёмом информации и экспрессивность языка - важная характеристика.
> т.к. $i-- выделяет дополнительную память для хранения предудыщего значения переменной
если компилятор не способен распознать и сделать такую простейшую оптимизацию, как замена i-- на --i в случае когда результат не используется, то это повод задуматься об адекватности компилятора.
нет. вдумайтесь: это выражение не имеет смысла.
имелась в виду скорость, /сек
сотни гигабит.
я думаю, оба типа трафика подросли, но http трафик за счёт ютуба подрос значительнее.
именно. не говоря уж о вопросах с ответами да/нет. это ж вслепую 50% попадания, о какой вообще защите может идти речь?
да, пардон, перепутал. самым быстрым будет прямое присваивание без разыменования (как описано ниже).
я не вполне ясно выразился.
первое: объявление массива и обращение к нему по ссылке - вообще не самый распространённый или оптимальный способ работы с массивом. когда это возможно, то с массивом нужно работать напрямую. $list[0] = 456 на 50% быстрее, чем $list->[0] = 456.

второе: тем не менее, разница между списочным присваиванием с разыменованием ссылки, @$list[0..2] = ( ), практически не отличается от присваивания без такового, то есть @list[0..2] = ( ).
хм. всё-таки это довольно странные и извращённые способы присваивания :)
а вот почему нету очевидного списочного присваивания?
    l_list => sub {
@$list[0..2] = ( 456, $bar, 'baz' );
},

это будет самый быстрый способ.
также list почему-то объявлен как ссылка, что не есть самый распространённый способ объявления списков.
по крайней мере стоило рассмотреть традиционный вариант my @list = ( ... )
по моим данным, вариант direct для @list будет на 50% быстрее, чем для @$list.
а вот существенной разницы между @$list = ( 456, ... ) и @list = ( 456, ... ) нет.
ну значит пофиксили уже, не будем файлить. shit happens, как грится :)

Информация

В рейтинге
Не участвует
Откуда
Ирландия
Дата рождения
Зарегистрирован
Активность