- "Need for Speed - C++ versus Assembly Language" - 7 Updates
- The worm that spreads WanaCrypt0r - 1 Update
| fir <profesor.fir@gmail.com>: May 15 02:29PM -0700 W dniu poniedziałek, 15 maja 2017 22:54:22 UTC+2 użytkownik Chris M. Thomasson napisał: > > in this field) > Wrt fast fractal explorers, assembly on the cpu is very slow compared to > implementing the fractal in a GPU shader. well you compare different hardware - stronger hardware will just win the race as to gpu my estimations (which were more to get a base of thought) was that 'average' gpu is 'roughly' '10 times' stroner than 'average' cpu (esp compare the memory bandwidth of gpu vs the one of cpu) - but i also heard it is esp good in executing organized simple 'code-fibers', when many branches and more complex kernels arise it radically slows down being even able to get below cpu (dont know the details - i was once interested in learning opencl but droped it) |
| Jerry Stuckle <jstucklex@attglobal.net>: May 15 05:50PM -0400 On 5/15/2017 4:43 PM, Gareth Owen wrote: > parallel systems like OpenCL, not assembler. Most of the discussion in > this paper talks about porting the speed-critical sections *from* > Fortran. As I said - I was referring to the GFS and European models. However, HadCM3 is a climate prediction model, not a weather forecasting model. Two entirely different solutions to two entirely different problems. Weather forecasting models don't try to predict more than about 10 days in advance, and try to get very accurate within 3-5 days. Climate prediction models such as HadCM3 are more interested in long-term forecasts. Not to say HadCM3 is not important - it is. But it's not the same. And you can do parallel processing in assembler, also. After all, they all end up as machine language, anyway. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| fir <profesor.fir@gmail.com>: May 15 03:02PM -0700 W dniu poniedziałek, 15 maja 2017 23:10:52 UTC+2 użytkownik fir napisał: > runing gpu from cpu and getting back results > - it seem i can run it in the 1 milisecond > window, so its very fine) i belive that with harder codes it may getting slower, but also belive with better card i may go also better than 7 ms) ps i was also talking that i would like to get such low level management of cores and gpu of gpus buildin in c or improved c (codenamed c2 and lastly renamed to c0), like vram int image_vram[1000][1000]; ram int image[1000][1000]; void genarate_mandelbrot(int* image, int size_x, int size_y) { //... c code for generate mandelbrot } void main() { gpu(1) generate_mandelbrot(image_vram, 1000, 1000); // just call it on gpu wait gpu(1); //wait until gpu finishes vram_to_ram_copy(image, image_vram, 1000*1000*4) save_image("mandelbrot.bmp", image, 1000, 1000); } but thats the other story (in fact in cw i wouldnt need to pass sizes explicitely nor nor use returning on the right size, nor obligatory using ";" also could return any data from program so user just can redirect it to a file like c:\> man.exe (1000,1000) > output.bmp char[] main(int size_x, int size_y) { vram image_in_vram[size_y][size_x] ram image[size_y][size_x] gpu(0) image_in_vram = generate_mandelbrot(size_x, size_y) wait for gpu(0) image = vram_to_ram_copy(image_vram) cpu(0) stack(1) char[] bmp = wrap_array_in_bmp(image); //cpu 0 and stack 1 may be default so no need to explicitely write that ;c return bmp; } idea is to seamles use of gpu hardware and cores (it may look weird but the ideas sre interesting imo, harder may be the language implementation) but thats c0 language digression |
| fir <profesor.fir@gmail.com>: May 15 03:19PM -0700 W dniu wtorek, 16 maja 2017 00:02:56 UTC+2 użytkownik fir napisał: > wait for gpu(0) as to this i could consider also such funny codes like cpu(0) foo() { while( gpu(0) is free ) sleep(0.1); //check if gpu(0) finished in 0.1 ms intervals if(cpu(1) is free) cpu(1) bar(); else if(cpu(2) is free) cpu(2) bar(); else { wait for cpu(1); cpu(1) bar(); } } such funny hand managing of cores (it a bit pissed me of i vannot manage real physical cores instead oof his trashy logical threads in present situation) - though thise while may be more anegdorical use as probably cores can communicate by some signals and not need to do active checking if given core is free //sorry for c0 digression (anyway if that would be really well lightning speed implemented it could be fun) |
| fir <profesor.fir@gmail.com>: May 15 03:38PM -0700 > c:\> man.exe (1000,1000) > output.bmp > char[] main(int size_x, int size_y) > { this point may also seem funny, as it could be seen that in such way one could wrote a pack oc ommandline small c porgrams thtat then can be called from commandline shell close or maybe even exactly as functions in c ;c (which who knows may be maybe good idea) such fractal approach to coding my have even some deeper repercussions maybe (btw the above slightly differs form c anyway as in c code you cant just create named file and fill it with data, though this is a bit to consider 2/too) |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 15 04:00PM -0700 On 5/15/2017 3:02 PM, fir wrote: > return bmp; > } > idea is to seamles use of gpu hardware and cores (it may look weird but the ideas sre interesting imo, harder may be the language implementation) but thats c0 language digression Check this shi% out: http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html Try to get asm on cpu to get similar performance characteristics. |
| fir <profesor.fir@gmail.com>: May 15 04:18PM -0700 W dniu wtorek, 16 maja 2017 01:00:30 UTC+2 użytkownik Chris M. Thomasson napisał: > Check this shi% out: > http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html > Try to get asm on cpu to get similar performance characteristics. why i could try to get the same performance on 10 times weaker hardware? ;c nobody is comparing cpu to gpu here.. maybe only you - i didmnt noticed nobody else what you can do rewrite it from gpu c to gpu asm and tell the dofference - some could be curious of the results ;c (the gpu asm may be some chaos though, im not sure question is if gpu efficiency is so much mrmory bandwidth bound as on cpu - i suspect it may be maybe more asm-bound there and that could mean that programming in asm may be more profitable there, but also not neccessary - it may be bound to code organisation which you could also make in gpu c, then asm would be not so important, yet other side, knowing the details of given gpu (which is related to sam) may be very important that could meen again asm is important - otherwise time of the good coders is so expensive so people would like to buy more hardware instead and so on.. it all needs a lot of expertise to answer ;c i am prersonally for both sides at onece i love both asm and c (c is really good and has so good improvement over assembly but assembly is also very good) (yawn) |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 15 10:32AM -0700 On 5/15/2017 6:33 AM, Cholo Lennon wrote: >> Strange that a virus is not written in assembly language. > Well, nowadays it's very unusual for a virus/malware to be written in > assembler, it has no sense (IMO) Okay. I have not been keeping up. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment