You seem to be missing the point that you can build C++ apps without using .Net.
Printable View
When you start optimizing I strongly suggest you analyze the core algorithm to establish what you're actually dealing with. The use of recursion indicates it's a combinatorial problem. When naively implemented they often suffer from the so called combinatorial explosion and become almost intractable. You must come down from exponential to polynominal complexity. It won't help to throw hardware at it.
That may very vell be enought to take care of the performance problem. Of course you should utilize all cores but don't start there for that alone is unlikely to make much of a difference.
A supplementary question ("debugging a vc++ 6.0 dll called from a vb.net routine")
At the moment, using the program written in vb6 which calls my dll written in vc++ 6.0, I can trace through the dll line by line by using Ctr F10 etc - perfect, no problem
Before I move to vc++.net (yes, that seems to be the route) I had hoped that I could trace through the vc++ 6.0 dll when called from the debug version written in vb.net but it says ".exe does not contain debugging information" despite the fact that there is a pdb file generated by the vb.net compiler in the same folder as the exe file.
So, is this possible? If so, what do I need to do?
Thanks in anticipation
if you are going to convert your app to .NET, as in, using the .NET framework: then you will loose performance and gain UI integration benefits.
C++ en C++.net/cli while similar, are essentially different languages.
I'm not into VB, but i believe, VB has dropped support entirely for non .NET based apps. So if you're going VB, it's .NET or nothing.
Your VC 6.00 code may need some changes to compile properly, there's been some changes to the language syntax, and a lot of old libraries have become obsolete. They're still there, but you'll get obsoletion warnings. Typically speaking, you want to clean those up.
If your code currently runs as a single thread on a single cpu... Then while parallellizing may be a fantastic speed improvement, you won't be getting this for free. This is going to be a big undertaking, and depending on the problem, may not even be possible at all. It depends how your app works and what it does.
It's close relation multithreading is typically easier to conceptualize but again, may not be feasible.
Countrary to myth, multithreading, parallellizing and using the GPU code (cuda ?) are not about improving speed. On the countrary, the speed usually goes down because of the extra management and need to synchronize. It is however about getting more overall throughput. Some problem domains don't lend themselves to increased throughput.
And repeating myself, going to (inline) asm doesn't really benefit you unless you can put a computationally significant amount of code in the single block of (inline) asm. If your asm is 1 or 2 instructions, then you'l get all the disadvantages and none of the advantages.
the exception would be the handfull instructions the compiler doesn't use, but... Those tend to be the slow instructions (taking multiple clock cycles), that either don't allow running in parallel in the CPU pipeline or which stall the CPU pipeline. So those single 'complex' instructions tend to eat up the equivalent of a handfull of simpler instructions. So you're often still better off letting the compiler do the work for you.
Like I said before, get your program to work first, worry about optimizing later (by profiling and optimizing the bit that matters).
Why don't you write it in MOPEKS instead? :)
Just kidding but if it's MOPEKS we're dealing with here than it's most likely a combinatorial problem (I've suspected in my previous posts). In that case I strongly suggest you go back to the drawing board before you continue because you most certainly have an NP-hard problem on your hands. No amount of hardware and micro-optimizations will fix this. You need an algorithmic solution.
I suggest you start over and work out a solution strategy to MOPEKS that is tractable before you continue. It's not enought to have something in principle. It's easy to say:- "generate all combinations and pick the best". This works in theory and in principle but not in practice. Not in multidimensional combinatorial search space. You must get down to polynominal complexity.
Furthermore for a project like MOPEKS I don't think .NET is the optimal platform because it's not portable. I think you should seriously consider Java or a native C++ with Qt combination. It will work on many platforms including Windows too so why limit yourself to Windows only?
So don't just port. First come up with a feasible solution and then make a proper new design based on your experience with the old program. Otherwise the project is doomed. Good luck.
--- double post by mistake ---
Unless the problem is defined incorrectly, NP (hard) problems tend not to have algorithmic solutions (or rather "none have been foud yet").
In that case, parallellizing is a feasible solution to try more possibilities in a given timeframe.
Small scale, this could be a rack of CPU servers.
Larger scale, this could be an elementary grid.
Massively scaled up, it could be a global effort.
There's a reason why we have such stuff like SETI@Home, Protein (un)folding and lots of other internet based efforts. It is by no means ideal, but it is a way to chop off a few digits in the total computation time needed.
Many NP (hard) type problems find "adequate" solutions using genetic algoritms, or "ant colonies" or other similar. In that case, parallellizing/sharing the computation means you can try significantly more combinations and find better results within the same amount of time.
In 20 years that may be possible! MOPEKS works by finding a program that fits the data so here is some data
1, 1
9, 3
144, 12
Clearly, this is square roots and here is the program that MOPEKS came up with this morning from that data
It can then go on to build a whole stack of programs using each program it has generated so far until you get something like:Code:double _stdcall SquareRoots(double R){
// Problem Description: '02 Square Roots'
// Generated by MOPEKS at 9.35 am on Tuesday 5th August 2014
// Initialise variables at zero
double ax = 0;
double bx = 0;
double cx = 0;
double dx = 0;
// 64 bits in Hex 1 2 3 4 5 6 7 8 9 10 11
// Type LHS EPrp Opr RHS1 Prop1 RHS2 Prop2 Goto Method Steps
Line1: ax = 3 - R; // &H9208B5C4187A8CBC 4 0 1 1 5 14 4 3 3 40 94
Line2: cx = R / ax; // &H18DBB330669188DB 0 2 27 3 4 25 0 12 4 24 109
Line3: ax = cx + ax; // &H1000080048200002 0 0 0 0 2 0 0 9 1 0 1
Line4: ax = ax / 2; // &H9009A0A7443D179E 4 0 1 3 0 5 7 8 1 81 79
Line5: if(cx < R / ax)goto line2; // &H5937F1B01820D033 2 2 6 3 4 13 0 3 1 13 25
out: return ax;
}
I believe this is the correct route to artificial intelligence ... as a friend of mine remarked "if you are right, this is the most significant thing since the origin of life 4 billion years ago". So, no pressureCode:Private Function R_Orbts_S_AntCl(ByVal R As Long, ByVal S As Long)
Dim ax As Double, bx As Double, cx As Double, dx As Double
1: ax = AnglSbtnddBy2Ob(S, R)
2: bx = 1 - 1
3: bx = ax + bx 'bx is the relevant angle to use so far ...
4: cx = DistBtwn2Objcts(R, S)
5: cx = R.Speed / cx
6: cx = cx / 2
7: cx = ATan(cx) 'cx is the angle correction (to allow for triangle)
8: bx = bx - cx 'bx is the relevant angle to use!
9: dx = Return180()
10: bx = bx + dx
11: ax = Cos(bx)
12: ax = R.Speed * ax
13: ax = ax + R.XAxis
14: ax ==> NextStep(R.XAxis)
15: ax = Sin(bx)
16: ax = R.Speed * ax
17: ax = R.YAxis - ax
18: ax ==> NextStep(R.YAxis)
End Function
Well, the programs evolve in a breeding pool and this is classic Genetic programming. Where I have extended it is the programs using each other and attach themselves to objects which interact in an environment - if you want to see more see the website. Bear in mind this is fully operational, you can download and install a fully working version for free - this is not about making money, it is about promoting an idea.
Once I have got the .net versions working the next step is a camera trained on an interactive situation (eg a billiard table) and it will derive programs that have predictive power ie which ball will go where and the ideal angle etc
A bit late now - this has got 35,000 lines of code written by me and has taken me almost 20 years so I am stuck with what I have!
Well, maybe if others think the basic principles have merit but if I am the sole person working on it that will not happen - I will die of old age first!
That's not true. Also NP-hard problems have algorithms that solve them, just not in polynominal time (what hasn't been found yet is a formal proof of this).
My point is that if the OP is trying to solve a problem in this category it's futile to just throw more and more hardware and micro-optimizations at it. This won't do. The problem must be approached at a more fundamental level. I called it algorithmic because the purpose is to find a solution based on a polynominal time algorithm. It could involve relaxing or reformulating the problem or seeking approximate solutions, etcetera, whatever it takes.
Why not allign your ideas with other ongoing research in the same area. Check out this for example,
http://www.cgchannel.com/2014/01/coo...on-for-bipeds/
Before you continue putting more effort into this old program of yours I think you should step back and have a hard look at your approach. Maybe it's not that novel after all and maybe others even are ahead of you?
I don't want to discourage you but you seem rather bogged down by the program. I know the feeling, it's like abandoning an old friend but sometimes it's better to unsentimentally let go and start anew. It may even allow you to finish sooner. Especially if you graduate from the procedural paradigm and start using object oriented and functional techniques part of modern languages. A program whose purpose it is to induce flexibility in the programming process should reflect at least some if this in its own design I think. It looks like the program itself is delaying the project. A redesign making use of modern design methods seems long overdue.
So this is what I suggest you do at this point instead of just trucking on:
1. Reality check. Allign your project with current research. How novel are your ideas? What have others done?
2. Analyze core algorithm(s). Classify in terms of complexity and devise tractable solutions.
3. Modernize. Bring the program up to todays standard using modern design and programming methods.
Good luck! :)
I have successfully ported my vc++ 6.0 assembly code to vc++ 2010 express and even to C# ..
I had written a device driver in vc++ 6.0 .. as it supports assembly code ..
for vc10 and C# , I made a DLL and imported it in my project .. It worked well
In VC .net is more friendly to handle DataBase. VC6 although it has less graphics design in built facilities than vc10,
it is easy to handle. Or may I am used to it. I am in systems programming and need many dialog boxes .. for which I prefer VC 6 .. Now I will have to port to C# or wpf .. but I may not love that ..
actually, what you're describing about mopeks (I didn't really make out what you intended it to do)
sounds a lot like Eureqa of which a demonstration program was released in 2009 and usable versions for other scientists have been available for a few years. (even better, it's absolutely free).
You feed it datapoints, and it finds the equation(s) that fit the data.
It sounds similar to what your mopeks appears to want to do, but it's incredibly fast. It finds a solution for a double pendulum in a matter of hours. (this is several orders of magnitude more complex than a square root).
It is a feat in itself to make a proper simulator for this, then think about reversing the output of the simulator back into it's input of pendulum lengths and mass and gravity.
Since it's now known that the OP's question is not about any program but specifically about MOPEK and because the OP is referring to this project in every one of his post, I feel it's okay to comment on this project.
There is so much lacking in the MOPEK project. The most troublesome aspect is that there is no scientific basis for it. There is no theory, only "views" based of quotes from authority figures in science taken out of context.
And the approach is also troublesome. There's no theory that can be tested up front, instead a program must be developed. This has been going on for 20 years already and is expected to go on for another 20 years still before any results can be expected.
I think this is nuts and has become an obsession on part of the OP. Other research is ahead already as I've shown in previous posts.
In saying this I agree with the OP who is anticipating a "negative reaction" to his project. (In fact it's the first time I fully agree with anyone at this forum.) Hopefully he reconsiders, but regardless, I wish him good luck in pursuit of his happiness.
Well, I didn't come here to argue about the merits or otherwise of Mopeks but after that comment I have little choice but to reply. What I am trying to do here is move a FULLY OPERATIONAL program from VB6 and VC++ 6.0 to .net
My fundamental contention is that a program which generates programs is the correct route to AI but you are totally free to think I am deluded (and doubtless that is what you do think)
As for no results for another 20 years, it ALREADY solves generalised problems concerning the interaction of objects. To spell it out
"It is my contention that:
The major use of simple human intelligence is the solving of problems whether they be of survival, finding a mate or just making a cup of coffee.
These problems normally involve the interaction of objects in a particular environment - eg in making a cup of coffee the environment is the kitchen and the objects concerned are you, a kettle, cup, teaspoon, coffee, sugar, milk, etc. The 'problem' may be to make the cup of coffee with the minimum amount of movement.
I believe a human being is a computing machine which can copy, learn or generate procedures which enable it to solve such problems. It is this ability which gives human beings their enormous degree of flexibility compared with animals - birds can build beautiful nests but would struggle to make a hat.
Similarly, "normal" computer programs written by human beings can only cope with events which have been anticipated by the person who wrote the program - a bridge playing program cannot play poker. To this extent, they are like animals.
The procedures which human beings copy, learn or generate, in turn use procedures which have been previously acquired. When you pick up a cup you are using dozens of procedures concerned with the estimation of angles, distances, gripping and co-ordination that you have learned previously.
'Understanding' and 'comprehension' (I believe) come from having an internal simulator which can reproduce the actions of objects and can therefore be used to make predictions and also evaluate alternative strategies.
Mopeks is built to imitate human intelligence insofar as it uses Genetic Programming to generate computer programs which can use each other to generate further computer programs in an endless upward progression of ever-increasing sophistication.
At its most sophisticated, it enables an "intelligent" object to solve problems which involve actions of objects in a particular environment. For example, the problem may be to avoid being eaten on the plains of Africa. Or maybe plan a seating arrangement to minimise the extent of arguments between guests with strongly held but opposing views (eg Razzle and myself)
It is a generalised problem solver and it is my belief that it is the correct route to real machine intelligence. "
Incidentally, in terms of speed, it will often find functions in less than a second eg "Sum of Integers". Square roots maybe a few minutes. The problems that may take days are those of an object in an environment (eg Cassius tries to murder Caesar in an optimum manner or maybe Flash Gordon is using the gravitational effect to intercept an object in space). It will usually find a solution in an hour or so but the optimum solution may take days.
I have now effectively removed my signature to avoid any offence ...