Sinisterly
Simple VB.Net 2D Game Engine - Printable Version

+- Sinisterly (https://sinister.ly)
+-- Forum: Coding (https://sinister.ly/Forum-Coding)
+--- Forum: Visual Basic & .NET Framework (https://sinister.ly/Forum-Visual-Basic-NET-Framework)
+--- Thread: Simple VB.Net 2D Game Engine (/Thread-Simple-VB-Net-2D-Game-Engine)

Pages: 1 2 3


RE: Simple VB.Net 2D Game Engine - Falgantil - 05-02-2013

(05-02-2013, 12:27 AM)ArkPhaze Wrote:
(05-01-2013, 09:20 AM)Falgantil Wrote:
(05-01-2013, 05:15 AM)ArkPhaze Wrote:
Quote:A very simple test is, try making a loop, writing "Hello there HackCommunity", say 1.000.000 times or so, in both languages. Start them at the same time and see what finishes first.
Unless something has changes drastically since last time I checked, it should be the C# code that finishes first.

That is so far off from being true... I love C#, but C/C++ is definitely faster, and I will never admit that that C# is better than any other language either; being a fanboy of a programming language gets you into trouble. I would rather keep an open mind.

if you recall what I said before C# and VB.NET go through something called JIT compilation at runtime. the CLR manually babysits the program at runtime, and is responsible for exception handling, memory management, and many other things. C/C++ is much faster for this reason, unless you're doing something really wrong, or your benchmark tests are really really screwed up. For that reason, C/C++ programs use less memory than .NET programs (unless you are a bad programmer and you do not properly manage memory in your C/C++ applications. That's called memory leaks though).

I really don't understand your server, vs games reference though...

If what you're saying is really true, then explain to me how a C++ program writing Hello World 100000 times, and a C# doing the same, that C# finished after about 4 seconds, and the C++ finished after 17 seconds.
Might differ on computers of course. But the statement remains true, that C# is faster than C++ at executing the same code over and over. Which in most cases are just servers doing that

~ Falgantil ~

Lets test that, what C++ code were you using and what C# code were you using? Are you even confident that the code was a fair comparison? You did read that C# manages things for you in the background? I know that there is no reason for there to be that large of a difference... But C is definitely faster than C#.

edit: Read this: http://stackoverflow.com/questions/138361/how-much-faster-is-c-than-c
Quote:There is no strict reason why a bytecode based language like C# or Java that has a JIT cannot be as fast as C++ code. However C++ code used to be significantly faster for a long time, and also today still is in many cases. This is mainly due to the more advanced JIT optimizations being complicated to implement, and the really cool ones are only arriving just now.

So C++ is faster, in many cases. But this is only part of the answer. The cases where C++ is actually faster, are highly optimized programs, where expert programmers thoroughly optimized the hell out of the code. This is not only very time consuming (and thus expensive), but also commonly leads to errors due to over-optimizations.

On the other hand, code in interpreted languages gets faster in later versions of the runtime (.NET CLR or Java VM), without you doing anything. And there are a lot of useful optimizations JIT compilers can do that are simply impossible in languages with pointers. Also, some argue that garbage collection should generally be as fast or faster as manual memory management, and in many cases it is. You can generally implement and achieve all of this in C++ or C, but it's going to be much more complicated and error prone.

As Donald Knuth said, "premature optimization is the root of all evil". If you really know for sure that your application will mostly consist of very performance critical arithmetic, and that it will be the bottleneck, and it's certainly going to be faster in C++, and you're sure that C++ won't conflict with your other requirements, go for C++. In any other case, concentrate on first implementing your application correctly in whatever language suits you best, then find performance bottlenecks if it runs too slow, and then think about how to optimize the code. In the worst case, you might need to call out to C code through a foreign function interface, so you'll still have the ability to write critical parts in lower level language.

Keep in mind that it's relatively easy to optimize a correct program, but much harder to correct an optimized program.

Giving actual percentages of speed advantages is impossible, it largely depends on your code. In many cases, the programming language implementation isn't even the bottleneck. Take the benchmarks at http://shootout.alioth.debian.org/ with a great deal of scepticism, as these largely test arithmetic code, which is most likely not similar to your code at all.

What this says to me is that you really can't compare these 2 languages. Simple as that... Optimizations depend on the skill of the programmer, and due to the CLR changing over time with many JIT optimizations along the way, it might as well be comparing optimized code to something not as optimized in comparison. You'd need to understand what the CLR does to make an accurate comparison, but in the end it really comes down to what the code looks like on a lower level.

C is a fast language though, that's just a known fact. It's good for more procedural based programs, and you may consider C++ over C for more object oriented projects. For development time, .NET might be better than a choice of C or C++. That is also a known fact, and it is the reasons why I get people coming to me asking me to develop their business related programs in .NET (usually C#, but sometimes VB.NET).

I should think that C++'s "cout" and C#'s "Console.WriteLine" is more or less equal, processing-wise.
Note that I am not saying that C++ is a bad language in any way. I'm just saying that sometimes you'd want to consider whether C++ is actually the best choice, even if you're very good at it.

~ Falgantil ~


RE: Simple VB.Net 2D Game Engine - ArkPhaze - 05-02-2013

I read this:
Quote:An area where I saw mentioned (I don't have tested this myself) that C# is supposed to be more consistently efficient is repeated memory allocation (as it is based on a GC, allocating memory is done in chunks and managed by the GC and releasing can be differed while the C++ code immediately allocates and releases each chunks from/to the OS immediately resulting in slower repeated memory allocations). But once again on the other hand the GC could kick in at unexpected times so it's hard to qualify this as an advantage/disavantage.

But the most important part is where he talks about the GC, which is a feature of the CLR I believe. Sure things may not be immediately released, but if the GC ever decides that it is time to clean up... That is a very computationally expensive task.

(05-02-2013, 04:19 PM)Falgantil Wrote: I should think that C++'s "cout" and C#'s "Console.WriteLine" is more or less equal, processing-wise.
Note that I am not saying that C++ is a bad language in any way. I'm just saying that sometimes you'd want to consider whether C++ is actually the best choice, even if you're very good at it.

~ Falgantil ~

You would be wrong to think that.

Code:
std::cout << "hello world"; 0013219E push 13EF24h 001321A3 mov eax,dword ptr ds:[001423DCh] 001321A8 push eax 001321A9 call std::operator<<<std::char_traits<char> > (01312FDh) 001321AE add esp,8

And only some of what goes on through the above:
Code:
[std::operator<<<std::char_traits<char> >:] 00FB12FD jmp std::operator<<<std::char_traits<char> > (0FB2210h) [template<class _Traits> inline basic_ostream<char, _Traits>& operator<<( basic_ostream<char, _Traits>& _Ostr, const char *_Val) { // insert NTBS into char stream] 00FB2210 push ebp 00FB2211 mov ebp,esp [template<class _Traits> inline basic_ostream<char, _Traits>& operator<<( basic_ostream<char, _Traits>& _Ostr, const char *_Val) { // insert NTBS into char stream] 00FB2213 push 0FFFFFFFFh 00FB2215 push 0FB9F48h 00FB221A mov eax,dword ptr fs:[00000000h] 00FB2220 push eax 00FB2221 push ecx 00FB2222 sub esp,154h 00FB2228 push ebx 00FB2229 push esi 00FB222A push edi 00FB222B lea edi,[ebp-164h] 00FB2231 mov ecx,55h 00FB2236 mov eax,0CCCCCCCCh 00FB223B rep stos dword ptr es:[edi] 00FB223D mov eax,dword ptr ds:[00FC10C4h] 00FB2242 xor eax,ebp 00FB2244 mov dword ptr [ebp-14h],eax 00FB2247 push eax 00FB2248 lea eax,[ebp-0Ch] 00FB224B mov dword ptr fs:[00000000h],eax 00FB2251 mov dword ptr [ebp-10h],esp (cont...) [ static size_t __CLRCALL_OR_CDECL length(const _Elem *_First) { // find length of null-terminated string] 00FB5DA3 sub esp,0C4h 00FB5DA9 push ebx 00FB5DAA push esi 00FB5DAB push edi 00FB5DAC lea edi,[ebp-0C4h] 00FB5DB2 mov ecx,31h 00FB5DB7 mov eax,0CCCCCCCCh 00FB5DBC rep stos dword ptr es:[edi]

Now for console.WriteLine in C#:
Code:
Console.Write("hello world"); 0000001a mov rcx,0B510003338h 00000024 mov rcx,qword ptr [rcx] 00000027 call 000000005E37A1E0 0000002c nop

What gets called:
Code:
00000000 push rbx 00000001 push rdi 00000002 sub rsp,28h 00000006 mov rdi,rcx 00000009 mov edx,0AEh 0000000e mov ecx,1 00000013 call FFFFFFFFFFF78050 00000018 mov rbx,rax 0000001b mov rax,qword ptr [rbx+000000D0h] 00000022 test rax,rax 00000025 jne 0000000000000030 00000027 mov cl,1 00000029 call 0000000000000120 0000002e xchg ax,ax 00000030 mov r11,qword ptr [rbx+000000D0h] 00000037 mov rax,qword ptr [r11] 0000003a mov rax,qword ptr [rax+58h] 0000003e mov rdx,rdi 00000041 mov rcx,r11 00000044 mov rax,qword ptr [rax+10h] 00000048 add rsp,28h 0000004c pop rdi 0000004d pop rbx 0000004e jmp rax 00000051 add rsp,28h 00000055 pop rdi 00000056 pop rbx 00000057 ret



RE: Simple VB.Net 2D Game Engine - iNanox - 10-28-2013

its a bit buggy but good job Smile


RE: Simple VB.Net 2D Game Engine - iNanox - 10-28-2013

its a bit buggy but good job Smile


RE: Simple VB.Net 2D Game Engine - iNanox - 10-28-2013

its a bit buggy but good job Smile


RE: Simple VB.Net 2D Game Engine - iNanox - 10-28-2013

its a bit buggy but good job Smile


RE: Simple VB.Net 2D Game Engine - iNanox - 10-28-2013

its a bit buggy but good job Smile