Is VB6 still in use of programmers?

As another test of speed, I have a GA that takes a few days to complete. Due to the lengthy run time, a difference in performance between VB6 and .NET would be highly noticeable. If anything, .NET was slightly faster, probably due to better design, since GAs are highly suited to OO design. However, the difference in speed was only a few hours, at best.

If you are seeing a significantly slower performance for audio processing, there is probably a reason for that which is specific to that particular task. I would guess that VB6 was making use of a library that wasn't part of the language, in which case it is equally available in .NET.

Quote:

---

Originally Posted by Shaggy Hiker

However, the difference in speed was only a few hours, at best.

---

I wonder how the different coding methods manage to make a difference in speed when using the GA?

Quote:

---

Originally Posted by Shaggy Hiker

If you are seeing a significantly slower performance for audio processing, there is probably a reason for that which is specific to that particular task.

---

no.
it's not only with audio , it's with every task,
since the .net tech designed to run in an interpreter.

Quote:

---

Originally Posted by whatsup

how can someone don't know about this, if this is the only way to run 16b apps on 32b os :)

---

It isn't the only way. It is the built in and supported way - and also applies to 32 bit apps on a 64 bit OS.

Quote:

---

if you see that vb6 run only in WoW, because there are no more new 32 OS releases,
that means, 32b is dead.

---

No it doesn't. All it means is that the OS itself does not natively run in 32 bit mode.

I use a 64 bit version of Windows, and almost all of the software I use is 32 bit, including many things from Microsoft themselves.

Even if the OS is capable of running 32 bit software (which I expect to be true for the next few versions of Windows, and probably all 64 bit ones [based on Win95 to XP]), whether or not the VB6 runtimes will work properly is not predictable with any certainty - at best you can hope.

Quote:

---

no.
it's not only with audio , it's with every task,
since the .net tech designed to run in an interpreter.

---

It is definitely not every task, I have yet to find one case where it is significantly slower.

In the few cases where I have seen measurable speed differences, they have either been better with .Net, or I checked my code and found that I was using the wrong method - which after a little research was easily corrected to give roughly the same speed (some faster, some slower) as the VB6 equivalent.

In addition to that, Shaggy Hiker (in the post you quoted) gave an example where .Net is noticeably faster, albeit not by a massive percentage.

As such I tend to assume that you didn't put in enough effort to work out what you were doing wrong in terms of speed, and instead are just clutching at an unjustified excuse (have you really compared properly written code for every task?) to blame the tool you used. There is a real possibility that .Net is slower for the task you were doing, but the fact that you didn't get a comparable speed does not make it anywhere near certain.

Quote:

---

Originally Posted by Nightwalker83

I wonder how the different coding methods manage to make a difference in speed when using the GA?

---

What do you mean? Are you asking how a GA can be better implemented using OO such that it speeds up the operation? Frankly, I can't answer that very well, as it has been at least five years since I have dealt with the program in .NET, and even more since I dealt with it in VB6. What I can point out is that a GA is a series of obvious objects: Genes, genomes, and populations. Each level of the GAs that I write has arrays of these (I never use only one population anymore). A population contains at least two lists of genomes, which contain arbitrary numbers and length lists of genes. At the very least, the ability to serialize the whole map would be an advantage, but overall, it has really been too long to be specific.

The other thing that I have forgotten is what I am comparing. I initially moved the VB6 to .NET without turning Option Strict ON. I used LOTS of implicit conversions (the code is small, but a single run is hundreds of thousands of iterations). I believe that my comparison between the two is a comparison with those implicit conversions. When I turned Option Strict ON and fixed all those implicit conversions, it increased the speed by a significant amount (two days rather than three).

So, while I have not directly compared the VB6 implementation to the optimized version of the .NET implementation, it is entirely possible that the .NET is now considerably faster than the VB6. So I don't know if the .NET was about the same or MUCH faster than the VB6, but either way it is a concrete example that contradicts what whatsup was reporting.

Quote:

---

Originally Posted by Shaggy Hiker

What do you mean? Are you asking how a GA can be better implemented using OO such that it speeds up the operation?

---

I always have difficulty understanding how VB6 and .NET can make a difference in speed. However, I guess that it isn't just because of the amount of code there is but also the number of operations that need to be preformed as well as the amount of system resources that are available to be used?

It certainly isn't the amount of code used, since Option Strict ON requires more code, but executes faster. Another example would be that VB6 only allowed for arrays, and they were all essentially fixed size. VB.NET has lists, which are kind of like optimized doubly linked lists (they may actually BE that under the hood). For collections that change size often, static arrays are awkward. Redim, and Redim Preserve can be implemented with some efficiency, but they still make use of some of the slower operations (memory allocation and deacllocation) on the x86 architecture.

Quote:

---

Originally Posted by si_the_geek

All it means is that the OS itself does not natively run in 32 bit mode.

---

sure :D

Quote:

---

they have either been better with .Net

---

that's for sure.
and that's because when MS touches something,
it can even turn an interpreted code,
to run faster than native one.

(at least in some users mind :) )

EDIT: for those who compare speed beteen .NET and VB6,
it isn't relate at all to what i was saying about speed.

what i said is in general, that native code runs much faster than interpreted code.

about vb6, i didn't check.
but if it does run slower than .NET, it can be two reasons:
* you use optimization in .NET, and not in VB6
* VB6 really sucks. - even if this is true, what i don't think,
VB6 app optimized, can run faster than .NET app optimized.

the speed not in all cases, noticable for the user.

but always: .NET app, runs much slower than Native Code app.

NightWalker83:
vb6 app, and every Native Code app, runs much faster than P-Code app,
because P-Code does much more operations for single instruction.
it has to translate every P-Code instruction to machine (Native Code) instruction.

You really need to stop pretending that your assumptions are correct, and instead actually check your facts - because yet again you have made unjustified claims that had already been disproved to the point that you should have very serious doubts.

VB.Net does have shortcomings (as does VB6, and any other language), but it is foolish to make others up based on a lack of knowledge, and even more so to keep on pretending that they must be right because you don't actually know better.


As to the speed comparisons I mentioned, you know me well enough to be in no doubt that both versions were optimised, and they were timed accurately. I find it childish and rather insulting that you would pretend otherwise.

There are reasons for the .Net version being faster for some things (which certainly does not imply that VB6 sucks), and it isn't hard for an experienced programmer to work out what some of them are.

http://en.wikipedia.org/wiki/P-code_machine

Is there even any point in arguing? VB6 is past and .Net is [at least] recent and near future.
People really need to stop comparing two things at once - absolutely pointless.
If someone likes one language vs another go ahead and use but do it quietly.
There are lots of java lovers ... and haters too ... Get over it.

Regards.

ps, I would close this thread...

Quote:

---

Originally Posted by whatsup

http://en.wikipedia.org/wiki/P-code_machine

---

That link would be much more useful if it was relevant. It appears that you have looked at the documentation and missed a key point. .NET, along with some other languages, does create an intermediate language that fits the definition of pCode. However, when the JIT runs, it turns the pcode into machine code...then leaves it there. This means that the initial run of the app can be slower because the JIT is converting the pcode into machine code, but every run after that is faster because the conversion doesn't happen a second time unless the program is changed.

So a .NET program starts out as pcode and then is no longer pcode. That conversion can be performed by other tools such that you don't even take a performance hit the first time you run an app, but with some caveats.

Quote:

---

Originally Posted by Shaggy Hiker

This means that the initial run of the app can be slower because the JIT is converting the pcode into machine code, but every run after that is faster because the conversion doesn't happen a second time unless the program is changed.

---

I don't think that is true... or I'm just not understanding what you mean.

Maybe some of the JIT'd code stays in memory so subsequent runs are a bit faster but I'm pretty sure the actual EXE/DLL file does not get changed at all. For a start, how could programs like Reflector disassemble a .NET assembly even after you have run it a few times if the code is now assembly code? Plus - what on earth would be the point? If the assemblies can work perfectly fine as machine code then why wouldn't the compiler just compile them to machine code in the first place instead of compiling them to IL just for the very first time they are run...

EDIT: In fact the more I think about this the more I am confident that this is not what happens and I would be surprised if that is what you actually meant because it seems such a daft concept.

EDIT EDIT: See the quote in my next post.

Quote:

---

Originally Posted by Shaggy Hiker

However, when the JIT runs, it turns the pcode into machine code...then leaves it there.

---

here i understand that the JIT (which i have no idea what it is)
use cpu cache memory.
nice.

native app can also use it, i guess.

if this is true, (i didn't check this yet)
that only the first pass there is a translation,
.net app can run pretty fast.

unless the exe is a big one, and there's not enough cache for it.

did i understand you correctly ?

EDIT: i just read about this.
good to know that at least there are ways to improve speed.

http://en.wikipedia.org/wiki/Just-in-time_compilation

anyway native code is always better :)

Quote:

---

if this is true, (i didn't check this yet)
that only the first pass there is a translation,
.net app can run pretty fast.

---

As I said in my last post, I'm sure that is not what happens. The .NET code gets interpreted by the JIT compiler every time the program runs. You can use an MS tool called NGen to create a native image of a .NET assembly but very few .NET developers use it.

EDIT: Here's a quote from an MSDN article that clearly states that the code is JIT'd every time a .NET process is launched:

Quote:

---

Originally Posted by http://msdn.microsoft.com/en-us/magazine/cc163808.aspx

As you know, the just-in-time (JIT) compiler is used for compiling the Microsoft intermediate language (MSIL) code in a .NET assembly into native code for the local machine immediately before the code is executed. This is temporary code; it is created and stored in the running processes's memory space, which is reclaimed by the OS when the process dies. Thus, it will be regenerated each time a new process needs it.

---

Native code is not always better, which is why .NET was created. Keep in mind that back when .NET showed up, MS was concerned that Java would run on any platform. This is done by creating an intermediate byte code language, and providing a virtual machine that will take the byte code and turn it into machine language on the architecture of choice. In theory, this would mean that you could write a program that could run on Mac (this was pre-intel Mac, so it was a whole different processor architecture), Windows, Linux, or whatever, as long as there was a virtual machine that could convert the intermediate language to machine language. In practice, this has only been moderately successful for either .NET or Java, but the theory is sound. So .NET came about at least partly out of MS fearing competition from Sun in the dawning internet age. Perhaps one day the promise of "write once run anywhere" will bear out. Alternatively, every other OS might emulate Windows so that it can run Windows apps. Stay tuned.

Ultimately, though, MS did the right thing by having the JIT convert the IL (Intermediate Language) to native, and store it that way, or else the speed really would suffer. In theory, at least, the performance of the program after that first run is entirely dependent on the quality of the JIT. The IL looks very similar to x86 ASM, not in the instruction names, but in the steps taken. Modern C compilers can produce code that is better than all but the best hand optimizers can create, so hand optimization of C code seems to be a dying art. The same might prove true for higher level languages like .NET, as well, especially with the heavy emphasis on parallel processing that showed up in framework 4.0. After all, it is nearly impossible (though not quite) to make full use of multiple processors in a VB6 program. Nor does my GA make use of multiple cores, but if I re-wrote it so that it did, then it would run FAR faster than the VB6 version on my quad core processor, because it runs at least as fast on a single core, and could easily be spread to multiple threads.

Quote:

---

Originally Posted by chris128

As I said in my last post, I'm sure that is not what happens. The .NET code gets interpreted by the JIT compiler every time the program runs. You can use an MS tool called NGen to create a native image of a .NET assembly but very few .NET developers use it.

EDIT: Here's a quote from an MSDN article that clearly states that the code is JIT'd every time a .NET process is launched:

---

That doesn't quite square with the behavior I have seen. However, it is entirely possible that I wouldn't know. The key is that once the JIT has compiled the code to native, it is native code running. Therefore, if you are in a loop, the loop has been converted to native, and is not re-converted each time through the loop, as would be the case for a true interpreted language.

Ah well that's different to what you said originally ;) but yeah, I believe that if you run a method (so it gets JIT'd) then it wont get JIT'd again if you run that same method a minute later... unless you killed the app and launched it again in between.

