- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
public static int fullBendList(out List<MnOneBend> bendList, double angle, int angType, double diameter) {
bendList = new List<MnOneBend>(); if (bendList == null) return Utils.ecError;
List<double> angArray = new List<double>(); if (angArray == null) return Utils.ecError;
if (angType < 1 || angType > 3 || angle < 0) { Utils.ErrorMessage("FULLBENDLIST"); return Utils.ecError; }
MnBendHard bend = (MnBendHard)MnBend.createBend(angType); if (bend == null) return Utils.ecError;
MnBend.getBendAngleList(ref angArray, diameter, angType);
for (int i = 0; i < angArray.Count; i++) {
double ang = Math.Abs(angArray[i]) * Utils.PI / 180; if (ang > angle + Utils.EPS) continue;
List<MnOneBend> oneBendList = new List<MnOneBend>(); if (oneBendList == null) return Utils.ecError;
if (bend.oneBendAngArray(ref oneBendList, ang, diameter) != Utils.ecNorm) return Utils.ecError;
if (oneBendList.Count != 1) { Utils.ErrorMessage("FULLBENDLIST"); return Utils.ecError; }
bendList.Add(oneBendList[0]);
}
return Utils.ecNorm;
}
Сохранено оригинальное форматирование, так как это неотъемлемый элемент данного произведения. Utils.PI - настоящий правильный ! Exception ? - Не, не слышал. П.С. Автор отказывает устонавливать ReSharper. Как вылечить пациента ?
Follow us!
Здесь медицина бессильна. Помочь может только экзорцист.
Скажи, у вас стандартов оформления кода вообще нет?
И вообще, автоформат в нормальных иде по сочетанию клавиш, что мешает задействовать?
Слил опинсорсный проект на яве, в нем были настройки для эклипса со включенным автоформаттером. Для явы это, видимо, стандарт.
Если с автоформатом будет смотреться лучше - так и оставь, если будет возникать - обмозгуй с начальством.
Т.е. что его никто в отпуск не отпустит, т.к. такой код никто не сможет поддерживать в его отсутствии.
Либо пулемётами:
1) Если TFS есть, то можно в плагинах поковыряться, чтобы автоформатирование автоматом при CheckIn'е применялось.
2) Либо коммандами (http://blogs.msdn.com/b/djpark/archive/2008/08/16/organize-usings-across-your-entire-solution.aspx):
3) Либо более сложный вариант: EnvDTE. Благо с 8ой студии можно без ATL обёрток общаться с API.
Но такой код студия автоматом выравнивать должна. Или у вас #Develop?
Есть еще StyleCop+.
Его можно поставить в студию, на сервер и выставить проверку перед коммитом в SVN. И хош нехош, а придётся всё форматировать и комментировать!
Может он прозреет от содеянного?
Это результат команды выше.
стало еще хуже!
public static int FullBendList(out List<MnOneBend> bendList, double angle, int angType, double diameter)
{
bendList = new List<MnOneBend>();
var angArray = new List<double>();
if (angType < 1 || angType > 3 || angle < 0)
{
Utils.ErrorMessage("FULLBENDLIST");
return Utils.ecError;
}
var bend = MnBend.createBend(angType);
if (bend == null) return Utils.ecError;
MnBend.getBendAngleList(ref angArray, diameter, angType);
foreach (var t in angArray)
{
var ang = Math.Abs(t)*Utils.PI/180;
if (ang > angle + Utils.EPS) continue;
var oneBendList = new List<MnOneBend>();
if (bend.oneBendAngArray(ref oneBendList, ang, diameter) != Utils.ecNorm) return Utils.ecError;
if (oneBendList.Count != 1)
{
Utils.ErrorMessage("FULLBENDLIST");
return Utils.ecError;
}
bendList.Add(oneBendList[0]);
}
return Utils.ecNorm;
}
}
Что то Говнокод формат не держит
Это для ленивых разработчиков было сделано, а не для автокорректора.
Ведь хрен поймёшь что метод вернул *лицопальма*
Да и в IDE давно всё с шорткатами делается, а не мышками наводится.
Ну попробуй скопировать в студию, может у тебя по наведению мышки что-то появится:
Код для чтения в блокноте уже давно не пишется.
Ну давай тогда про стайлгайды забудем, в студии автоформат уже давно есть. Не нравится - студия сама отформатирует.
Локальные переменные давай называть так чтобы поверх затенение не проводить, т.к. 10+ студия уже сама подсвечивает использование мемберов.
Скажи, у вас стандартов оформления кода вообще нет?
Код для чтения в блокноте уже давно не пишется. (с)
>Ну давай тогда про стайлгайды забудем, в студии автоформат уже давно есть. Не нравится - студия сама отформатирует.
Если речь идет только об отступах - я бы когда-нибудь так и сделал и закоммитил, а потом спокойно обьяснил пациенту, что так код выглядит лучше.
>Код для чтения в блокноте уже давно не пишется. (с)
Нипонял.
Если это некий анонимный тип, то можно и глазками догадаться что там выведется. А если вот так всё var'ами заделать, то изредка приходится ещё и тип смотреть... Поэтому и говорю, что решарпистам за такое var'варство по умолчанию, надо ручки отрывать.
>а потом спокойно обьяснил пациенту, что так код выглядит лучше.
Это насильственное принятие, можно и на "барана" нарваться.
>Нипонял.
Это коммент к тому, что можно стайлгайдами не пользоваться, если и так новые IDE всё замечательно подсказывают, форматируют и подсвечивают. При этом, я придерживаюсь практики, что код должен в любом виде спокойно читаться без всяких var'ов, и генерик параметров типа InvokeProcess<A,B,C,D...>(...) {...}
Код типа Object object = new Object() встречается очень часто, и обьявление типа по сути лишнее.
Допустим, Lock.getLock() (Класс Lock - наш велосипед)
возвращал объект Lock.
Затем, мы устроили рефакторинг, метод getLock() остался, но теперь он выдаёт не Lock, а, скажем, Mutex. Соответственно, строка:
ошибки не вернёт, а ошибку мы получим в строках:
В данном случае догадаться где произошла ошибка достаточно просто, хотя и требует вникания в код.
А если это уже будет некая математическая операция?
> // ...
> lock.unlock();
Экцепшенов на вас нет...
А ты знал, что у каждого ядра л1 свой? А ты знал, что общие данные находятся минимум в llc? А ты знал, что для того, чтобы прочитать любые даные - надо мигрировать кешлайн из llc в l1d?
И лишь после миграции л1д - ты можешь их писать. В процессоре итак есть локи - твои же локи - говно безпрофитное.
Т.е. с нормальным выравниванием у тебя все данные до 64байт атомарные. А вообще питухи - юзают общую память для нитей только питухи. Максимум, что могут делать нити - это общий мердж, не более. Вы пишите это говно только лишь потому, что не осилил много"поточность", но писать говно надо - вот тыкаете логи где не попадя.
Ты про хардварную атормащину? Ну этож надо подумать - а тут чё - хреначь мютекс - всё за тебя придумано. А и похрен, что контекстсвичи - планеровщик уже убьёт твой процсс/нить - l1d/i будут уничтожены - похрен, мы же локнули.
> с нормальным выравниванием
Царь судя по всему под нормальным выравниванием подразумевает судя по всему, чтобы данные не пересекали границу кешлинии. И видимо только под x86-x64.
Похоже на правду. Посоны, он же гонит, правда?
> 64байт
Кешлиния в не топовых процах 1995 года (кои ещё можно встретить) разве не 32 байта или даже 16?
Видемо под любой современный х86, да и под не х86 - у норма ОС есть апи, по которому ты можешь узнать всё о камне, его кешах и их сво-вах.
>Похоже на правду. Посоны, он же гонит, правда?
На не х86 - твоя жава даже не заведётся. А уж сишарпик 120% .
>Кешлиния в не топовых процах 1995 года (кои ещё можно встретить) разве не 32 байта или даже 16?
Реально? Знаешь сколько стоит коре2 сейчас? 500рублей на развале. Если ты неспособен купить проц за 500рублей - тебе сишарпик не поможет.
И да, на топовом проце 1995года твой сишарпик и маздайка даже не подымится, не то, что жаба. Поэтому не кукарекай. Скажи - да, пропитушились, но что с нас анскилледов взять - скорбим.
Ты же знаешь нас анскиледов, пишущих на дядю? Так что нам такой вариант не подойдет. Если бы х86 имели кешлинии везде 64 байта - стало бы понятно. А вообще я думаю это не работает. Одно ядро вполне может записать только половину кешлинии, когда второе получит кешлинию после этого и кешлиния будет на половину содержать старые данные, а на половину новые для второго ядра, не говоря уж и о других проблемах.
> на развале
Это где?
А твой же дядя тебе говорит - клади на тех, у кого 256оперативы? Говорит - почему он не говорит - клади на тех, у кого 16байта кешлайн? Двойные стандарты и неосилизм с оправданиями. Ваша жаба/сиварпик просто не заведутся там, где 16байтные кешлайны, даже где 32батные.
Все х86 на которых работает твой сишарпик имеют 64байта.
Не бывает такого - в процессоре есть локи и миграция кешлайна там полностью атомарна, ибо в противном случае ты получил бы говно.
Ты же об этом не думаешь? И у тебя всё работает. Вы локаете тупо стрктуры, а что кто-то другой может менять кешлайн и что ваш кешлайн может перейти вообще на другой адрес - вас не интересует - значит вы уже были давно понять, что процессор это умеет делать сам.
>Это где?
Ну сейчас в эру новых технологий - это ебеи и прочии онлайн аукционы и просто впаривалки.
Ебанулся?
>А уж сишарпик 120% .
Моно.
Ты ты про пример ведроида? Который даже со своей жвм, но ито сливается в говно - и все мечтают выкинуть твою жабу.
Ни на одном старом х86 твоя жабагуйня не заведётся - хочешь проверить, берёшь камень 95-го года и запускаешь там жвм. А там, где заведётся - кешлайн 64байта.
На арм"е она беспощадно тормазит и лучше бы её там небыло - это не питух х86, но скоро арм будет 2-м х86. Когда на нём перестанет тормазить жаба - он будет жрать твою батарейку за 8минут и жрать как 8вёдерный бульдозер.
>Моно.
Моно и мигель нен ужны, да и говно.
Можно, конечно, юзать лок-фри структуры, но у них есть свои недостатки.
> Максимум, что могут делать нити - это общий мердж, не более.
Все зависит от задачи... если для твоих целей достаточно раздать задания потокам и смерджить результаты после join'а - я рад за тебя, тебе очень везет с задачами ;)
Яж объяснил - атомарность на х86 в районе 64байт. Спокойно целые структуры можешь хреначить, если с норм выравниванием и не посреди 2-х кешлайнов.
Поиск и вставка - абсалютно атомарные на уровне процессора операции - чтение не надо локать, если тебе надо локать чтение - выкинь свою многохренточность. Вставка тоже атомарна.
Не локфри, а вайтфри. Локфри такой же локнофри, только без мютиксов ОС, либо любой другой ереси. Ну или жабамашины в питух ЯП.
На мувсложении ты можешь словить границы кешлайна, хотя за питухов уже всё выравневает жаба.
или абструктионфри
Меня всегда интересовали подобные. Как они реализуются? Внутри ведь все равно локфри должно быть? Можешь поподробнее?
Тупо некоторые операции могут выполняется без лока, ждёт структура мало - вот и пошло название файтфри, а на самом деле обычнй фри, который лишь немного илитней запилен.
А ты пробовал? ;) Банальный инкремент одного счетчика из нескольких потоков уже барахлит на многоядерке.
Из твоего инкримента получается такая питушня, что просто пичаль. В многоните не катит ваше тухлое фоннеймовское мышление. Не надо его обходить тухлыми локами - надо думать, как можно заюзать эти особенности, но особенностей много и они везде разные - поэтому х86 и питушня и это очень сложно - но меня не интересует это. Вас да, но не меня - поэтому я пилю понтово и я клал на говно.
Я тебе запилю примеры, если не лень будет и успею. Как писать по-пацански.
Я понимаю к чему ты клонишь: если треды вообще не имеют общих данных - это идеальный случай, к которому все стремятся... Но этот идеал достижим только в числодробилках, да и то не всех. Ну и в stateless серверах.
В остальных заедушных случаях какая-то часть данных будет общей, хочешь ты этого или нет. Да, количество этих данных нормальные люди пытаются свести к минимуму, но они есть.
> Я тебе запилю примеры, если не лень будет и успею.
Ну ок, я только за.
Атомарность двух операций совсем не означает, что их комбинация будет атомарной.
Вот самый простой случай - инкремент. Оба треда прочитали значение, увеличили, записали. Да, чтение и запись в отдельности были атомарными, но чьему значению верить? Вот и остается в таких случаях или сводить все к атомарной операции (а кроме сложения и сравнения-с-обменом интел ничего атомарного не умеет) или лепить критическую секция/мутекс/спинлок и забыть о перфомансе.
Никуда они ничего не пишет - кешлайн у тебя будет болтаться в кеше до вытеснения. Значит ваша атомарщина - это тупо обратная миграция кешлайна, чтобы потом о5 прочитать его заного. Есть nt запись и чтение - вот юзайте. Пишет через буфер сразу в оперативу.
Или писать сразу нормально, а не как питухи. Вот как вы питухи запилите сложение 2-х векторов в 2-х нитях? Как животные - возмёте "тредсейф питухвектор" и будите его копировать в 2-х нитях. Будет ли это быстрее - вас не интересует. Зато у нас "многотредность, а ты питух".
Нормальный пацан возмёт поделит вектор на части и сложит. А ещё лучше, пацан итак знает, что это не работает на всё, кроме intel-е, бульдозерах, серверного интела с овер2х канальной капамятью, оптеров и прочего - т.е. того, чего нет у 99% юзверей. А бульдозер тормазит так, что под него что-то писать(работающие с памятью интенсивно) - бесполезно.
А с локами не надо никому верить. С правильно расставленными локами нет конфликтов, защищенный кусок выполняется только одним потоком в каждый момент времени. А плата за локи очень сильно зависит от конкуренции - если они постоянно лезут к локу - работать будет намного хуже чем однопоточка. Если же 10-100 раз в секунду - то лока ты даже не заметишь.
> Есть nt запись и чтение - вот юзайте.
Чем оно мне поможет? Один тред сделал nt load, подумал над тем, что ему делать дальше, сделал nt store. Второй тред в то время пока первый думал, тоже сделал nt load, тоже подумал, сделал nt store. В результате - гейзенбажная питушня с далеко не нулевой вероятностью, даже если "раздумья" заняли всего 1-2 такта.
Если 100раз в секунду, то твой лок не нужен, как и несколько нитей. И да, заметишь. На твоём питух коде - да, не замечу. На своём коде я получу распитушенный конвейер, возможно слитый л1, возможно потерю контекста и в лучше случае пропитушу тысячу тактов.
Да, ты скажешь - 100к тактов - это же жалкий мегагерц - а у меня овер 2ггца. Только вот такого говна у тебя дохрена.
Ваяй примеры, где без локануника - я запилю это без лока. Да мне даже не надо без лока - я тупо запилю на одном вдере перфоманс, который запилет питух минимум 2-х и то в идеальном случае.
Т.е. если в коде практически нет зависимости между тредами (а 100 раз в секунду это практически независимые треды), то треды не нужны? Okay.
> в лучше случае пропитушу тысячу тактов
Да не, емнип, успешное взятие лока стоит в районе 10-100 тактов. Неуспешное - да, грозит сменой контекста со всеми вытекающими.
P.S. Еще в заедушном программировании часто встречаются богомерзкие интерфейсы (например апишки субд), которые не умеют в асинхронность. И тут тред приходится юзать только с той целью, чтобы мой питушиный GUI не вис на время запроса.
Есть какие-то комманды апаратного скидывания кешлайна? Я не шарю в запиле ваших локов.
На интелях, емнип, при удачном взятии мутекса кеши вообще не сбрасываются. А соседние процы узнают о изменении кешлайна по межъядерному протоколу, даже не обращаясь к памяти.
Т.е. удачное взятие мютекса захватывает ИО порты в каждом ведре и резагружает кешлайн из л2? Приэтом он должен смержится с тем кешлайном - т.е. это стопорит всё вёдра, у которых есть данный кешлайн в л1д.
Именно nt запись и чтение это делают - только быстрее, намного быстрее. И я не ошибся.
Вобщем понятно - питушня везде.
В non-temporal, емнип, есть только чтение и запись по-отдельности. Комбинированной херни в духе xadd, xchg или cmpxchg, там никак не сделать. А поэтому они тебе не особо помогут с межпоточным общением.
И да, вот смотри - ты захватил свой питух-мютекс - после него захренчил мемкопи, а потом разлочил. Куда будет писать мемкопи на 100байт? Как 2-е ведро это прочитает - опи мне.
В l1d скорее всего, при таком-то размере.
> Как 2-е ведро это прочитает
Ну не помню я все эти cache-coherency протоколы (MOESI, емнип, на интелях используется, посмотри в доках). Вроде как второе ядро должно выпросить "грязные" строчки кеша, которые задел memcpy у первого.
В мутексе самое главное - не дать работать с неким куском данных двум тредам одновременно (отсюда и его название MUTual EXclusive). Ну и, емнип, на армах, которые в отличие от интеля не умеют в cache-coherency после лока и анлока еще вставляются барьеры, которые сбрасывают кеши.
> Суть не в этом, чтобы делать на этом питух локи.
Да я же не заставляю делать локи на этом... Но ту же очередь, в которую один поток будет пихать элементы, а второй забирать, ты на nt load/store не запилишь.
В этом и суть, и именно к этому царь и ведёт - ибо иквернить скверну можно только полным удалением - ибо накласть кучу рядом со скверной - будет скверна, а построить идеальный замок - будет скверна. Даже если твоя замок будет идеален - все будут видеть лишь скверну вокруг.
Да, что-то в этом есть.
Говорят локфри алгоритмы охрененно параллеляться на виртуальных ядрах (гипертхреадинг) Почти не уступают однопоточному доступу
Как локфри поможет гипертрейдингу я не понимаю. Да и вообще я понимаю под локфри, да и как по теории положено - локи в юзерспейсе. Вайтфри - это именно локи на нужны части, даже не локи, а просто атомарные флаги.
Поясните царю что вы имете ввиду под лок/вайтфри?
Да, но вроде как у них общие кеши первого уровня? Или брешут собаки? Так вот в случае локфри между реальными ядрами - приходится кешлинии перетягивать, что медленно, а случае с виртуальными ядрами, если кеши общие, то не нужно, поэтому это ускоряет. Но это я не исследовал. Только слышал кукареканье где-то в блогах
Это надо продумать код, поглядеть как он там работает. Я лично не представляю, что там это виртуальное ядро будет делать с юзерспейсными локами.
Если для того, чтобы делится данными в обход л2, то я не думаю, что свитч того треда на гипертрейдинг-сосед твоего ведра будет быстрее, чем передать через л2.
Как они описывали профит?
Что это?
> Как они описывали профит?
Они мало того что говорили, что через L2 кешлинию передавать не нужно, но и говорили, что и L1 у виртуальных ядер общий. Мне вот что-то второе утверждение не вериться...