Avatar billede tommya Nybegynder
10. maj 2006 - 22:13 Der er 9 kommentarer og
1 løsning

signed long problem

Jeg er pt. igang med at udvikle et skakspil i Java (ja jeg ved sproget langt fra er optimalt til det, men er nødsaget til at bruge det). Hastighed er altafgørende og derfor bruger jeg så vidt muligt primitive typer... Til at repræsentere boardet bruger jeg 12 bitboards alle af typen long da dette lige præcis passer med 64 bit (antal felter).

Der er dog det problem at når jeg opretter boardsne og sætter MSB til til 1 så bliver tallet negativt (da long selvf. er signed) og dette har betydning de andre bits i variablen, jeg benytter meget bitshifting, and, or osv. med bitwise operander. Så vidt jeg kan se er det et overflow der er skyld i det.

Det undre mig da det ikke burde ske med simpel bitshifting at hele variablen vendes (grundet 2 complementær signed notation). Når man slår problemet op på nettet er løsningen at bruge en datatype der er nummeret større, problemet er at jeg allerede bruger long, og ønsker at benytte primitive typer.

Hvis der er nogen der har en løsning på denne, en af javas mange short commings. Ville jeg blive utrolig glad.
Avatar billede arne_v Ekspert
10. maj 2006 - 22:29 #1
nu kan jeg ikke se hvorfor Java ikke skulle vaere lige saa godt som
ethvert andet sprog til et skak spil

det er vel ikke specielt hardware/OS naert

Java har ikke unsigned data typer (stor fejl efter min mening), men til
dit formaal kan du vel bruge et array

det er vel ioevrigt hurtigere (men bruger 8 gange saa meget memory) at bruge
bytes fremfor bits
Avatar billede pidgeot Nybegynder
10. maj 2006 - 22:31 #2
Hvorfor ikke et byte-array, om man må spørge? Det fylder mindre i hukommelsen, og jeg tvivler stærkt på der er mere end en minimal forskel i hastigheden. Det tager jo også noget tid at lave ANDs, ORs og shifts...
Avatar billede pidgeot Nybegynder
10. maj 2006 - 22:32 #3
Det var det med at opdatere inden man poster en kommentar... >.>
Avatar billede tommya Nybegynder
10. maj 2006 - 22:45 #4
Java er ikke godt til skak spil med en AI modstander da det er langsommere end sprog med lavere abstraktions niveau. Man har langt flere muligheder for at lave hastigheds relaterede tweaks i sprog som f.eks. C hvor man jo kan gejle koden helt ind til benet. Men det er en helt anden sag end denne. :)

Jeg giver dig helt ret Arne det er en stor fejl at undlade unsigned datatyper, men det kan vi jo ikke ændre på nu.

Grunden til at jeg bruger bitboards er at man med bitshifting har mange (og hurtige) muligheder for at ændre flere områder på boardet på en gang. Og lave "simpel" og nemme movegenerators osv. Inspiration fundet fra denne side: http://www.onjava.com/pub/a/onjava/2005/02/02/bitsets.html?page=2

Bytes er hurtigere til enkelte modifikationer, men når jeg kan redigere en hel række på en gang i bitboards, tror jeg ikke det kan følge med, desuden kan jeg ikke or'e byte arrays sammen på samme måde for at finde lovlige træk.
Avatar billede tommya Nybegynder
11. maj 2006 - 12:50 #5
Fandt problemet, og det var simpelt nok et manglende L efter tallet der blev bitshiftet ind. Så jeg istedet bitshiftede end integer ind i long, og derfor ændrede bits sig der ikke skulle. Jeg takker mange gange for diskussionen :D
Avatar billede arne_v Ekspert
12. maj 2006 - 02:24 #6
Der er ikke nogen logik som siger at et sprog med høj abstraktions niveau
er langsommere.

Med compilere af idag er det ofte ikke tilfældet.
Avatar billede tommya Nybegynder
12. maj 2006 - 19:01 #7
Må være min fejl så, men ved Java har man da ikke en Java Virtuel Maskine som ligger mellem java bytecode og så den kode der skal fortolkes af processoren?
Avatar billede arne_v Ekspert
12. maj 2006 - 19:12 #8
De foerste JVM (midten af 90'erne) var rene fortolkere som fortolkede Java byte kode
og den fortolkning gav er enormt overhead sammenlignet med native executables.

JVM idag har indbygget JIT compilere som faktisk compiler Java byte koden
til native kode (hvor den finder det hensigsmaessigt).

Du kan lidt hen af vejen betragte javac som en simpel preprocessing fra
text format til binaeret format og java som en kombineret compiler
og executer.

Konsekvense er at rent eksekveringsmaessigt er Java meget hurtigt idag
(mine eksperimenter antyder at nyere JVM's er stort set ligesaa hurtige
som de bedste kommercielle compilere og faktisk hurtigere end GCC).

Java's stoerste performance problem idag er opstartstiden (fordi man compiler
naar man koerer).

Og daarlige realtime egenskaber (GC goer svar tider meget uforudsigelige).

Det bedste bevis paa VM konceptets holdbarhed er nok at Microsoft har valgt
det samme med .NET !
Avatar billede tommya Nybegynder
12. maj 2006 - 20:17 #9
Ganske interessant faktisk.

Ser man på denne side http://dada.perl.it/shootout/ så ligger java ellers forholdsvis sikkert placeret i midten af skalaen, hvad angår cpu tid, men dårligere hvad angår hukommelses forbrug. Men dette afhænger selvfølgelig også af de funktioner man bruger til at benchmarke koden.
Avatar billede arne_v Ekspert
12. maj 2006 - 20:34 #10
Det afhaenger af hvad man tester.

Men resultaterne ser nu ret fornuftige ud.

Der er visse ting i Java som bruger meget memory. Men det er svaert at sammenligne
GC sprog med ikke GC sprog. I et ikke GC sprog frigives memory kontinuerligt.
I et GC sprog frigives memory foerst naa VM synes at det er noedvendigt d.v.s.
at GC sprog har en naturlig tendens til at bruge al den memory som er
til raadighed i VM.

Men J2SE er ikke et godt valg til systemer med meget lidt memory. Saa skal man
over i J2ME.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester