Inlägg

Jag använder sugfunktionen för att dra ut dammet i motsatt riktning som det kom in. Blåser man är min teori att man i vissa lägen kilar fast dammet hårdare. Det dammar inte heller så mycket när man suger bort det som när man blåser omkring det "Rätt" eller "fel" det funkar för mig.

Handtag och slang är helt i plast men håller ändå en hand på chassit för att motverka statisk elektricitet.

Jag vill opponera mig mot ett av de fösta inläggen här som säger att IO är ett problem för x86-baserade system. Det kan vara ett problem om applikationerna som körs producerar mycket omfångsrikt data som ska skickas. Detta sker som bekant vid användning av XML/SOAP (haha skojade bara, få NET-utvecklare verkar känna till att SOAP är oerhört IO-krävande). XML/SOAP är också oerhört CPU-krävande och då främst vid avtolkning av SOAP-strängen, mindre vid skapandet av strängen.

Dagens serverapplikationer lider av samma problem som så gott som alla serverapplikationer alltid gjort: det läggs för mycket funktionalitet på servern (eftersom det är mer komplicerat att lägga det i klienten) som därmed tappar en stor del av sin förmåga. Varför skicka en fråga i SOAP-format om det är mycket krävande att fastställa vad det är som klienten egentligen vill ha gjort? Har man inte så bråttom kan man konstruera binärfrågor som säger anropa funktionen vars numeriska värde finns i den binära frågans byte 2 (eller 5 eller någon annanstans). Hur mycket jobb är det? För mycket uppenbarligen.

Låt också bli att ställa komplicerade SQL-frågor där femtisjutton tabeller blir indragna för att ett "rent" svar ska kunna levereras sorterat till klienten. Skicka allt och låt klienten sålla bort ovidkommande för att sedan sortera.

Centrala resurser som servrar har inte tid att göra jobb som lokala resureser lika gärna kan utföra.

IO är inte probemet, utvecklarna är det.

Utan att ha arbetat med det tycker jag det är lite konstigt att du inte kommer åt AD via VB. Det du kan göra i C, C++ ska du kunna göra i VB. Det borde egentligen bara vara en frågan om att du har rätt (administratör) behörighet.

C i all ära men ska du ha interaktivitet (knappar, menyer, inmatningsfält) blir det mycket otympligt. Då föreslår jag ett "produktivt" språk som C#.

Om du däremot arbetar mot AD i batchmiljö (kommandorad) med enstaka parametrar tror jag C kan vara enklare. Men då får du sätta dig in i programmering genom deklarationer dvs att du bygger upp strukturer med data som ditt batchprogram kör igenom på ett generellt sätt, annars blir det bökigt.

Hoppas jag bidrog till att lösa ditt dilemma.

