[C] File inlezen regel voor regel met fscanf()

[jvaneijk]

Hoi tweakers,

Ik probeer een file in te lezen regel voor regel. Nu zag ik ergens staan dat dit door middel van fscanf() gaat.

mijn file ziet er zo uit:

code:

0
7
13
18
23
27
30
32
34
35
35
35
36
38
40
43
47
54
60
65
70
74
77
79
81
82
82

iedere regel heeft zijn eigen integer.

nu heb ik in mijn programma de volgende code:

C:

//For debugging reasons, read prefix sums from file.
       FILE *ppsX;
       ppsX = fopen("ppsX.log","r");
       
       FILE *ppsY;
       ppsY = fopen("ppsY.log","r");
       
       FILE *ppsZ;
       ppsZ = fopen("ppsZ.log","r");
       
       for(int j=0; j< Ntotal; j++) {   
        int tempPrint;
        fscanf(ppsX,"%i",&h_offset_x[j]);
        //printf("We're in the loop\n");
        //h_offset_x[i] = tempPrint;
        printf("h_offset_x[%i] = %i\n", h_offset_x[j]);
        fscanf(ppsY,"%i",&h_offset_y[j]);
        fscanf(ppsZ,"%i",&h_offset_z[j]);
       }
       
       fclose(ppsX);
       fclose(ppsY);
       fclose(ppsZ);

echter als ik dit nu draai krijg ik niet zoals ik dacht de waardes die op de regel staan maar hele vreemde waardes.

code:

h_offset_x[0] = 136572760
h_offset_x[7] = 136572764
h_offset_x[13] = 136572768
h_offset_x[18] = 136572772
h_offset_x[23] = 136572776
h_offset_x[27] = 136572780
h_offset_x[30] = 136572784
h_offset_x[32] = 136572788
h_offset_x[34] = 136572792
h_offset_x[35] = 136572796
h_offset_x[35] = 136572800
h_offset_x[35] = 136572804
h_offset_x[36] = 136572808

Ik heb al van alles geprobeerd maar niets lijkt te werken. Ik doe ergens iets fout maar zie niet in wat.

[jvaneijk]

Oke na ong 2 dagen lang zoeken ben ik er deels uit nu ik het hier post zie ik het in een oogopslag staan.

de printf() doe ik niet helemaal goed. nu print hij wel netjes de goede waardes.

[.oisyn]

Duh, kijk nog eens goed naar je printf regel.
.edit: dat zeg ik

Als je overigens gewoon een debugger had gebruikt had je het al meteen gezien.

[ Voor 56% gewijzigd door .oisyn op 29-11-2007 14:16 ]

[jvaneijk]

.oisyn schreef op donderdag 29 november 2007 @ 14:15:
Duh, kijk nog eens goed naar je printf regel.
.edit: dat zeg ik

Als je overigens gewoon een debugger had gebruikt had je het al meteen gezien.

Ik weet dat als ik een debugger had gebruikt ik het gewoon had kunnen zien. Maar dat is het hem juist. Ik kan geen debugger gebruiken. Niet omdat ik het zelf niet snap maar omdat ik bezig ben met programmeren op de grafische kaart. En daar geen debugger voor is Dus als jij voor mij een debugger hebt voor de grafische kaart wat kan werken met nVidia CUDA dan hoor ik het graag van je

[.oisyn]

Ten eerste draait die fscanf/fprintf kak niet op de grafische kaart, dus daarvoor kun je gewoon de debugger gebruiken die bij je compiler hoort. Ten tweede zou je natuurlijk ook gewoon je probleem kunnen isoleren (dat stukje wat je hier gepost hebt dus) en dat als een normaal CPU project kunnen compileren én debuggen.

Daarnaast lees ik op het forum ook gewoon berichten over het daadwerkelijk debuggen van GPGPU code: http://forums.nvidia.com/index.php?showtopic=50357

[jvaneijk]

