Проблему "не люблю ждать" очень просто решить. За бОльшие деньги, чем обычно стоит услуга все можно получить очень быстро. Если же потребляется стандартная и дешевая услуга, которая стоит как у всех, то здесь необходимо смириться с автоответчиками и очередью запросов :)
Да и еще... если возникает желание запостить топик о подобном после передачи на НТВ, то стоит задуматься над тем - насколько легко вы внушаемы или подвержены зомбированию :)
Сами того не зная таким досугом, когда избегаете мыслительной деятельности, вы переключаете решение стоящих перед вами задач на подсознание - поэтому, например, выйдя на работу на следующий день вы легко, сходу можете решить задачу, к которой не могли подступиться вчера :)
Все люди разные, что для одного хорошо, то для другого плохо. Все бросить и уехать жить в гоа - это фактически поиск себя. Но некоторым все же удается найти свое место в жизни и уйти на покой они не могут до глубокой старости, потому что действие - это их натура. Представьте себе мир, где все будут сидеть под пальмами и есть бананы, но ничего больше не делать :)
Появление чувства ответственности - признак взросления. Излишние волнения, правда, морут привести к депрессии - выдыхайте. Все что вы описали было практически всегда - стоит только почитать старые книги :)
К тем, кто заключает договор на бумаге и кто не вырубит домен просто так, без официального судебного решения, например ;) Рекламировать никого не буду, но таких немного.
Я бы рекоменовал перевести домены к более легальным регистраторам :) "Приличная экономия" меньше стоимости чашки кофе может легко аукнуться потерей домена. Имхо, оно того не стоит. А для крупных клиентов скидки есть у многих.
Зря выплатили. Надо было забить. Если бы директор начал бы выеживаться - жалобу в комиссию по труду или налоговую службу и товаришу пришел бы такой кирдычек, что он бы еще потом очень сильно пожалел об этом.
Да, компилятор, несомненно сможет развернуть цикл, заменить divы на битхаки подобные приведенному в этой статье, но это не отменяет того, что нужно знать специфику компиляторов и процессоров. Конвейеры это конечно круто, но компилятор не сделает за вас эту работу. Чтобы конвейеры использовались нужно написать грамотный код, а грамотный код нужно писать держа в уме таблицы из референса по ASM по операциям, которые могут выполняться параллельно, а также неплохо иметь понятие, каким образом в SMP используются различные уровни кэша, как идет работа с памятью и т.п..
Если написать логику без учета этих многих параметров, то результат может получиться много медленнее несмотря на оптимизацию от компилятора. Это примерно как оптимизировать целочисленную логику под SSE, когда эти же операции выполняются на новых интелах с таким же уровнем параллелилизма, но без затрат на ввод/вывод данных в специальные регистры. Без использования SSE логика даже рассчитанная на параллельные вычисления будет работать быстрее. Чтобы использование SSE (и любой другой SIMD технологии) дало нужные результаты - нужно четко понимать - для чего это используется и в каких случаях можно получить преимущество.
Убеждать против подхода "за счет инлайнов", "сорт в C++" и "быстрее" считаю бессмыссленным. Любое мнение имеет право на жизнь. Если долго повторять себе, то начинаешь в это верить :)
ИМХО, тот, кто занимается оптимизацией должен знать несколько больше слов, чем "инлайны" и "сорт в C++", в противном случае остается пользоваться устаревшим кодом из неэффективных библиотек написанных много лет назад.
Что же касается C vs C++, то работа под высокой нагрузкой в мультипоточной среде при SMP основанная на сборке мусора ... кхм. Зачем тогда пишут вещи подобные hoard, ведь лучше использовать все стандартное и полагаться на компилятор? :)
а сколько вы знаете highload серверов написанных на плюсах? есть мнение что писать для быстродействия нужно на C используя местами ASM, а плюсы больше для бизнес приложений где важно чтобы куча кетайцов и индеров могла свободно ориентироваться в коде
http://developers.sun.com/solaris/articl…
Попробуйте, как нибудь поинтересоваться, как реализуется обычно сборка мусора для SMP и какие операции нужны, чтобы отслеживать число ссылок.
Если написать логику без учета этих многих параметров, то результат может получиться много медленнее несмотря на оптимизацию от компилятора. Это примерно как оптимизировать целочисленную логику под SSE, когда эти же операции выполняются на новых интелах с таким же уровнем параллелилизма, но без затрат на ввод/вывод данных в специальные регистры. Без использования SSE логика даже рассчитанная на параллельные вычисления будет работать быстрее. Чтобы использование SSE (и любой другой SIMD технологии) дало нужные результаты - нужно четко понимать - для чего это используется и в каких случаях можно получить преимущество.
Убеждать против подхода "за счет инлайнов", "сорт в C++" и "быстрее" считаю бессмыссленным. Любое мнение имеет право на жизнь. Если долго повторять себе, то начинаешь в это верить :)
ИМХО, тот, кто занимается оптимизацией должен знать несколько больше слов, чем "инлайны" и "сорт в C++", в противном случае остается пользоваться устаревшим кодом из неэффективных библиотек написанных много лет назад.
Что же касается C vs C++, то работа под высокой нагрузкой в мультипоточной среде при SMP основанная на сборке мусора ... кхм. Зачем тогда пишут вещи подобные hoard, ведь лучше использовать все стандартное и полагаться на компилятор? :)
Про стандарный сорт ... кхм.
http://research.microsoft.com/barc/sortb…
Некоторый софт доступен даже для скачивания. Можно протестировать :)