.NET or VC++
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
hi Do you have an sample main ? I want to optimize this function. just for fun ... I would like to speed up this code. Long life to C/C++ Fred
-
Hi, I am puzzled? I come from a .NET background but am currently engaged with VC++ (COM/ATL) at my current organization. Now, I am ina dillema. Should I go fill flegded with VC++ or keep uptodate with .NET too. Will VC++(COM/ATL) stay for some more years or will it be eradicated by .NET? What about MFC?
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise
Hey I think that the C++ will surely exist for couple of years in future as a kind of native language to do some low level development where the run-time efficiency is more important than developing efficiency. But MFC might not be pretty a perfect thing, and I don't think that it is one of the best GUI developing helper amoung varieous kinds of programming language. Cheers one to two, two to three, three to everything
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
-
sorry, but your algorithm can be rewritten (without assembly code) to work as twice as fast. that makes your test unrealistic and don't get me wrong, I believe .NET is the future for most applications PeroB
any suggestions you may have would be appreciated i am always interested in better algorithms
-
hi Do you have an sample main ? I want to optimize this function. just for fun ... I would like to speed up this code. Long life to C/C++ Fred
below is what i tested, threw it together the binarysearch function is the only one i thought about trying to optimise, the code is from a .h and .cpp file just copied and pasted would be interested in anything you do could probably change the string compares, but i want them to be case sensitive haven't thought about it too much, didn't like the casting but didn't have time to think about it #include #include #include #include #include #include using namespace std; void run(); void QuickSort(string* a, int lo0, int hi0); void swap(string* a, int i, int j); int binarySearchRecursive(string* a, string* value, int left, int right); int binarySearchLoop(string* a, string value, int left, int right); int _tmain(int argc, _TCHAR* argv[]) { run(); return 0; } #define MAX_NUMBER_OF_WORDS 500000 #define MAX_LENGTH_OF_STRING 20 #define WORDS_TO_SEARCH_FOR 40000 #define MIN_LENGTH_OF_STRING 3 string* strings; void run() { clock_t startTime; clock_t endTime; string characters[] = {"-", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z"}; int i; int j; int lengthOfString; strings=new string[MAX_NUMBER_OF_WORDS-1]; for(i=0;i
-
Gary R. Wheeler wrote:
Windows services
I'm sure they can be done in C#
Christian Graus - C++ MVP
Already have to wait for the PC to start, loading all the services. Do you imagine what it would be like, if each service loads a 25 MB runtime? :omg:
-
any suggestions you may have would be appreciated i am always interested in better algorithms
I considered that 'left' and 'right' are always positive when the function is called. int new_binarySearchLoop(string* a, string value, int left, int right) { int mid; int result; const char *search_value = value.c_str(); while (left <= right) { mid = (left + right) >> 1; result = _stricmp(search_value, a[mid].c_str()); if (result < 0) left = mid + 1; else if(result > 0) right = mid - 1; else return mid; } return -1; }
-
Todd Smith wrote:
- Any application where performance is an issue
Supposedly that's no longer the case. I've seen a number of articles where managed code is faster than the equivalent native code. The rationale is that the just-in-time compiler and loader can perform whole-program and load environment optimizations that yield greater performance than is possible with a 'static' compiler and linker. I'm willing to believe it on a case-by-case basis, but I have my doubts under general circumstances.
Software Zen:
delete this;Gary R. Wheeler wrote:
I've seen a number of articles where managed code is faster than the equivalent native code.
I've had two interviews in the .NET era where the interviewer told me that apps. they had ported to C# from C++ were faster as a result. Ultimately this must be down to a combination of better design and the things you mention. I've also read a case study where an app. ported from C to Eiffel (another language with GC) was 10 times faster as a result. Eiffel however compiles to C, so this is really C vs. C. But the greater abstraction of Eiffel obviously enabled a more efficient implementation than could be obtained in straight C.
Kevin
-
I'm going to go against the flow here. While I think there are many places where .NET is the way to go, I just can't see it replacing C++ for all new apps. Large categories of apps are going to be on C++ for a long long time. And yes, I know of new apps being written in unmanaged C++. I've been looking at some time critical apps. While I'm skeptical about claims of .NET going faster then well written unmanaged C++ using a good optimizing compiler I'll pass on that because it's not my main concern about .NET My main concerns are these: 1. The garbage collector. If you're doing a little database app (retrieve stuff from the database, display it, let the user edit it, put it back in the database) or something like that it's no big deal. If you're doing a time critical app which CANNOT EVER halt to do GC I'm skeptical. I know there's things you can do with the GC to keep some of it's problems in check, but they seem to me to be overly involved compared to just being able to do delete when need be. You don't need to be an expert on heap management to use delete, you do need to know a lot about the garbage collector to keep it from shooting you in the foot sometimes. Yes I know the C++ heap can become fragmented and the GC can relieve that issue, but it's been my experience that fragmentation is hardly ever a problem, and on those RARE occasions when it is there are ways to relieve it without chucking the whole thing and using a garbage collected language. 2. I have to give up control in the memory representation in .NET which often makes it hard to write good code. C++ lets me specify exactly how an object is handled in memory -- whether on the heap or stack, passed by value or reference, const reference, whatever. With C# several times I have found myself fighting the language just to get it to produce something halfway reasonable. 3. Portability is out the window. If you're in a mixed Unix/Linux/Windows shop like I am you're going to have problems in .NET even if you're writing managed C++, whereas if you stick to ANSI unmanaged C++, portability is often very manageable. Until MS can convince other OSes to use .NET this is going to be a serious problem in some environments. 4. It's been my observation that the problems .NET always trumpets as having solved aren't nearly as bad as they make them out to be and the problems it introduces are, in some situations far more serious. I am quite capable of using delete for example but the loss of control is sometimes nasty. Yes there's many
Goriax wrote:
While I think there are many places where .NET is the way to go, I just can't see it replacing C++ for all new apps.
Is anyone claiming this? The OP raised the issue of .NET or VC++. This pretty much presupposes an MS environment. Given that it seems fairly clear that the scope for new C++ apps. will be increasingly delimited. But of course there are still plenty of scenarios in which it is the best solution.
Goriax wrote:
My main concerns are these: 1. The garbage collector.
Why are almost all new languages designed with GC or a similar memory management scheme? It's because the advantages outweigh the disadvantages. Of course there are always scenarios where greater flexibility is required. There are tradeoffs, as always. But I generally prefer having GC to not having it. I've yet to work on a reasonably sized C++ app. that doesn't have non-trivial memory management problems. Also, we need to distinguish between. 1. Not being competent enough to do memory mangement properly. 2. The ordinary human propensity to make mistakes. The rationale for GC is 2, not 1. With unmanaged languages 2 leads to buffer overrun security vulnerabilities and the like. Almost every important distributed application written in C++ seems to suffer from this. Also, GC enables separation of concerns. We can focus more on the business problems we want to solve rather than book-keeping.
Goriax wrote:
3. Portability is out the window. If you're in a mixed Unix/Linux/Windows shop like I am you're going to have problems in .NET
You can always try Mono, provided you're not insistent in having the very latest features of .NET at any time. An alternative is Java, of course. And if you find that too slow, Eiffel is cross-platform and gives equivalent performance to C++.
Goriax wrote:
Yes there's many ways of crashing your app in C++. Happens all the time. But those obvious blunders are also easy to fix, if you know the language.
I think I know the language reasonably well, and they're not easy to fix. And I'd much rather spend time fixing bugs in business logic.
Goriax wrote:
I'm very intrigued by .NET and I agree that anyone in the MS world must be familiar with it.
Yep, that's the main thing.
-
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++. They will be around for decades to come (eg COBOL programmers are still required). A company which has invested $millions in C++ software development is not going to chuck it all away just because something new has come along. I reckon it's easier to go from C++/MFC to c# than vice versa.
Ian Semmel wrote:
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++.
That's right. But if you aspire to something more than just boring maintenance programming...
Kevin
-
Ian Semmel wrote:
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++.
That's right. But if you aspire to something more than just boring maintenance programming...
Kevin
-
I considered that 'left' and 'right' are always positive when the function is called. int new_binarySearchLoop(string* a, string value, int left, int right) { int mid; int result; const char *search_value = value.c_str(); while (left <= right) { mid = (left + right) >> 1; result = _stricmp(search_value, a[mid].c_str()); if (result < 0) left = mid + 1; else if(result > 0) right = mid - 1; else return mid; } return -1; }
moved your changes over to the recursive version and it was even faster binarySearchRecursive doing the stricmp twice was just a stupid mistake on my part, but i assumed that c++ would automatically optimise the divide to a shift and remove the casting, now i know thanks
-
moved your changes over to the recursive version and it was even faster binarySearchRecursive doing the stricmp twice was just a stupid mistake on my part, but i assumed that c++ would automatically optimise the divide to a shift and remove the casting, now i know thanks
never assume that a compiler always optimises. ;) According to the options which one can choose, it or not will do it. Thus always to prefer to test. Else ask to the compiler to generate assembly code, and check it directly. example with a part of binarySearchLoop before with use of 'floor' function --------------------- ; 230 : { ; 231 : //mid = (left + right) >> 1; ; 232 : mid = (int)floor((float)(left + right) / 2); 0002e 8d 14 1f lea edx, DWORD PTR [edi+ebx] 00031 89 54 24 10 mov DWORD PTR tv297[esp+24], edx 00035 db 44 24 10 fild DWORD PTR tv297[esp+24] 00039 83 ec 08 sub esp, 8 0003c dc 0d 00 00 00 00 fmul QWORD PTR __real@3fe0000000000000 00042 d9 5c 24 18 fstp DWORD PTR tv295[esp+32] 00046 d9 44 24 18 fld DWORD PTR tv295[esp+32] 0004a dd 1c 24 fstp QWORD PTR [esp] 0004d e8 00 00 00 00 call _floor 00052 d9 5c 24 18 fstp DWORD PTR tv289[esp+32] 00056 83 c4 08 add esp, 8 00059 d9 44 24 10 fld DWORD PTR tv289[esp+24] 0005d e8 00 00 00 00 call __ftol2_sse 00062 8b f0 mov esi, eax ; 233 : result = _stricmp(a[mid].c_str(), search_value); --------------------- After, without 'floor' function --------------------- ; 230 : { ; 231 : //mid = (left + right) >> 1; ; 232 : //mid = (int)floor((float)(left + right) / 2); ; 233 : mid = (left + right) / 2; 00030 8d 04 1f lea eax, DWORD PTR [edi+ebx] 00033 99 cdq 00034 2b c2 sub eax, edx 00036 8b f0 mov esi, eax 00038 d1 fe sar esi, 1 ; 234 : result = _stricmp(a[mid].c_str(), search_value); --------------------- After, without 'floor' and direct shift --------------------- ; 230 : { ; 231 : mid = (left + right) >> 1; 00030 8d 34 1f lea esi, DWORD PTR [edi+ebx] 00033 d1 fe sar esi, 1 ; 232 : result = _stricmp(a[mid].c_str(), search_value); --------------------- if this code is used some times in an application, it is not very important, but if it is used several million times, it is important.
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
A couple of quick things you can do to speed up this algorithm. No you don't need to resort to assembly either. 1) Why are you converting your mid place holder to a float just to do division? mid=(left+right)/2 is all you need. No need for a conversion routine and a call to floor. 2) Recursion has a lot of overhead associated with it too. Convert it to an iterative loop and you should pick up more speed. In this case you would be trading complexity for speed. Only the developer can really decide which is more important in this case. That is the two simplest things you can do. Other thing you can use is pointers instead of array indexing. If you are looking for simple you can also try the binary_search template that is part of the STL. I don't know how it would compare to the VB benchmark but may be worth exploring.