From: Ryan McGovern Date: 2006-07-15T00:27:56+09:00 Subject: Re: How to speed up ruby and make it as fast as possible "I find this answer to be unsatisfactory. I do not know C and neither do many others who like Ruby but want better performance. The knowledge and syntax demands of programming in Ruby and C are worlds apart. It is not much different than telling someone to go code in (modern) Assembler! " Assembler is not that bad either, imho once you've learned how to program beyond just a specific language picking up another one is not that challenging. And i agree learn c it's at the very least good for very speed important tasks, or interfacing directly with the os or writing ruby modules to do said interfacing. I mean try to beat this thing in speed *need an x86 compiler* .model small .stack 100h .386 Bufsize= 800 bsize=800 .data ten DD 10 FACT DD Bufsize DUP(0) INDEX dd 0 MULTI DD 0 LEN DD 1 .code main proc far mov ax,@data mov ds,ax mov ah,62h int 21h mov es,bx mov eax,0 mov ebx,081h movzx ecx,BYTE PTR es:[80h] L4: mul ten movzx edx,BYTE PTR es:[ebx] and edx,000000fh add eax,edx inc ebx loop L4 ;put code here MOV ESI,OFFSET FACT MOV [ESI],EAX DEC EAX MOV ECX,EAX CMP ECX,0 JE PEAX Fac1: MOV EBX,0 MOV ESI,OFFSET FACT MOV INDEX,0 Fac2: MOV EAX,[ESI] ;MOV FACT INTO EAX MUL ECX ;MUL BY COUNT ADD EAX,EBX ;ADD CONTENTS OF EBX TO ECX JNC Fac3 ;NO CARRY => JUMP L3 INC EDX ;OTHERWISE INC EDX Fac3: MOV EBX,EDX ;MOV CONTENT OF EDX TO EBX MOV [ESI],EAX ;STORE MUL RESULT IN CURRENT ESI POS INC INDEX MOV EAX,INDEX CMP LEN,EAX ;COMPARE LEN, INDEX JNE Fac5 ;NOT EQUAL => JUMP L2 CMP EBX,0 ;COMPARE FOR CARRY AFTER ADD ECX,EBX JZ Fac4 ;NO CARRY => JUMP L4 INC LEN ;INC LEN ADD ESI,4 MOV [ESI],EBX JMP Fac4 Fac5: ADD ESI,4 JMP Fac2 Fac4: LOOP Fac1 mov INDEX,0 mov ESI,OFFSET FACT MK1: mov eax,[esi] push eax inc INDEX add esi,4 mov ecx,INDEX cmp ecx, LEN jnz MK1 ;end code PEAX: pop eax mov ebx,eax mov ecx,8 cmp INDEX,0 jz I1 L9: L3: mov edx,0f0000000h and edx,ebx push ecx mov cl,28 shr edx,cl pop ecx mov ah,02h cmp dl,10 jb L1 add dl,37h jmp L2 L1: or dl,30h L2: int 21h shl ebx,1 shl ebx,1 shl ebx,1 shl ebx,1 loop L3 dec INDEX cmp INDEX,0 jnz PEAX mov ah,4ch int 21h I1: inc INDEX jmp L9 main endp end main Kent Sibilev wrote: > I find this attitude is quite amazing. We all know that Ruby is not a > best language in terms of performance. Even if we had Ruby 2.0 (YARV) > delivered to us, Ruby's performance would still be a way behind those > strong typed languges like ocaml or java. If you want to keep using > Ruby, but sometimes you need a raw performance, you should learn C. > It's not that bad, you know. If you always need a raw performance, > then probably you are not using right tool for the job. > > just my 2 cents. > > On 7/14/06, Jamal Mazrui wrote: >> -----Original Message----- >> From: list-bounce@example.com [mailto:list-bounce@example.com] On Behalf >> Of Reggie Mr >> Sent: Friday, July 14, 2006 6:56 AM >> >> > Write it C. >> >> I find this answer to be unsatisfactory. I do not know C and neither do >> many others who like Ruby but want better performance. The knowledge >> and syntax demands of programming in Ruby and C are worlds apart. It is >> not much different than telling someone to go code in (modern) >> Assembler! >> >> I think the more that Rubyists acknowledge and try to directly solve the >> language's performance hindrance rather than rationalizing it away, the >> better the prospects for the success of our beloved language. Of >> course, better algorithms can produce better performance, but that >> argument is also true for the languages with which Ruby compares >> unfavorably in performance. Please do not claim that Ruby's adoption by >> others is irrelevant: a good idea is worth spreading, and the more >> users, the better library support and learning resources available to us >> all. >> Also, please do not tell me to rewrite Ruby, myself, if I care about >> performance. As stated, I do not know C or have the interest and time >> to devote to such an undertaking. I do promote Ruby to friends and >> colleagues in ways that I can. We should be able to have a legitimate >> desire for language improvements without being characterized as >> ignoramuses, nay-sayers or lazy spectators. >> >> Regards, >> Jamal >> >> > >