I apologize in advance if this comes up frequently.

I am writing a program that will sum all permutations of a set of numbers to see if any of them add up to a specific target. It is strictly a number cruncher, and no fancy GUI is needed.

I originally did it with visual basic (because it is what I'm most familiar with) while running windows XP. Needless to say it is slow as hell, and it takes the program over an hour to do this for a set of 20 numbers. I was hoping to use it for sets of up to 100.

I'm thinking of porting the code to C and, for the first time ever, scrapping XP and converting a pentium4 laptop I have to linux, a project the computer geek in me has wanted to do for years.

Before I start this task though, can someone give me advice or insight on how much extra speed this will give me? Is it worth it?

It seems like using the simplest operating system on a fast machine using a fast programming language will speed things up quite a bit. Will it be enough speed to rationalize the work involved?

Thanks in advance.

Good questions. I don't have any results of studies or any percentages to throw to this forum but there is good reason to doubt if C coded solution would run noticeably much quicker than the VB solution for this kind of a problem(+you could always benchmark yourself your particular situation). VB is a language which is compiled into Microsoft Intermediate Language (MSIL) which in turn is executed by .NET JIT compiler at runtime. What this means is that at the run time ,just before execution, the MSIL-code is compiled into real machine code. This compilation does cost some execution time but then it is also cached by the JIT for the probability that the same piece of code might be needed soon again.

Typically such algorithms like calculating permutations run in a loop and therefore once the MSIL is compiled to machine code it will run in processor with maximum possible speed. The next question might be : Perhaps C is compiled to more "tight" machine code than VB which may be more "loose" and "wastefull" especially if such things as carbage collectors etc. are internally linked in the JIT compiler. Whatever the answer to that question might be I would say that if speed optimization becomes the big issue then with both VB and C there is the possibility to use assembly for maximal speed gains.

Before going headfirst into assembly I would however recommend to mathematically and computationally optimize the algorithm as much as possible. Instead of "brute force" try to make it smarter. If possible.

Even if VB may be as quick to run in this case as the C solution there are other reasons which may make C more appealing. VB depends on .NET with huge libraries and runtime JIT engine in order to execute. In many cases this is unnecessary clutter and hog for resources like memory and disk space and indeed is also slower when a lot of memory management and usage of OS resources is involved. Also for almost any platform there exists a C compiler which can target that platform while VB applications can be only created for those platforms having .NET runtime (or some compatible like mono).

Finally the question if it is worth your while it really ultimately depends on you. If the goal was just simply solve one problem once then, well you did it already. If you want to optimize a function which you created and you think you probably won't be needing much low level programming in the future then you can opt for either mathematical improvements of your algorithm or you could also study languages like Python or Java. Which are both o-o but without the frustration factors inbuilt into VB syntax. However if you want to learn the ability to write low level code and maybe just have fun in low level understanding then it may definitively be worthwhile to learn C. And if developing for embedded systems C is still a commonly enough used language despite that in many visions it has been predicted that C language will face extinction as c++ or some other o-o language will completely replace it.

Hey, thanks for the well thought response. That is interesting, I guess I'm dating myself. I always thought VB was a relatively slow language. I thought that's why most games, etc, are programmed in C or it's big brother. But then, I haven't messed around with programming much since the 90's. Maybe VB has caught up.

Also, I thought All programming languages were translated into machine code at runtime. Isn't that what compiling a program is, essentially?

I don't know about assembly. LOL. I already know C and VB. I don't know if I want to teach myself a new language, especially that one.

Well, this is more complicated than a simple no or yes. VB can still be ineffective to use for games. Programming is not just about your code it is also about resources you use. VB is designed "lego" approach in mind where the typical financial analyst drags-and-drops his applications together from ready-on-the-shelve graphical widget components. Such components can hardly be very efficient for games or similarly performance critical purpose. Programming something that goes against the design ideology of VB is maybe possible but lots of trouble.

Not true. e.g. C language is translated into machine code in the development phase by the compiler. The binary executable which is executed by user is already in machine code and doesn't need further translation at runtime.

Programming languages and execution models can be categorized in three categories (or maybe even more exists?):

• Languages compiled to native code. e.g. C, C++. Compiled at development phase into native machine code.
• Interpreted languages. e.g. perl and javascript. No compilation. 'program' is actually a script which is read at runtime by the interpreter line-by-line. Different interpreters may choose to implement the desired effects differently.
• Languages compiled to virtual machine code. e.g. Java, also .NET languages including VB. Tries to combine the benefits of both worlds. Native binaries are efficient at runtime but not portable and interpreted scripts are portable but not efficient. So the source code is compiled into a virtual machine code aka bytecode. Bytecode is designed so that it should closely resemble real machine code. At runtime there is two options to run bytecode : by interpreter or by JIT engine. Interpreting means there is a simulation going on but JIT improves the situation by compiling the byte code into native machine code before it needs to be executed. JIT removes the simulator layer and JIT compiled native code should be (at least according to theory) almost as efficient as native code which was created at development phase. However the JIT compilation itself since it happens at runtime will take processor time.

Besides; usually that is the very last step to make in order to squeeze those last drops of juices out of the processor.
Are you at liberty of showing the permutative algorithm you are using? Preferrably written in pseudo code rather than VB.

You can embedded assembly inside C code to improve speed and processing time.