Достаточно долго у меня дома лежала ESP с ними, по поводу чистоты звука, эм… я еще поверю в то, что PAF дает достаточно чистый звук но не emg (хотя опять же, в каком плане он должен быть чистый с электрогитары?).
У меня, да и не только у меня, сложилось мнение что звук их не меняется от гитары, чистый звучит резко и однообразно — как любая баллада любой тяжелой группы (думаю это как-то связанно). Мяса много. Даже небольшой кранч звучит так, что хочется играть не блюз, а гонять риффы.
При этом некоторым приятнее слушать меня, чем пару знакомых, у одного из которых акустика за 50к «из канадского клена и over9000 слоев лака».
Это ни о чем не говорит, ну разве что о том, что из инструмента необходимо научиться извлекать звук. Цеплять струны может каждый, а сыграть так, что бы это стало мелодией, да еще и приятной — далеко не все.
И опять же, как говорили ниже: зайдите в любой музыкальный магазин, возьмите любую приличную гитару и послушайте в любой приличный усилок. А там уже от вас зависит, к примеру мой друг (в общем-то программист-диванный гитарист) сразу оставил пару своих зарплат и запряг меня погружать купленное добро в его машину.
А надо ли в будущем уметь играть на лопате? Часто ли приходится? Мне вот, после того как купил нормальную гитару, а картонку с надписью Jackson, стало играть в удовольствие: поэтому иногда проводил за занятиями по 7-10 часов, а не 2-3 как раньше, поэтому же и через пару месяцев после покупки стал играть гораздо лучше, начало что-то появляться, что обычно зовут техникой. Тоже самое было и с моими знакомыми, а у меня тогда в то время был достаточный круг общения среди музыкантов, что бы судить о тенденции… Покупали с первыми зарплатами нормальный инструмент, сразу же становились на голову лучше нежели были раньше.
Поэтому советы вроде «сначала дорасти до инструмента» и начни учиться на говне — это бред. Хреновый инструмент во первых может убить всю технику, точнее даже так — все что связано со звукоизвлечением, а во вторых отбить желание учиться и заниматься музыкой
Качество звука напрямую зависит от качества дерева, если это спресованная фанера, то такой гитаре уже ничего не поможет. Ну разве что emg, и разве что если мы собираемся играть какой-нибудь грязный, неразборчивый треш
Я (не знаю, к счастью или к сожалению), пока еще не занимался оптимизацией матиматики под яву, но знаю людей которые плоненько так думали над тем, как быстро и красиво обработать пару млн структур с несколькими интовыми значениями… одним словом в таких случах следует быть чуточку ближе к памяти, нежели хочеться: тут и кэш у процессора сыграет свою роль, и возможностей по обработке больше (хотя они все страшные и посложнее будут).
Эти числа весьма highload, если обрабатывать это на одном ядре.
Слово highload уже стало таким, базарным, что ли, что его применяет ко всему, что только можно. Хайлоад и одно ядро, ну вам самой то не смешно? Хайлоад и использование синхронизации для доступа к общим данным.
Вы писали что у вас все лежит или лежало в дефолтных коллекциях. Я вот уверен, что если немного посидеть и подумать над математикой то можно это все ускорить в, ну не знаю, раз десять. Вот когда вы выжмите из просчета мира все, что только можно, тогда и думайте о том, что у вас хайлоад, и ващи десять тыщ игроков уже не влезаеют на один сервер…
Надеюсь вы знаете, что synchronized — это ой как дорого и с java 1.5 (+1.6) есть атомарные синхронизации.
synchronized в яве разный бывает (а точнее может быть одним из трех). JVM очень хорошо умеет его оптимизировать, но увы, если мы постоянно дергаем монитор из разных потоков то мы несчадно тратим ресурсы и на синхронизацию тоже
Synchronized не так уж и дорого. Структура такова, что синхронизация происходит лишь при доступе к общим коллекциям и ни как иначе.
А насколько коллекции общие и как часто к ним происходит обращение и со скольки потоков. Хотя думаю что в данном случае это самое «дорогое» что у вас есть.
Пока вы будете писать свою сборку мусора в мире уже будет написан десяток серверов которые по скорости и стабильности работы будут работать так же как и ваша поделка с супер адаптивной сборкой мусора.
Проходили уже это, если на яве пишут не ентерпразники, а люди понимающие что к чему (а таких кстати сейчас достаточно, что бы собрать команду, не то что три-четыре года назад) то ни у кого ни со скоростью, ни со сборкой мусора проблем не возникает
На старте моего проекта в 2006-2007 гг. пробовали и сишарп, и джаву. Обе версии стабильно держали порядка 500-1000 соединений, потом ой.
Два разных проекта (архитектура, геймплей) правда на одной платформе под популярным сетевым фреймворком в яве, один на 200 уже умирает выжирая все ресурсы до которых может дотянуться, другой 25 тысяч держит и жрет скромненько процессора и нормально так памяти (25 тыщ игроков, как никак в онлайне).
Не всегда. Если у вас много потоков и они переключаются постоянно, то общей памяти может не хватать, хотя она будет освобождаться своевременно.
Количество потоков тут роли не играет, я могу и одним потоком засрать так, что у меня будет каждые пару секунд память ворошится под yg и скапливатся все в og.
Full GC не нужен
Full gc хоть и зло, но увы, практически не избежен. Даже если поиграться с настройками jvm, то мы можем многократно увеличить время до полной сборки (путем увеличения yg), но полностью его исключить — увы, я не верю в столь оптимистичный сценарий. Но правда это все бессмысленно потому что избавится от Minor gc в сотни раз сложнее (привет doEscapeAnalysis, который давно уже по дефолту включен), а в некоторых случах не возможно вовсе.
Если вы дошли до Full GC, у вас память утекла, тут уже на лицо не шататная работа сервера.
Когда вы станете чуточку более опытнее, к примеру поработаете с несколькими высоконагруженными серверами, которые архитектурно разные, то вы не будете делать такие громкие заявления*
* да, на высоконагруженном игровом сервере full gc это ужас-ужас и может обернутся невероятными проблемами, но обычно стараются делать так, что бы время до full gc было гораздо больше нежели время работы сервера.
* в не совсем высоконагруженном игровом проекте, с небольшим хипом (допустим ±2гб) и не совсем сложной разветвленной стуктурой классов full gc (если мы говорим о параллельной сборке мусора) может занимать совершенно небольшое время (я сейчас про STW), которым можно пренебречь.
Знаю людей, которые перебегали из за 10% к зп на менее интересные проекты в совершенно непонятные места. Мало людей, да и они все молоды, которым хватает зарплаты программиста или ведущего программиста в Москве. Семейная жизнь у многих отнимает все до последней копейки.
Еще смешнее смотрится другая ситуация, опять же, которая приключилась со мной в прошлом году. Скоро (в ближайший месяц) дожен состоятся релиз, все в подвешанном состоянии, пишу завяление на майские. Ага, дают, но к сожалению, из за независящих от меня обстоятельств отпуск отменяю — не сидеть же неделю дома, или ездить по Москве в поисках всевозможных занятий.
Но когда отменял, сказал, что после релиза, когда я буду спокоен по поводу что все работает и что моя комманда сможет многие вещи решать без тех пяти дней, что меня не будет, то поеду отдыхать. Прошло полтора месяца, приложение уже запущено, народ идет, все хорошо спокойно, команда еще больше понимает что и как нужно делать, я на работе появляюсь на три-четыре часа, иду общатся по поводу отпуска и что же я слышу. О… нет, сейчас не лучшее время, необходимо много чего сделать, переделать, доделать и додумать.
В итоге день проведен весь на нервах, наорал на всех, послал всех в жопу и ушел (сказав, что собственно делайте то что хотите — я за своих людей спокоен, телефон у вас и у них мой есть, звоните если что). Прошла неделя, все чрезвычайно важные дела уже как-то решились без меня (многие из которых едва ли были важными), все хорошо и спокойно.
И это тоже, онажды столкнулся с похожей по маразму ситуацией: Ушел из компании A, которую купила компния B, которая является один из крупнейшних игроков в рунете. Одной из причиной ухода было то, что с непойми чего порезали прибавку к зп. Когда уходил, то пообщался с людьми из компани B, даже провели пару собеседований с ними — они готовы были меня взять на эту же должность но с большей зп.
Историю мало кто учит. Да, даже не в этом дело, многих людей даже не учит то, что они видят своими глазами.
Вроде сейчас уже и agile в моде, и везде скрам-канбан-лин в том или ином виде, а нет… (реальный пример от середины 2012-го года в достаточно крупной компании) есть такие кто начинает первую итерацию с фф 0.7, в итоге через три месяца реально сделанно только на 0.5 (ах, да, про баги забыли, мелкие детали не учли). Но ничего, поработаем лучше в следующих итерациях, мы же стали умнее и опытнее, правда фф придется поднять уже до 0.8. Ну как же, мы в этой итерацииплохо поработали. То, что под конец он едва перевалил за 0.4 отмечали уже всей компанией…
Еще хуже когда компания гордая и заявление подписывается, через какое-то время, они вынуждены либо согласится с изменившейся ситуацией на рынке (инфляция и прочие экономические прелести) или нанять менее компетентного специалиста,
Это не говорит ни о чем: может быть они работали в треть силы, а может быть стали выкладыватся на 172%, а после гей парада производительность упала в десятки раз, как обычно бывает после «релиза», когда разработчики сидят и по 12-13 часов допиливают код.
Дедлоки, это конечно неприятно, но лишь частный случай всех проблем с многопоточностью. Проблема с тестированием многопоточности в том, что ошибки могут возникать с невероятно низкой вероятностью, а вмешательство дебаггера гораздо больше нежели вмешательство тестов (где мы, к примеру можем проверять состояние каждые… допустим 1000 итераций).
При работе с дебаггером мейджика гораздо больше, и, если я не ошибаюсь, код, который мы дебажим не совсем тот код, который мы имеем после JIT-а, поэтому в данной ситуации мы дебажить можем совершенно не то, что нам нужно
У меня, да и не только у меня, сложилось мнение что звук их не меняется от гитары, чистый звучит резко и однообразно — как любая баллада любой тяжелой группы (думаю это как-то связанно). Мяса много. Даже небольшой кранч звучит так, что хочется играть не блюз, а гонять риффы.
Одним словом мне не понравилось.
Это ни о чем не говорит, ну разве что о том, что из инструмента необходимо научиться извлекать звук. Цеплять струны может каждый, а сыграть так, что бы это стало мелодией, да еще и приятной — далеко не все.
И опять же, как говорили ниже: зайдите в любой музыкальный магазин, возьмите любую приличную гитару и послушайте в любой приличный усилок. А там уже от вас зависит, к примеру мой друг (в общем-то программист-диванный гитарист) сразу оставил пару своих зарплат и запряг меня погружать купленное добро в его машину.
Поэтому советы вроде «сначала дорасти до инструмента» и начни учиться на говне — это бред. Хреновый инструмент во первых может убить всю технику, точнее даже так — все что связано со звукоизвлечением, а во вторых отбить желание учиться и заниматься музыкой
Слово highload уже стало таким, базарным, что ли, что его применяет ко всему, что только можно. Хайлоад и одно ядро, ну вам самой то не смешно? Хайлоад и использование синхронизации для доступа к общим данным.
Вы писали что у вас все лежит или лежало в дефолтных коллекциях. Я вот уверен, что если немного посидеть и подумать над математикой то можно это все ускорить в, ну не знаю, раз десять. Вот когда вы выжмите из просчета мира все, что только можно, тогда и думайте о том, что у вас хайлоад, и ващи десять тыщ игроков уже не влезаеют на один сервер…
synchronized в яве разный бывает (а точнее может быть одним из трех). JVM очень хорошо умеет его оптимизировать, но увы, если мы постоянно дергаем монитор из разных потоков то мы несчадно тратим ресурсы и на синхронизацию тоже
А насколько коллекции общие и как часто к ним происходит обращение и со скольки потоков. Хотя думаю что в данном случае это самое «дорогое» что у вас есть.
Проходили уже это, если на яве пишут не ентерпразники, а люди понимающие что к чему (а таких кстати сейчас достаточно, что бы собрать команду, не то что три-четыре года назад) то ни у кого ни со скоростью, ни со сборкой мусора проблем не возникает
На старте моего проекта в 2006-2007 гг. пробовали и сишарп, и джаву. Обе версии стабильно держали порядка 500-1000 соединений, потом ой.
Два разных проекта (архитектура, геймплей) правда на одной платформе под популярным сетевым фреймворком в яве, один на 200 уже умирает выжирая все ресурсы до которых может дотянуться, другой 25 тысяч держит и жрет скромненько процессора и нормально так памяти (25 тыщ игроков, как никак в онлайне).
Количество потоков тут роли не играет, я могу и одним потоком засрать так, что у меня будет каждые пару секунд память ворошится под yg и скапливатся все в og.
Full gc хоть и зло, но увы, практически не избежен. Даже если поиграться с настройками jvm, то мы можем многократно увеличить время до полной сборки (путем увеличения yg), но полностью его исключить — увы, я не верю в столь оптимистичный сценарий. Но правда это все бессмысленно потому что избавится от Minor gc в сотни раз сложнее (привет doEscapeAnalysis, который давно уже по дефолту включен), а в некоторых случах не возможно вовсе.
Если вы дошли до Full GC, у вас память утекла, тут уже на лицо не шататная работа сервера.
Когда вы станете чуточку более опытнее, к примеру поработаете с несколькими высоконагруженными серверами, которые архитектурно разные, то вы не будете делать такие громкие заявления*
* да, на высоконагруженном игровом сервере full gc это ужас-ужас и может обернутся невероятными проблемами, но обычно стараются делать так, что бы время до full gc было гораздо больше нежели время работы сервера.
* в не совсем высоконагруженном игровом проекте, с небольшим хипом (допустим ±2гб) и не совсем сложной разветвленной стуктурой классов full gc (если мы говорим о параллельной сборке мусора) может занимать совершенно небольшое время (я сейчас про STW), которым можно пренебречь.
Но когда отменял, сказал, что после релиза, когда я буду спокоен по поводу что все работает и что моя комманда сможет многие вещи решать без тех пяти дней, что меня не будет, то поеду отдыхать. Прошло полтора месяца, приложение уже запущено, народ идет, все хорошо спокойно, команда еще больше понимает что и как нужно делать, я на работе появляюсь на три-четыре часа, иду общатся по поводу отпуска и что же я слышу. О… нет, сейчас не лучшее время, необходимо много чего сделать, переделать, доделать и додумать.
В итоге день проведен весь на нервах, наорал на всех, послал всех в жопу и ушел (сказав, что собственно делайте то что хотите — я за своих людей спокоен, телефон у вас и у них мой есть, звоните если что). Прошла неделя, все чрезвычайно важные дела уже как-то решились без меня (многие из которых едва ли были важными), все хорошо и спокойно.
И к чему весь этот цирк?
Вроде сейчас уже и agile в моде, и везде скрам-канбан-лин в том или ином виде, а нет… (реальный пример от середины 2012-го года в достаточно крупной компании) есть такие кто начинает первую итерацию с фф 0.7, в итоге через три месяца реально сделанно только на 0.5 (ах, да, про баги забыли, мелкие детали не учли). Но ничего, поработаем лучше в следующих итерациях, мы же стали умнее и опытнее, правда фф придется поднять уже до 0.8. Ну как же, мы в этой итерацииплохо поработали. То, что под конец он едва перевалил за 0.4 отмечали уже всей компанией…
При работе с дебаггером мейджика гораздо больше, и, если я не ошибаюсь, код, который мы дебажим не совсем тот код, который мы имеем после JIT-а, поэтому в данной ситуации мы дебажить можем совершенно не то, что нам нужно