Just wondering, can you give me any reasons to try out asm from vb?
ive read some stuff here and dont really understand..there should be a big tutorial somewhere..i know there must :bigyello:
Printable View
Just wondering, can you give me any reasons to try out asm from vb?
ive read some stuff here and dont really understand..there should be a big tutorial somewhere..i know there must :bigyello:
only for the speed in which it executes. asm is the fastest way to execute code. the drawback is that it is machine specific. VB will run on most every PC, while asm is processor specific. You would want to write something in Asm to learn it. Then go about writing code to replace VB code, I think.
I started out learning BAL (Basic Assembler Language) on the IBM Mainframe, about 25 years ago.
When you say try out asm from vb, what exactly do you mean? If you're asking do you think learning ASM is useful for a visual basic programmer, then the answer is yes. If you're asking if visual basic supports inline asm, the answer is no. You have to write dll files and call it from visual basic. Only C++ supports inline asm atm.Quote:
Originally Posted by |2eM!x
I started to write a very long post but instead I'll shorten it to this. If you are interested in learning the secrets of a computer then you should definitly learn asm. If you would rather live in a programming world where everything happens magically behind the scenes then live on my brother. In a nutshell, if you are going to take programming seriously then you need to know asm else there should be no need to learn it.
Actually asm isn't faster then visual basic but can be made faster. If you wrote the same exact thing as the visual basic code generator then you would produce in theory the same exe file.Quote:
Originally Posted by dglienna
ASM can run every where that a visual basic program can run plus more as you can alter asm source and run on linux and other software platforms. Visual basic generates x86 instructions and is most definitly tied to windows forever. A lot of people get confused about asm because the word "Processor Specific is used". If you learn some **** processor asm that nobody has ever heard of nor will ever use then yes you're pretty much fubar. If you're going to learn ASm then you MUST learn the x86 language. Don't go out and buy some book on some speciality kind of processor, make sure it's X86 you're learning. The reason... Just about every computer you see out there, even supercomputers, are all running AMD or INTEL and both are X86 processors. Next time you pick up a game or some kind of software, look at the system requirements... Just about everything you'll ever pick up will say requires either intel or amd bla bla bla processor.
well yes, seeing as i have no hope in getting to college besides art/soccer this would be helpful..
if youd like to help me learn some, what do download and stuff-id greatly appreciate it :wave:
Some links to asm stuff...
http://vbforums.com/showthread.php?t=317393
You may want to buy a book on asm. Check out assembly langauge for intel-based computers by irvine.
IMHO ASM is a waste of time these days when you are not making your own operating system or working on a realtime embedded os.
Most of the speed gained from switching from VB (pre .net) can also gained by switching to C or C++, which is a lot easier.
C++ easier then vb? Are you insane?
Powerful, yes.
Easier, hell no.
I didn't mean C++ is easier then VB, I meant that C++ is easier then ASM and comparible in speed. VB6 is a lot slower then C++ in areas where speed matters.
You are so absolutely wrong!Quote:
Originally Posted by twanvl
I agree wholeheartedly with Maven - if you want to be a professional developer (not programmer, coder or hack!) - then you must know assembler.
People who don't know assember do silly things like REDIM PRESERVE on an array of 1000 items to make it 1001. People who don't know assember have no clue why something is slow - or why something is fast! People who don't know assember have no clue what the operating system is doing. No clue how memory works.
Assambly is not important anymore these days. The only thing ASM is good for is micro optimization. Micro optimization is a thing you rarely need anymore, you can gain much more by profiling and choosing the right algorithms.
You say you need to know what the operating system is doing, I agree that this can be important. But your operating system is mostly written in C, not in asm.
About your REDIM PRESERVE example, this is not explained easily using asm, the reason you shouldn't REDIM PRESERVE is because of the algorithmic complexity of the operation. I would say a modern developer should learn complexity theory instead of asm.
There is also a difference between knowing the hardware and the cost of operations and knowing assambler. You can learn how memory works from using pointers in C or C++ for example. In a higher level language you don't need to know this at all. Most of this knowledge comes gradually as you program, for example the difference between floating point and integer operations, again, no need to know assambly.
Again - I disagree with your point completely.Quote:
Originally Posted by twanvl
Knowing machine code - what the "chip" in the computer is "executing" - knowing that there are registers - and not that many of them - knowing that is paramount to understanding what is happening. Programmers think they make a variable - fill it with a value and all of a sudden stuff happens.
ASM exposes machine code - which all third-generation languages get compiled into.
From what I see of programmers trained in colleges today - they have all kinds of knowledge of proper technique - proper programming constructs to use - but have no clue what's going on under the hood.
They can argue why you should never use GOTO (but really have no practical knowledge of why it's bad practice - they would have to maintain a program written by a bad programmer 10 years ago to appreciate that). But they have no clue that JUMP operations are going on at the machine code level constantly. PC's are all about check condition and jump - do some math - check condition and jump.
Being able to develop a meaningful function in ASM to perform a simple operation makes a big difference in my opinion.
You are right that knowing what's under the hood is very important. I know some asm myself. But I think you only need to be able to read some of it, and know that there are about 6 usable registers on the x86, etc. Writing asm is completely useless (for x86 at least). Also, IMO it doesn't matter what kind of assambly you know, I only understand half of x86 asm, but I have written programs in z80 asm.
Finally, it is not always important, for example when programming in java or .net I think knowing x86 asm is pointless, your code could just as well run on a powerpc, or an itanium. You need to know the cost of operations, but not the exact translation into machine code.
You can make VB do it, but it's messy. Whack the hex into an array. GlobalAlloc the same size then copy mem array into it and call the WinAPI (which I can't remember) to jmp to the start of the memory block.Quote:
Originally Posted by Maven
C++ is not easier then asm. You'll learn ASM a hella lot faster then you will C++, that I promise you!Quote:
Originally Posted by twanvl
I don't think you guys are getting that both C++ and VB generate the same thing, that is machine code. ASM isn't faster then either langauge but has the ability to be. With C++ or visual basic, you can only impletement things in certian ways where as in asm, you have more freedom with what you can do.
That is my whole point - magic happens in the computer to those people who do not explore ASM - which exposes the machine code.Quote:
Originally Posted by Maven
That, in my opinion, is a shame.
But last time I checked it made pretty much faster code. And C++ also has the ability to use other instructionsets that you can't use in VB.
BAck when we evaluated compilers on the mainframe - 20 years ago (when speed really mattered)...Quote:
Originally Posted by NoteMe
Companies would make claims like "compiles to within 60% of machine code" - or "compiles to within 80% of machine code". Granted they were tough to challenge the accuracy of these...
But also you could not use %-of-machine code comparisons between completely different languages. Some language constructs are closer to machine code "naturally" - thus they get a higher %-age score. They are also harder to use.
It is not all about how much machine code the compiler uses. Different techniques for a job makes differnte ASM output after compiled in C++.
And why would Intel and Codeplay use sooo much money to make fast compilers, if the compiler doesn't do a lot of stuff with the code before it makes the machine code so it can be faster. No one would use US$26500 on a compiler if it wasn't faster then the free compilers out there.
ØØ
Quote:
Originally Posted by szlamany
Ohh BTW, so you are saying speed doesn't matter....:D:D:D:D...I dare you to make a new thread in the game section and see what happens....:D:D:D
Huh??Quote:
Originally Posted by NoteMe
"how much machine code the compiler uses" - what do you mean by that.
Talk slower - I must be having a hard day :bigyello:
I said " (when speed really mattered)..."Quote:
Originally Posted by NoteMe
That cannot be syntactically changed into me saying "speed doesn't matter"!
Quote:
Originally Posted by szlamany
Well let me try to rephrase it again then. Make a thread in the game section and say that "speed doesn't really matter"....this should be fun...:D
Quote:
Originally Posted by szlamany
Different coding styles and theqnices gets optiomised differently on different compilers. If you want the MAX out of your compiler, you have to know what kind of coding style you should apply to let the compiler optimice it to the max. You don't have that opertunity at all in VB, because you only have one big bloated dumb compiler, that is just happy if it can make working code.
C++ compilers have been around for long, and are used for much more time criticle application hence compiler makers have used more time to optimze the compiler then the VB developers ever did, or will do.
And an other thing is that there is many different companies struggling to make the fastest compiler, and more competition makes them work even harder on optimizing it...;)
Ok - you are truly misunderstanding me.Quote:
Originally Posted by NoteMe
Imagine you have a requirement - to schedule students into classes at a high school. Some kids schedule in 20 iterations - some kids can take 100,000 iterations.
So it's an algorithm - simple actually - but very time consuming.
If you developed it in ASM - using flawless ASM - you could get as close to machine code - as close to the creators of the chip invisioned was possible.
We didn't do that - we put it in VAX-11 BASIC - the language we decided to use back in the 1980's. We were happy that Digital at the time was stating that VAX-11 BASIC compiled to within 60% of machine code (I'm guessing at the figure - I don't remember).
It took several hours to run.
We decided that developing the algorithm in MACRO-11 (the ASM on that machine) was not beneficial.
Instead we looked carefully at where the most time was spent in the code, and made memory pools, better binary searches - developed some MACRO-11 functions to call.
With that we were making incremental speed changes - 2% here, 5% there.
Always knowing that faster chips were coming along - they would show us a 20% or 30% increase in speed every couple of years.
And I must say that you can write poor code in VB that will turn into even worse machine code instructions to the machine - and you can certainly write neat, clean, concise code in VB that will take less machine code instructions to process.
And by faster compiler, you mean speed in turning source into executable file - right? I personally could care less - that's when I look out the window and stretch my eyeballs :bigyello:
Quote:
Originally Posted by szlamany
no no no...you are missunderstanding me completly...:D..we two are from different worlds...:)
OK, let me have this post, and the 3 next posts to show you.
When you compile a C++ app, you don't get the same ASM output from different compilers. Different outputs gives different speed during RUN TIME. That is what we are talking about. Most don't care too much about the compile time, because you have debug mode and Release mode with most compilers. So it doesn't take to much time to compile while you are just making the darn app.
So lets take an example from my world. A simple function that don't require too many lines of code is to rotate a vector in 3D space. The following post will show you some simple code to roate a vector. Written in C++.
Rotate a vector in 3D space:
Code:static void __cdecl RotateVectors (void)
{
int i, r, x, y, CentreX, CentreY;
int temp [4];
SetRotation ();
DrawFlag = TRUE;
SOAFlag = FALSE;
IntFlag = FALSE;
for (r=0; r<4; r++)
{
for (i=0; i<NUMPOINTS; i++)
{
TPoints [i] [0] = CameraRotation [0] [0] * Points [i] [0]
+ CameraRotation [0] [1] * Points [i] [1]
+ CameraRotation [0] [2] * Points [i] [2];
TPoints [i] [1] = CameraRotation [1] [0] * Points [i] [0]
+ CameraRotation [1] [1] * Points [i] [1]
+ CameraRotation [1] [2] * Points [i] [2];
TPoints [i] [2] = CameraRotation [2] [0] * Points [i] [0]
+ CameraRotation [2] [1] * Points [i] [1]
+ CameraRotation [2] [2] * Points [i] [2];
Flags [i] = TRUE;
__hint__ ((unroll(2)));
}
}
}
Now, if you compile this with the VectorC compiler you get:
Code:_RotateVectors:
push ebx
push ebp
push esi
mov esi,eax
mov eax,80
push edi
mov edi,esp
call __chkstk
mov eax,esi
and esp,-16
mov dword ptr 76[esp],edi
call _SetRotation
mov byte ptr _DrawFlag,1
mov byte ptr _SOAFlag,0
mov byte ptr _IntFlag,0
mov dword ptr [esp],4
movss xmm0,dword ptr _CameraRotation + 20
movss xmm1,dword ptr _CameraRotation + 8
movss xmm3,dword ptr _CameraRotation + 28
unpcklps xmm1,xmm0
movss xmm0,dword ptr _CameraRotation + 32
shufps xmm0,xmm1,64
movss xmm1,dword ptr _CameraRotation + 4
movaps xmm2,xmm0
movss xmm0,dword ptr _CameraRotation + 16
unpcklps xmm1,xmm0
movss xmm0,dword ptr _CameraRotation + 12
shufps xmm3,xmm1,64
movss xmm1,dword ptr _CameraRotation
unpcklps xmm1,xmm0
movss xmm0,dword ptr _CameraRotation + 24
movaps xmmword ptr 16[esp],xmm2
mov di,word ptr __vconst92
shufps xmm0,xmm1,64
movaps xmm1,xmm0
align 32
_$PreHeader99100:
xor esi,esi
xor ebp,ebp
align 32
L18_FOR_SKIPINC:
movss xmm0,dword ptr 0 + _Points[ebp]
prefetchnta 152 + _Points[ebp]
movss xmm2,dword ptr 4 + _Points[ebp]
movss xmm5,dword ptr 16 + _Points[ebp]
movss xmm4,dword ptr 8 + _Points[ebp]
mov word ptr 0 + _Flags[esi],di
add esi,2
movss xmm6,dword ptr 20 + _Points[ebp]
movss xmm7,dword ptr 24 + _Points[ebp]
shufps xmm0,xmm0,0
shufps xmm2,xmm2,0
mulps xmm0,xmm1
shufps xmm4,xmm4,0
mulps xmm2,xmm3
shufps xmm7,xmm7,0
mulps xmm4,xmmword ptr 16[esp]
mulps xmm7,xmmword ptr 16[esp]
shufps xmm5,xmm5,0
addps xmm0,xmm2
mulps xmm5,xmm1
shufps xmm6,xmm6,0
mulps xmm6,xmm3
addps xmm0,xmm4
movhps qword ptr 0 + _TPoints[ebp],xmm0
addps xmm5,xmm6
movss dword ptr 8 + _TPoints[ebp],xmm0
addps xmm5,xmm7
movhps qword ptr 16 + _TPoints[ebp],xmm5
movss dword ptr 24 + _TPoints[ebp],xmm5
add ebp,32
cmp esi,49999
jl L18_FOR_SKIPINC
cmp esi,50000
jge L13_FOR_INC
movss xmm0,dword ptr 0 + _Points[ebp]
movss xmm2,dword ptr 4 + _Points[ebp]
movss xmm4,dword ptr 8 + _Points[ebp]
shufps xmm0,xmm0,0
shufps xmm2,xmm2,0
shufps xmm4,xmm4,0
mulps xmm0,xmm1
mov byte ptr 0 + _Flags[esi],1
mulps xmm2,xmm3
mulps xmm4,xmmword ptr 16[esp]
addps xmm0,xmm2
addps xmm0,xmm4
movhps qword ptr 0 + _TPoints[ebp],xmm0
movss dword ptr 8 + _TPoints[ebp],xmm0
L13_FOR_INC:
mov ebp,dword ptr [esp]
dec ebp
mov dword ptr [esp],ebp
jne _$PreHeader99100
mov esp,dword ptr 76[esp]
pop edi
pop esi
pop ebp
pop ebx
__ReturnProcedure109:
ret
__EndProcedure110:
It is higly optimized after your choice using MMX, 3DNow, or SSE or SSE2.
And most of all, it is short. Making less cash misses occure duing run time.
Now if you compile it using Visual C++, you get more or less 50% longer code, and it is not optimized for MMX, nor 3DNow, nor SSE, nor SSE2, because you didn't write the ASM to do so.
Code:_RotateVectors:
push esi
push edi
call @SetRotation@0
xor edx,edx
mov byte ptr [_DrawFlag],1
mov byte ptr [_SOAFlag],dl
mov byte ptr [_IntFlag],dl
mov esi,4
L1:
mov ecx,12500
mov eax,16843009
mov edi,_Flags
rep stosd
xor eax,eax
L0:
fld dword ptr [_CameraRotation+8]
fmul dword ptr _Points+8[eax]
fld dword ptr [_CameraRotation]
fmul dword ptr _Points[eax]
add eax,16
cmp eax,800000
faddp st(1),st
fld dword ptr [_CameraRotation+4]
fmul dword ptr _Points-12[eax]
faddp st(1),st
fstp dword ptr _TPoints-16[eax]
fld dword ptr [_CameraRotation+20]
fmul dword ptr _Points-8[eax]
fld dword ptr [_CameraRotation+12]
fmul dword ptr _Points-16[eax]
faddp st(1),st
fld dword ptr [_CameraRotation+16]
fmul dword ptr _Points-12[eax]
faddp st(1),st
fstp dword ptr _TPoints-12[eax]
fld dword ptr [_CameraRotation+32]
fmul dword ptr _Points-8[eax]
fld dword ptr [_CameraRotation+24]
fmul dword ptr _Points-16[eax]
faddp st(1),st
fld dword ptr [_CameraRotation+28]
fmul dword ptr _Points-12[eax]
faddp st(1),st
fstp dword ptr _TPoints-8[eax]
jl long L0
dec esi
jne long L1
pop edi
pop esi
ret
@SetRotation@0:
sub esp,80
fld dword ptr [_Rotx]
fadd qword ptr [__real@8@3ffbccccccccccccd000]
mov dword ptr 12[esp],0
mov dword ptr 20[esp],0
mov dword ptr 24[esp],1065353216
mov dword ptr 28[esp],0
mov dword ptr 36[esp],0
mov dword ptr 44[esp],1065353216
fstp dword ptr [_Rotx]
fld dword ptr [_Roty]
fadd qword ptr [__real@8@3ff8a3d70a3d70a3d800]
mov dword ptr 48[esp],0
mov dword ptr 52[esp],0
mov dword ptr 56[esp],0
mov dword ptr 68[esp],0
fstp dword ptr [_Roty]
fld dword ptr [_Rotx]
fcos
fld dword ptr [_Rotx]
fsin
fld dword ptr [_Roty]
fcos
fchs
fstp dword ptr 4[esp]
fld dword ptr [_Roty]
fsin
mov eax,dword ptr 4[esp]
mov dword ptr 60[esp],eax
mov edx,eax
lea eax,8[esp]
mov dword ptr 76[esp],edx
push eax
lea edx,48[esp]
fstp dword ptr 4[esp]
fld st(1)
mov ecx,dword ptr 4[esp]
fstp dword ptr 12[esp]
mov dword ptr 76[esp],ecx
mov ecx,_CameraRotation
fld st
fchs
fstp dword ptr 20[esp]
fstp dword ptr 36[esp]
fstp dword ptr 44[esp]
fld dword ptr 4[esp]
fchs
fstp dword ptr 68[esp]
call @RotateMatrix@12
add esp,80
ret
nop
nop
@RotateMatrix@12:
push ebx
mov ebx,dword ptr 8[esp]
push esi
push edi
add edx,4
mov edi,3
L3:
lea eax,12[ebx]
mov esi,3
L2:
fld dword ptr 12[eax]
fmul dword ptr 4[edx]
fld dword ptr -12[eax]
fmul dword ptr -4[edx]
add eax,4
add ecx,4
dec esi
faddp st(1),st
fld dword ptr [edx]
fmul dword ptr -4[eax]
faddp st(1),st
fstp dword ptr -4[ecx]
jne short L2
add edx,12
dec edi
jne short L3
pop edi
pop esi
pop ebx
ret 4
It is for SURE slower.
Now over to the last of the big compilers on the selling market. Intels C/C++ compiler. It sells like ****. But on this example you can see that it is nearly making 100% longer code then the VectorC compiler. And it is not that optimized at all. Unless you have a P4 processor that is. But still the VectorC output will beat it to deth.
Code:_RotateVectors:
sub esp,52
call _SetRotation
mov byte ptr [_DrawFlag],1
xor al,al
mov [_SOAFlag],al
mov [_IntFlag],al
xor eax,eax
fld dword ptr [_CameraRotation]
fstp dword ptr 24[esp]
fld dword ptr [.bss+1650036]
fld dword ptr [.bss+1650040]
fld dword ptr [.bss+1650044]
fld dword ptr [.bss+1650048]
fld dword ptr [.bss+1650052]
fld dword ptr [.bss+1650056]
fld dword ptr [.bss+1650060]
fld dword ptr [.bss+1650064]
fstp dword ptr 28[esp]
fstp dword ptr 32[esp]
fxch st(3)
fstp dword ptr 44[esp]
fxch st(3)
fstp dword ptr 40[esp]
fxch st(3)
fstp dword ptr 36[esp]
L2:
xor ecx,ecx
xor edx,edx
jmp short L0
mov esi,esi
lea edi,0[edi]
L1:
fstp dword ptr .bss+800024[edx]
L0:
fld dword ptr _Points[edx]
fld dword ptr .bss+36[edx]
fld dword ptr .bss+40[edx]
fld st(2)
fmul dword ptr 24[esp]
fld st(2)
fmul dword ptr 36[esp]
faddp st(1),st
fld st(1)
fmul dword ptr 40[esp]
faddp st(1),st
fstp dword ptr _TPoints[edx]
fld st(2)
fmul dword ptr 44[esp]
fld st(2)
fmul st,st(7)
faddp st(1),st
fld st(1)
fmul st,st(6)
faddp st(1),st
fstp dword ptr .bss+800036[edx]
fxch st(2)
fmul st,st(3)
fxch st(1)
fmul dword ptr 32[esp]
faddp st(1),st
fxch st(1)
fmul dword ptr 28[esp]
faddp st(1),st
mov byte ptr _Flags[ecx],1
add edx,16
inc ecx
cmp ecx,50000
jl short L1
fstp dword ptr .bss+800024[edx]
inc eax
cmp eax,4
jl long L2
fstp st
fstp st
fstp st
add esp,52
ret
lea esi,0[esi]
_SetRotation:
sub esp,124
fld qword ptr [$2$3_2il0floatpacket$1]
fadd dword ptr [_Rotx]
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fst dword ptr [_Rotx]
fld qword ptr [$2$3_2il0floatpacket$3]
fadd dword ptr [_Roty]
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fst dword ptr [_Roty]
fxch st(1)
fsincos
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fxch st(1)
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fxch st(2)
fsincos
fchs
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fxch st(1)
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fxch st(2)
fst dword ptr 24[esp]
fld dword ptr [$2$3_2il0floatpacket$5]
fst dword ptr 28[esp]
fld st(4)
fchs
fstp dword ptr 96[esp]
fld dword ptr 96[esp]
fst dword ptr 32[esp]
fxch st(1)
fst dword ptr 36[esp]
fld dword ptr [$2$3_2il0floatpacket$7]
fst dword ptr 40[esp]
fxch st(1)
fst dword ptr 44[esp]
fxch st(6)
fst dword ptr 48[esp]
fxch st(6)
fst dword ptr 52[esp]
fxch st(3)
fst dword ptr 56[esp]
fxch st(1)
fst dword ptr 60[esp]
fxch st(3)
fst dword ptr 64[esp]
fst dword ptr 68[esp]
fst dword ptr 72[esp]
fxch st(4)
fst dword ptr 76[esp]
fld st(5)
fchs
fstp dword ptr 80[esp]
fxch st(4)
fst dword ptr 84[esp]
fxch st(5)
fstp dword ptr 88[esp]
fxch st(3)
fstp dword ptr 92[esp]
fld dword ptr 24[esp]
xor eax,eax
fstp qword ptr 104[esp]
fstp st(1)
fxch st(1)
fstp qword ptr 112[esp]
jmp short L3
lea esi,0[esi]
lea edi,0[edi]
L4:
fstp dword ptr .bss+1650028[eax]
L3:
fld dword ptr 60[esp][eax]
fld dword ptr 64[esp][eax]
fld dword ptr 68[esp][eax]
fld qword ptr 104[esp]
fmul st,st(3)
fld st(5)
fmul st,st(3)
faddp st(1),st
fld st(6)
fmul st,st(2)
faddp st(1),st
fstp dword ptr _CameraRotation[eax]
fld st(4)
fmul st,st(3)
fld dword ptr [$2$3_2il0floatpacket$7]
fmul st,st(3)
faddp st(1),st
fld st(5)
fmul st,st(2)
faddp st(1),st
fstp dword ptr .bss+1650036[eax]
fxch st(2)
fmul st,st(3)
fxch st(1)
fmul st,st(4)
faddp st(1),st
fxch st(1)
fmul qword ptr 112[esp]
faddp st(1),st
add eax,12
cmp eax,36
jl short L4
fstp dword ptr .bss+1650028[eax]
fstp st
fstp st
fstp st
add esp,124
ret
mov esi,esi
So...
I've been saying - in pretty much every one of my posts in this thread...
Knowledge of ASM helps you understand what the computer is doing at the machine code/chip level.
And didn't you just prove that for me with three perfect examples of machine code?
As a round up, the vectorC code is more then twice as fast as the Intel output on an average 1GHz machine. And nearly twice as fast as the VS output.
If I had the opertunity to get the asm output for VB doing the same I guess I had to post 999 post just to get all the code posted, and it is not optimized at all. Just working ASM code.
ØØ
Quote:
Originally Posted by szlamany
No, you don't have to know anything about ASM, to grab a C++ compiler and beat VB with it hands down even without trying that much. And that is my point.
Maven said:
Hell yeah, but machine code is not just machine code. As long as VB makes crappy machine code as it does, it will never be comparable with VB. The output is alfa omega, but you don't have to care about it at all.Quote:
I don't think you guys are getting that both C++ and VB generate the same thing, that is machine code.
Learning ASM helps you understand what is going on, but I can't see it help you much in making fast C++ code, because it is more about knowing your compiler, and what it likes then anything else.
ØØ
Quote:
Originally Posted by Maven
Thats not possible to generalize.
You did maybe.
I used more time to learn ASM with it hard graphics things, and making use of COM is more or less hopeless.
In C++ it took me no time at all.
But that was me, not you.
An other example is that I have really big problems trying to learn Prolog. Kedaman loves it, and know how to find his way around it. For me it is still just a big void in my brain.
Noteme - I certainly don't want to give you a big head...
...it looks like you have been banging it for eternity :bigyello:
You apparently appreciate the inner workings of the computer - how you arrived there - through C, Games, ASM - whatever - you appear to be there.
But the original post was:
And I still maintain that if you are a novice, you will benefit from learning ASM - and removing the magic of what goes on inside.Quote:
Just wondering, can you give me any reasons to try out asm from vb?
ive read some stuff here and dont really understand..there should be a big tutorial somewhere..i know there must
We have a report writer engine that's in our VB6 application. It loops through the rows in a recordset (could be 1000's) and the "report objects" that are being printed (typically 10 or 20, but for a complex report 200 or 300 is possible). That 1000 * 300 is a loop of 300,000 iterations.
So when it comes to the logic to determine the currentx/currenty on the page we actually "duplicate" that logic in each CASE statement (there are nearly 100 case statements).
Some programmers would have written a SUB/FUNCTION for this.
But we know that a SUB/FUNCTION must deal with the stack/frame and thus has outrageous overhead.
A programmer trained in VB only would never consider not using a SUB/FUNCTION.
I believe that our overall knowledge of the inner workings of the computer allows us to "breach" this construct rule (duplicated code - oh my!).
We happen to have arrived at the "it's not magic" through 2 decades of assembler and reviewing how code compiled from BASIC into machine code (along with other things as well).
And those programmers would have done the right thing, writing easy, maintainable code. And if they used a half decent compiler the compiler would have inlined the functions for him. Also, when printing, calculating the currentx/currenty will not be a bottlneck, that will be either the printer or the screen. You will have wasted your time copying code a 100 times and reading it a lot of times, possibly copying it again is there is a bug, etc. Until your profiler tells you that this may be a point that needs optimization you shouldn't even think about it.Quote:
Originally Posted by szlamany
There are some cases where converting your code into asm is needed, but to get back to the original post:
Only if you have code that has some very often used inner loop, say a image transformation. And even then, you should first consider C or C++, it will be faster then VB, and it will be more portable and easier to maintain then asm. It may be 2 times slower, but that may not matter at all. It is also quite likely that you can find some library that does what you need to do, so you don't need to write it yourself.Quote:
Just wondering, can you give me any reasons to try out asm from vb?
Finally, I don't think anyone can honestly say that writting fast asm, i.e. asm with sse, etc., that optimally uses registers, is easier then writing C.
My point is that having a SUB/FUNCTION was going to "cost too much" - that doing the currentx/currenty logic in-line was the proper method to choose.Quote:
Originally Posted by twanvl
I never said calculating the x/y was a bottleneck. I said that calling a SUB/FUNC to do it would be a bottleneck.
Can you appreciate that at all? Do you appreciate the effort (memory and CPU thrashing) that calling a SUB/FUNC does?
This is not a post (nor is this a thread) about converting to ASM for speed.
It's about the benefits of knowing ASM.
Quote:
Originally Posted by szlamany
I have no idea what you are talking about, when you talk in codes like that. Speak up, don't use metaphors....it will only make you lose your point when discussing with a foreigner. Because if you just had a point. It was never transmitted through the right channel.
Well enough about teaching away communication skills.
Quote:
Originally Posted by szlamany
Yes it was, I just commented on your and Mavens comparing of VB and C++. And that was a lousy comparison.
Quote:
Originally Posted by szlamany
I still can't see the big point in teaching ASM for this. You will reveal more then enough of that magic by just using an other language that is not a RAD language, like C++. Then you will deal with stacks, and you can look at cach misses, DMA crash and so on and so on. And I can't see one reason why I would need ASM to understand anything of this. I thought it my self much better by teaching about how a computer is buildt up and then use C++ to deal with it as best as I could. And the ASM course didn't bring anything new too it, nor did it teach me more then 10% then what C++ have thought me. But hell yeah, C++ have thought me a lot about structure, maintenance, coding paterns, and pros and cons about how to lay out your code, that VB never thought me.
And twanvl said that a half decent compiler will inline it for you. And I agree. And he also stated that you would see it on a profiler that it should have been inlined, or done in an other way, and I agree.Quote:
Originally Posted by szlamany
"Giving someone a big head" means giving them a compliment - one that is well deserved, but so well deserved it's better not said!Quote:
Originally Posted by NoteMe
Banging it is something you appear to be doing in your little animated jpg - that was just a silly joke.
I meant nothing but respect for your level of knowledge. :)
I already knew what lines of code were required to be "duplicated" and I also knew that VB was not going to detect duplicate code or function usage and in-line it in the machine code executable.Quote:
Originally Posted by NoteMe
I didn't need a profiler - and never need a profiler - to show me what's going on.
In the past 20 years we have developed in-house RDBMS systems, RPG-like compilers - lots of low-level functionality - so maybe I'm a little one sided on this.
C&D (my 4 year old twins needed to sign their initials!)
That was the point of my compliment!Quote:
Originally Posted by NoteMe
It appears you have arrived at the inner knowledge of the way things "compute" through C++ - we did it through machine code...
Same goal reached - different paths.
Structure, laying out code - that low level stuff you appreciate and acknowlege does not seem to be available to the programmers I've interviewed/hired/used in the past 3 years.
Quote:
Originally Posted by szlamany
I can't see a joke even if someone smacks me in the head with it outside the ChitChat forum...:)
But for an average person, you won't see that just because you took an ASM course or what ever. That is something that is much easier to get through teaching more languages (languages that is actualy useful), and learning the languages WELL, not just touch them, as most VB users do that post on this forum.Quote:
Originally Posted by szlamany
If you know C++ well, you know that wrapping something into a class will make the your machine look up one extra address in memory without knowing anything about ASM. And you also know that if the class is inherited, there is no way for the compiler to know where this address is at compile time. It requires a vTable, so the address can be found at run time. And that will slow down the function you talked about even more. And the worst thing is that it can no longer be inlined either.
But my point is that you don't know much more about that by teaching some ASM. You get that from experience over a longer period, and reading.
But now I feel we are touching an other topic here. Because people that say they know C++ and don't know what a vTable is, they are most of then self taught. And that is an other problem. They lose a lot of the inner work, because they teach them what they want in stead of things they should have known. And that you will be taught on a collage or at a uni. And reminds me about the old stories I have read about self taught VB programmers coming to an interview, and the guy that is interviewing asks him about algorithms, and the guy doesn't even know what an algorithm is because he has just taught himself the VB skills he wanted.
Well back on track again. At my Uni (the one I am soon finished at) we had a computer course that was about how a computer works and what parts there is in a computer and so on. And they taught us ASM. The teachers and the school board liked the course. Then I became the second in command (or what the PIIIP it is called....guess I have been in the army too long..:)) in the school board for physics and CS at my Uni and presented them with an other plan that changed the C++ course and the computer course that I just talked about. And they liked it. It no longer contains ASM coding. They will be taught about the registers and so on, but the rest will be about other PC parts as it was. And then they will use this in the C++ course.
So after the new semester new students at our Uni will no longer be taught ASM, but I am pretty sure they will understand the plot just as well.
You are just too cute to be a computer geek...:DQuote:
Originally Posted by szlamany
Well I guess we some how, in an odd way agree then....hmmm....:DQuote:
Originally Posted by szlamany
I hope you have just interviewed self taught programmers the last 3 years. If not, then I will rule out USA (if that is where you are coming from) for my master degree. That's for sure.Quote:
Originally Posted by szlamany
You should try too look for employees in an other country..:D
The way visual basic works internally is much different from C++. That is why you see a speed difference, because microsoft made visual basic very simple. Visual basic is a very object based langauge, everything from array variables to the functions you rely on are all OLE objects. A good example of this is to look at the internals of an array. One thing you will find that all visual basic arrays are actually OLE_SAFEARRAY structures. When you call LEN(String) for example, you don't actually perform any calculations on the variable, it reads a memory address. That is why you will never write a better len function then the one visual basic provides. In fact calling len multiple times in visual basic on a large string would more then likely be faster then doing the same in C++ using strlen.Quote:
Originally Posted by NoteMe
In C++, you have the ability to work with the strings and arrays in the same fasion as visual basic. You will also make the same sacrafices in speed that microsoft made with their design of vb. MFC is a good example of sacrafice in the name of simplicity. Just like visual basic, if you use MFC, you wouldn't have the ability to make much use of directx graphics because the method is too slow. In a nutshell, the more high level layers you add onto a language, the slower it will become.
Compiler design is one of the hardest software programming projects in existance. That's why it's so expensive =/Quote:
Originally Posted by NoteMe
Speed is not the only design goal. That's important to remember!Quote:
Originally Posted by NoteMe
Hold it there partner =PQuote:
Originally Posted by NoteMe
Just because the code is longer in asm does not mean that it will run slower.
It's not the machine code that makes visual basic so slow, it's the high level layers that go with it. If you added the same layers to C++, you would get the same slowdown.Quote:
Originally Posted by NoteMe
You have to know you're compiler optimization settings and what they are to make full befinit out of a compiler. That my friend is not all there is to making fast programs. Have you ever heard of parallel processing? Did you know that intel has out of order execution and do you know how that effects speed of a program? Do you know what a register dependcy is and what it does? Have you ever heard of a cache miss or know anything at all about the system cache and how it effects code? Do you know anything at all about branch misspredictions and how that effects the speed of the code? Do you know what TLB priming is and what it does? Do you know why loop unrolling effects code or that multiplication is faster then division? How about data and code alignment and how that effects speed? Do you know why running two loops out of sync could create a speed boast?
Also I would like to point out Intel's v-tune code profiler. You're not going to understand much of that output unless you have a background in ASM.
I almost hit the close button then thought I would add more:
It's a well known fact that different compilers generate different asm output for the very same reason that my hand optimized asm is going to be different from what a compiler will generate. The speed of one compiler will change from processor to processor. That is something that has been known in computer science since high level languages.
That is the reason complexity theory is the defacto standard way for analyzing algrorithms.
Quote:
Originally Posted by Maven
And your point was?
And BTW, no one would use MFC for speed intensive apps anyway. To be honest, I can't see why anyone uses MFC at all.
Quote:
Originally Posted by Maven
But that doesn't explain why one compiler can be free and one cost a whole years of payments...;)
The reason my friend is because one of them just works, and one of them is making HIGLY optimized code...;)
Quote:
Originally Posted by Maven
Never said so...;)...but in some applications, you could just as well not make the game at all, if it isn't fast...;)
Never said so. But it is pretty importent. Often if you have an app in C++, and you compile it "for fast code" it will actualy run slower then if you compile it "for small code". Some of the reasons I can see you have listed in your next post.Quote:
Originally Posted by Maven
But since the code I pasted is both smaller and vectorized, THAT means that it is faster...;)
Quote:
Originally Posted by Maven
It's both actualy. Even if it didn't add the same layers to VB, it would still be slower because of the output of the VB compiler. VB was never ment for speed. It is a RAD language.
Quote:
Originally Posted by Maven
Yes
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
YesQuote:
Originally Posted by Maven
All these things we students learn at school today...;)...and none of them thought through ASM at all.
Did you have any more questions...;)
Well, Intel's v-tune code profiler isn't the best anyway. I have never liked a profiler that is made from any HW vendor anyway.Quote:
Originally Posted by Maven
Quote:
Originally Posted by Maven
That is true. But vecotrized asm will always kill non vectorized output something that VB does.
And even Intels C/C++ compiler fails to make it most of the time.
I was explaining that cpp isn't always faster, it depends on the decisions made during the design.Quote:
Originally Posted by NoteMe
Unless you're programming something that requires intensive graphics processing, MFC is a good choice. Speed is not the only design goal.
"Compiler design is one of the hardest software programming projects in existance. That's why it's so expensive =/"Quote:
Originally Posted by NoteMe
I think that explained it correctly myself. How much simpler can one get?
Quote:
Originally Posted by NoteMe
Explain a few of those to me then. =P
oh man this topics gotten to hot for me...
Ok - I've just been through a thread that debated two ways to do things.
The goal was to find the number of days in the month of a given date.
First up the solutions given had basically taking the YEAR() and MONTH() of the date and adding a month and subtracting a day. This is a pretty standard trick - I've used it in T-SQL many, many times - but T-SQL is a fourth generation (at least) language...
At any rate, I suggested using a logic/If/math method in code - basically an array having the number of days in a month and some logic to determine if it's a leap year - you could imagine...
I'm not sure what easy maintainable code would have dictated - or what complexity theory would have dictated.
Here's the post if you are interested...
Post with comparison of timing
And the whole thread, if you want to read what got us to this point.
The thread itself...
What an interesting thread.
For what it's worth, I think ASM is worth learning because it gives you a much deeper and more tangible understanding of what the CPU is doing. You can really feel the processor's anatomy and appreciate how much work it has to do to accomplish even the simplest thing.
I doubt that any compiler will be able to write code as well as a human doing ASM by hand. And its a challenge too, it expands the intellect, and best of all it makes most other languaes look flabby and slooooooow (and easy).
I like to write code that performs as fast as it can for any given language, ASM happens to appeal to that side of me. I'll be using ASM mostly for spot-tuning my C# programs.