.oisyn schreef op donderdag 29 november 2007 @ 16:08:
Ten eerste draait die fscanf/fprintf kak niet op de grafische kaart, dus daarvoor kun je gewoon de debugger gebruiken die bij je compiler hoort. Ten tweede zou je natuurlijk ook gewoon je probleem kunnen isoleren (dat stukje wat je hier gepost hebt dus) en dat als een normaal CPU project kunnen compileren én debuggen.

Daarnaast lees ik op het forum ook gewoon berichten over het daadwerkelijk debuggen van GPGPU code: http://forums.nvidia.com/index.php?showtopic=50357

Voordat je van alles begint te schreeuwen moet je eerst goed kijken. Want zolang je niet je programma in device emulation draait kan je helemaal niets debuggen en als je het wel in device emulation draait dan werkt de rest niet.

Aangezien ik het totaal plaatje moet hebben kan ik dus niet debuggen en uit elkaar trekken helpt ook niet want dan heb ik het totaalplaatje niet meer. Om aan te geven. de compiler is geen standaard gcc maar nvcc. en de files zijn dan ook geen .C maar .cu

[.oisyn]

jvaneijk schreef op donderdag 29 november 2007 @ 16:18:
[...]

Voordat je van alles begint te schreeuwen

Rare definitie van schreeuwen heb jij . En misschien moet je zelf beter kijken?

quote: http://developer.download...Programming_Guide_1.0.pdf

nvcc is a compiler driver that simplifies the process of compiling CUDA code: It provides simple and familiar command line options and executes them by invoking the collection of tools that implement the different compilation stages.

nvcc’s basic workflow consists in separating device code from host code and compiling the device code into a binary form or cubin object. The generated host code is output either as C code that is left to be compiled using another tool or as object code directly by invoking the host compiler during the last compilation stage.

Wat nvcc doet is gewoon de sourcefile inlezen en die opdelen in een CPU en een GPU deel. Dat CPU deel kun je vervolgens gewoon met je favo compiler compileren zodat je het kunt debuggen.

Aangezien ik het totaal plaatje moet hebben kan ik dus niet debuggen en uit elkaar trekken helpt ook niet want dan heb ik het totaalplaatje niet meer.

Debuggen doe je ook niet door naar het geheel te kijken, maar juist naar afgebakende stukken. Blijkbaar had je je probleem al dermate afgebakend dat het fout ging bij het lezen en schrijven naar een file. Die code runt natuurlijk prima op een CPU en had je dus in feite gewoon kunnen copy/pasten naar een klein miniprojectje zodat je het kunt testen. Het is niet zo heel raar om gewoon op een ander platform dan je target een proof of concept te maken als je op je target platform nogal gelimiteerd bent in het testen en debuggen.

[jvaneijk]

Dat is nou juist het probleem. Om alles met elkaar te laten werken en zeker van te zijn dat het goed gaat moet je alles in een keer runnen. Als je het runt op de GPU ook al doet hij CPU + GPU code seperaten. kan je geen gebruik maken van printf dus moet je er vanuit gaan dat je uitkomst maar goed is.

Over het algemeen ligt het programmeen niet zo voor de hand op de GPU, helaas ook niet het CPU gedeelte wat de GPU code aanroept.

[ Voor 18% gewijzigd door jvaneijk op 29-11-2007 16:41 ]

[.oisyn]

jvaneijk schreef op donderdag 29 november 2007 @ 16:40:
Over het algemeen ligt het programmeen niet zo voor de hand op de GPU

I know, 't is m'n werk .

Van CUDA heb ik niet zo heel veel kaas gegeten, maar daadwerkelijk de shaders debuggen (wat met CUDA ongetwijfeld lastiger is aangezien de link tussen originele code en uiteindelijke shaders een stuk vager is) lukt aardig met tools als PIX en NvPerfHud. Goed, dat heeft natuurlijk allemaal te maken met graphics, maar die laatste tool is wel van nVidia en is vrij uitgebreid. Ik vind het dus op z'n zachtst gezegd een beetje krom dat ze niet ook fatsoenlijke tools voor hun eigen CUDA systeem kunnen maken