Det du beskriver är det jag stötte på. Men jag hade en processor med flera kärnor. Det fanns två problem: det ena att jag delade upp jobben jämnt (istället för i stycken som var multiplar av cachelinjerna) så att trådarna började slåss om samma cachelinje. Det andra att jag utförde en omgång sorteringar (x[i] med x[i+k] med x[i+2k] ...) istället för cachelinjevis (x[i] med x[i+k], x[i+1] med x[i+k+1] för att sedan gå vidare (x[i+k] med x[i+2k] ...) när linjerna uttömts.

Ha! Fick just en idé jag ska pröva!

Mina kunskaper har inte varit surt förvärvade, jag har haft roligt nästan hela tiden.

Om jag hade arbetat på Google och försökt lagra hela internet hade jag inte heller valt Shellsort, problemet var av begränsad omfattning som jag skrivit.

Ja, parallell algoritmteori är rimligen svårare än seriell. Det finns dessutom en extra knorr och det är att den helst ska vara effektiv på flera kärnor vilket för in ett praktiskt moment i det hela.

Från Wikipedia:

"Sorting algorithm
... Main article: Shell sort ...
... Although this method is inefficient for large data sets, it is one of the fastest algorithms for sorting small numbers of elements."

Givet att Wikipedia inte alltid har rätt, vad är problemet? Jag vill minnas att jag nämnde att det handlade om ett RAM-baserat data set (dvs begränsad storlek), dessutom hade jag begränsat med tid.

"Den råkar ge bra prestanda för små indata (1 miljon tal - jag vill minnas att jag skrev poster, det är liksom mera verklighet då) ..." för att den råkar vara en av de bästa algoritmerna för de förutsättningarna sedan den uppfanns (50 år sedan). Den står dessutom "i böckerna." Om jag hade försökt teoretisera fram en egen sorteringsalgoritm som är bättre än de som finns "i böckerna" hade man inte behövt vänta "bra många år på svaret (på sorteringen)," man hade inte haft någon algoritm överhuvudtaget! Jag är som du förstår varken Donald Shell eller Tony Hoare eller saddam och jag har aldrig trott det heller.

"... så det gick bra i alla fall." Jag vet att det var rena rama slumpen att jag lyckades göra en (tror jag) snabb implementation av den, kanske alldeles särskilt utifrån mitt förfarande att "tuta och köra." Hur visste du det? Kan du göra dig osynlig så att du suttit bredvid mig och sett hur jag gjort? Mycket kusligt.

Men om jag verkligen inte hade försökt göra en parallell version av Shellsort vilken algoritm borde jag verkligen ha försökt göra en parallell implementation av? Alla de riktigt vassa implementationerna av algoritmer och - gissar jag - även de vassaste algoritmerna är hemliga dvs NSA sitter på dem eller IBM eller någon annan.

Just det, frågan: vilken algoritm borde jag verkligen ha försökt göra en parallell version av givet förutsättningarna (du som vet menar jag)?

... tycker jag att det finns två sätt att se det. Tycker du programmering och hårdvara är kul ska du fundera på att välja ett språk med lägre nivå. C är ett bra ställe att börja. Jag började själv med Basic sedan Fortran och sedan assembler. Sedan blev det PL/M och assembler igen. Sedan 20 år tillbaka är det mest C men assemblern har jag stor nytta av i t ex debugging och för att interfacea mina C-program mot speciell CPU-funktionalitet som t ex blockinstruktionerna. Jag arbetar både mot IT-branschen och mot inbyggda system.

Tycker du hårdvara är jobbigt så välj ett språk som är lite längre bort som t ex C# och Java.

Sedan 10 år kan jag inte längre skriva assemblerkod som är snabbare än vad min kompilator (OpenWatcom) kan generera :(. Däremot tror jag att jag vet jag hur jag ska uttrycka mig i C för att kompilatorn ska kunna göra snabbast möjliga assemblerkod av det :). Med detta sagt menar jag inte att jag skriver program som inte går att förstå eller underhålla.

Det är lättare att bli riktigt duktig i C än i C++. Jag kan ärligt säga att jag bara träffat en riktig superstar i C++, samma sak i C (tyvärr inte jag ). Men steget under är det betydligt mer tunnsått på C++ folk.

À propos algoritm kontra programmeringsteknik. För ett tag sedan skulle jag implementera en multitrådad RAM-baserad sorteringsalgoritm som skulle exekvera på ett multikärnesystem. Jag fann, ev felaktigt, att en Shell-sort skulle vara lättare att implementera än en Quick-sort. I enkeltrådad form är det inte jättestor skillnad i prestanda mellan dem, några tiotals procent.

Mitt testdata bestod av en miljon unika poster sorterade i stigande ordning. Testet var att sortera den (logiskt, med index) i fallande ordning alltså sista posten ska vara först och tvärtom.

Sagt och gjort. Jag började med att dela upp Shell-sorten så att varje kärna sköter en del av arbetet. Körde med tidtagning och vad fann jag? Att den multitrådade versionen behövde 32% längre tid att exekvera än den enkeltrådade.

Eftersom jag inte gärna ville tro att en multitrådad Shell-sort inte kunde vara snabbare än en enkeltrådad började jag analysera. Det visade sig att ett problem hade med sorteringstatistiken att göra: trådarna krockade när de skulle inkrementera samma statistikvariabler (ncompares och nswaps). En annan sak var att jobben som fördelades ut till resp tråd inte var cacheanpassade och dessutom på två olika sätt.

Jag har nu en snabb Shell-sort som blir snabbare ända upp till tre samtidiga trådar, sedan blir den långsammare igen. På en Core 2 Quad Q9300 och tre trådar sorterar den en miljon poster på 0,7 sekunder vilket jag är nöjd med.

Vad vill jag säga med detta? Jo hade jag inte varit intresserad och kunnig i assembler, hårdvara och prestanda hade jag inte vetat var jag skulle börja angripa multitrådningsproblematiken. Att sorteringstatistiken var en bov i sammanhanget var en riktig slamkrypare.

Bara för att man har en bra algoritm att utgå ifrån betyder det inte att vem som helst kan göra en kompetent implementation av den. Det omvända är också sant: det går att göra programmeringstekniskt och prestandamässigt mycket kompetenta implementationer av dåliga algoritmer. Vitsen är att göra en kanonimplementation av en bra algoritm.

Så gosh, var du än är, så har du mer rätt än du får credit för.

Personligen tycker jag följande:

1. Backa upp det du vill behålla på en annan disk
2 Gör en enda stor partition av disken och installera XP från scratch

Behåll XP, det är mindre resurskrävande än 7.

Det här med att ha C och D på samma disk men olika partitioner är jag av egen erfarenhet skeptisk till. På något sätt lyckas alltid den ena bli för stor och den andra för liten. Med en enda partition blir det inte så. Tror dessutom att D blir trögare eftersom den börjar en bit in på disken.

Din dator har säkert många år kvar att leva. Sen kanske du inte kan köra vissa spel - fast det kanske är viktigt?

Jag kör Avira Antivir gratis virusskydd som jag tycker fungerar bra utan att dra för mycket kräm.