1. Euphoria is 3 to 30 times faster than DJGPP! (warning! C code
- Posted by Jack Cat <catjackus at yahoo.com> Jan 08, 2001
- 637 views
- Last edited Jan 09, 2001
I running a NEIL-based app and found it kinda slow. It sed NEIL's pixel() to flood fill the screen. I decided to benchmark NEIL's pixel() and found out it did a few thousand pixels per second in 640*480*16. I then ran TEST.EXE wich comes with Allegro for DJGPP and found out Allegro's pixel() routine drew tens of thousands of pixels per second. I thought: "Hell! Another major defeat for Euphoria...". But later on in the evening, I came accross a site promoting "the fastest way to draw to the screen in mode 19 using DJGPP". I looked at the sample program, and translated it to Euphoria by hand. And guess what? Interpretted Euphoria is THREE TIMES FASTER THAN COMPILED DJGPP C! That is, I compiled it with "gcc -o pix.exe pix.c", wich means no optimisations, but neighter does the interpreter, so... But it gets even better! When I translated this Euphoria program to C using EC.EXE, and compiled it with DJGPP, it was...hold on.. THIRTY TIMES FASTER THAN C!!! Don't believe me? Go ahead! Try it out! Here are the two benchmark programs written in C, and in Euphoria, and they are identical in every way. -------------------Begin C Code "pix.c"--------------- #include <dpmi.h> #include <stdio.h> #include <time.h> #include <go32.h> #include <sys/farptr.h> void set_mode_13h() { __dpmi_regs r; r.x.ax = 0x13; __dpmi_int(0x10, &r); } void putpixel(int x,int y,int color) { _farpokeb(_dos_ds, 0xA0000+y*320+x, color); } void return_to_text_mode() { __dpmi_regs r; r.x.ax = 3; __dpmi_int(0x10, &r); } void main() { int t,cnt; set_mode_13h(); t = time(NULL); while((t+10) >= time(NULL)) { putpixel(10,10,20); cnt++; } return_to_text_mode(); printf("%d Pixels Per Second",cnt/10); } ------------------Begin Euphoria Code "pix.ex"--------- include machine.e include graphics.e include get.e procedure putpixel(integer x,integer y,integer c) poke(#A0000+y*320+x,c) end procedure integer cnt atom t cnt = 0 if graphics_mode(19) then end if t = time() while t+10 >= time() do putpixel(10,10,20) cnt+=1 end while printf(1,"%d Pixels Per Second",floor(cnt/10)) if wait_key() then end if ------------------------------------------------------- Go ahead, copy and paste these sources into files, and run pix.ex with Euphoria, and pix.c with DJGPP by typing "gcc -o pix.exe pix.c" on the command line. And see for yourself. Then, translate pix.ex to C using EC.EXE and compile it with DJGPP. The speed increased 20 fold. Am I doing something wrong here, or are these benchmarks correct? If they are, I see no reason why Rob can't put "Euphoria is 3 to 30 times faster than DJGPP in mode 13h!" on his site. Sure DJGPP is better at math and all, but using the Euphoria translator, this difference is not so big (when using integer math there is no difference). Now let's just get some more features in it and increase flow control speed a little, and we have the perfect language. Mike The Spike __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/
2. Re: Euphoria is 3 to 30 times faster than DJGPP! (warning! C code
- Posted by Euman <euman at BELLSOUTH.NET> Jan 09, 2001
- 531 views
Mode 13 is so outdated, who still uses this for games or graphics? I tried to use some old stuff that Pete Eberlein wrote to get faster graphics. maybe this only works well with Euphoria 1.5 prior, I'm not sure. modified for 1024x768 </snip> global integer bank_start sequence regs, dummy integer bytes_per_line, bank_granularity bytes_per_line = 1024 bank_granularity = 65536 regs = repeat(0, 10) regs[REG_AX] = #4F05 regs[REG_BX] = #0000 global procedure pixel(object data, sequence p) integer offset, len len = length(data) offset = p[2] * bytes_per_line + p[1] if offset < bank_start or offset + len > bank_start + 65536 then regs[REG_DX] = floor(offset / bank_granularity) dummy = dos_interrupt(#10, regs) bank_start = regs[REG_DX] * bank_granularity end if poke(#A0000 + offset - bank_start, data) end procedure global function get_pixel(sequence p) integer offset offset = p[2] * bytes_per_line + p[1] if offset < bank_start or offset + p[3] > bank_start + 65536 then regs[REG_DX] = floor(offset / bank_granularity) dummy = dos_interrupt(#10, regs) bank_start = regs[REG_DX] * bank_granularity end if return peek({#A0000 + offset - bank_start, p[3]}) end function <snip\> I couldnt figure out why the top half of the screen when useing mouse routines\ made the mouse do strange things. Even Mighty with it's redefined pixel / getpixel had the same effects. NEIL (ha) Only one of the examples will run on either of my machines because I like the rest of the potential customers in the world dont run a supercharged \ system i.e Fancy Graphics Card. I also found VESA.E that (ha) doesnt like certain modes either so, I gave up on that too. I wish I had a dime for every scratch of my head that I tried to get fast graphics in Dos under Euphoria and am delighted now that the DJGPP translator uses Allegro and can achieve by a factor of 6 (per Robert) faster screen writes than the Watcom graphics lib. I'm finally happy. eum