[jvaneijk]

.oisyn schreef op donderdag 29 november 2007 @ 16:54:
[...]

I know, 't is m'n werk .

Van CUDA heb ik niet zo heel veel kaas gegeten, maar daadwerkelijk de shaders debuggen (wat met CUDA ongetwijfeld lastiger is aangezien de link tussen originele code en uiteindelijke shaders een stuk vager is) lukt aardig met tools als PIX en NvPerfHud. Goed, dat heeft natuurlijk allemaal te maken met graphics, maar die laatste tool is wel van nVidia en is vrij uitgebreid. Ik vind het dus op z'n zachtst gezegd een beetje krom dat ze niet ook fatsoenlijke tools voor hun eigen CUDA systeem kunnen maken

Ja idd. Alleen is het probleem dan ook weer dat ik onder Linux draai en ik dus geen gebruik kan maken van NvPerfHud en totaal niets doe met graphics. PIX weet ik zelf niets over. Maar zal het morgen eens uitzoeken. Ga nu lekker naar huis.

[.oisyn]

PIX is een Direct3D ding, dus daar ga je niet heel veel aan hebben onder linux

[phobosdeimos]

Wat is er zo moeilijk aan om dit stukje gewoon te compileren en debuggen met respectievelijk gcc en gdb?

[jvaneijk]

phobosdeimos schreef op donderdag 29 november 2007 @ 18:15:
Wat is er zo moeilijk aan om dit stukje gewoon te compileren en debuggen met respectievelijk gcc en gdb?

Als je bovenstaande berichten leest dan zal je misschien snappen waarom dat niet zomaar gaat.

[phobosdeimos]

jvaneijk schreef op vrijdag 30 november 2007 @ 09:19:
[...]


Als je bovenstaande berichten leest dan zal je misschien snappen waarom dat niet zomaar gaat.

Daar hoef ik bovenstaande berichten niet voor te lezen.
Als je de code die jij hier gepost hebt omsluit met een int main() etcetera, dan kan je die makkelijk apart compileren en debuggen met gcc en gdb.
Die code heeft niks met cuda of GPU te maken.

[jvaneijk]

Nee maar ik moet zoals ik hierboven al aangaf het in het grote geheel zien. Want inlezen van files lukt me wel. Das geen probleem. Maar het dan ook nog laten werken met de GPU dan wel in emulation mode of niet, das een ander verhaal.

[farlane]

De fout die je in deze code had zitten zal op geen enkel platform werken, dus je emulation mode / GPU probleem bestaat helemaal niet.

[jvaneijk]

farlane schreef op zaterdag 01 december 2007 @ 13:09:
De fout die je in deze code had zitten zal op geen enkel platform werken, dus je emulation mode / GPU probleem bestaat helemaal niet.

Niet volledig mee eens, Hij werkte namelijk gewoon. Zoals je kan zien was de uitvoer vrij normaal. Enige probleem wat optrad is dat ik een stukje geehugen naar buiten schreef. Dat gaf die inmens hoge waardes. Maar op FC 6 werkt het gewoon.

[farlane]

jvaneijk schreef op maandag 03 december 2007 @ 09:40:
[...]
Niet volledig mee eens, Hij werkte namelijk gewoon. Zoals je kan zien was de uitvoer vrij normaal. Enige probleem wat optrad is dat ik een stukje geehugen naar buiten schreef. Dat gaf die inmens hoge waardes. Maar op FC 6 werkt het gewoon.

Ik zie eerlijk gezegd niet hoe dat goed had kunnen werken, dan moet net op die plek op je stack de gevraagde variabele staan.

Kreeg je eigenlijk geen warnings over het aantal parameters naar printf?