Quote:

---

However, it is entirely possible that I wouldn't know

---

Yeah I'm afraid I believe MSDN over you :) nothing personal :D

Missed your earlier post entirely, by the way.

It is often the case, in my experience, that the first time I run a .NET program, it has a significant pause on startup that never happens after that. It is so common that it seemed to happen with ALL .NET programs, though I can't categorically make that statement. I always assumed that the JIT was caching the compiled code on disc, and that the pause was the initial JITing of the IL. If that is not the case, I will have to pay more attention to those pauses, to try to figure out why they happen.

If its the first time you have run any .NET application since booting the machine up then there will be a pause, as a lot of the core .NET DLLs (which are quite large) have to be loaded from the GAC for the first time. After that initial loading, some of them remain cached in memory so its quicker the next time you use a .NET app. Other than that its just the same as when you run any program - the first time it always takes longer to load than subsequent times because of the fact that data is cached from the previous run.

Quote:

---

Originally Posted by Shaggy Hiker

Missed your earlier post entirely, by the way.

It is often the case, in my experience, that the first time I run a .NET program, it has a significant pause on startup that never happens after that. It is so common that it seemed to happen with ALL .NET programs, though I can't categorically make that statement. I always assumed that the JIT was caching the compiled code on disc, and that the pause was the initial JITing of the IL. If that is not the case, I will have to pay more attention to those pauses, to try to figure out why they happen.

---

the answer for that is on my link above.

Getting back to the basic (sic) question:

Quote:

---

Originally Posted by ARB_Rauf

Can anyone tell me that VB6 is still in use of programmers because I am going to learn programming as hobby also confused what version learn to start with whether VB6 or VB2008?:)

---

Yes VB6 is still in use.

If you are a hobbiest then learn whichever version you want to. If you have no knowledge of Programming in Basic, then start with a .NET version since they are 'current' (one of the Express Editions which are free, VB6 and previous are not free) Google for examples as and when required or look in the Code Bank here.

Performance and speed are not relevent to a hobbiest, the key thing is the satisfaction of creating something that you have desgned and implemented to solve a given problem. Efficiency and things like speed can come later.

Your first few programs will be (technically) terrible, but as you learn more techniques they will get better.

Have fun, and enjoy yourself creating whatever programs you want to.

Quote:

---

Originally Posted by Shaggy Hiker

That link would be much more useful if it was relevant.

---

I reckon that link was in response to my question not the argument that seems to be taking place in this thread.

Quote:

---

Originally Posted by Nightwalker83

Yeah, but we still have about ten years of Win7 to look forward too.

---

I joined VBForums in 2008 and I had friends tell me it was on it's way out then, so how can it have been released in 2008? Please educate me.

http://support.microsoft.com/lifecyc...&y=10&p1=14498

Extended support date hasn't been published. If you're to go by Windows XP dates (http://support.microsoft.com/lifecycle/?p1=3223) then we can expect 7 to be supported until 2020.

As a side note, 7 went RTM on July 22nd 2009.

Quote:

---

Originally Posted by doramide7

I joined VBForums in 2008 and I had friends tell me it was on it's way out then, so how can it have been released in 2008? Please educate me.

---

I think I already answered the exact same question by Renovator! Anyway, reading post #20 onwards here may help you understand what I was referring to.