Printable View
Hi all,
I am using C on purpose but it is slower than say java to develop code in C. However i think that if I write my code in C it will be the fastest. May be only assembly can beat C in speed. I think C is also faster than C++.
So I need some positive feedback saying that C will be indeed fastest. So I can continue the slow paced development in C.
:)
I'd rather go with C++. It can be as fast as C, depending on what you do, although it may be a bit slower. However, it is also much faster and advantageous to develop in for most applications over C. I don't think the speed hit compared to C really matters (it's nowhere as slow as java or dotNet, etc).
But yes, C is faster than other languages, but also the hardest. Remember that C means a lot of security issues unless you develop good code and take extra care not to run into any security issues.
It would be easier to develop code in C++. It MAY be slower (depends which compiler you use...on a decent one the speed should be almost identical). C is definately faster than Java, VB, VB.net, C# and any other interpreted language. You should be more worried about how much faster it is, rather than it just being faster.
Some have the opinion that Java is better than C++ in terms of speed.Quote:
Originally Posted by Elysia
*poof*, There goes his credability.Quote:
Some of the C++ tests would not compile. I've never been very good at decoding GCC's error messages, so if I couldn't fix a test with a trivial modification, I didn't include it in my benchmarks.
Not to mention it was only level 2 optimization
While javac will optimize as much as it can.Quote:
g++ [test].cpp -O2 -march=i386 -o [test]-386
See http://zi.fi/shootout/ for a response to that benchmark :)
I know another fellow who has shown that PHP beats Java in terms of speed in a specific benchmark :DQuote:
Some have the opinion that Java is better than C++ in terms of speed.
To properly answer Jackie Chan's question, we need to know what he is developing, since only then we can help to guage which language is the appropriate tool for the job.
Not to mention that some of the tests are needlessly complicated. The methcall example doesn't even need a virtual destructor.
C/C++'s efficiency also comes with the flexibility. Just stuff some code in there and it's sure to be slow.
Don't trust the info on that page. It's written by a java programmer that doesn't know what they're doing with respect to C++. They tend to use dynamic memory allocation for stuff that no sane C++ programmer would use dynamic memory allocation for. When the code was changed to allocate on the stack instead, then the test ran so fast that the timing didn't even register above zero.Quote:
Originally Posted by stevesmithx
Not to mention they used a pretty old C++ compiler and didn't use the best optimisation settings either.
If you want the real story then the page below runs the same code on a newer compiler, with a few fairness changes, and gets results with C++ easily outperforming java by a factor of two or three.
In Summary some will always be wrong.
C or C++ are only faster because they're lower level though. With lower level programming comes more responsibility and more ways to shoot yourself in the foot. Don't feel you have to port your code to C or C++ unless it is definitely too slow. Even then, ask some java gurus for help first too.
I think C is faster since it is very low level and that is why it is taking longer to develope something. But may be it will help me learn more. My only worry is people may not be using it any more for new projects. There may be only old maintained code in C.
C++ can be as fast as C and is much easier to use. And you shouldn't be that worried about performance C vs C++, because you'll not notice it. C++ can deliver blazing speeds, as well.
C is necessary when it comes to the real resource lacking environments that cannot support C++ or where it is even more necessary for full speed.
C will give you a headache in big projects, but with C++ it's manageable.
Anyway, what are your plans? What do you intend to do?
That said I never noticed speed difference between C and Perl either. :)Quote:
Originally Posted by Elysia
Well no such thing as resource lacking though I have 1.5GHz, 512MB,20GB configuration. After huge language base of Perl and complexity of Java the C is like a refresher. So little to learn and understand. And after that just stay awake while coding.Quote:
C is necessary when it comes to the real resource lacking environments that cannot support C++ or where it is even more necessary for full speed.
C will give you a headache in big projects, but with C++ it's manageable.
Plans? :)Quote:
Anyway, what are your plans? What do you intend to do?
Well, it all matters how you use it and for what task. Certainly, a GUI app can be just as fast in both C/C++ and Perl. But for very intensive tasks, C/C++ will almost certainly be better, but yes... it just goes to show you aren't limited to the fastest but most complex language.Quote:
Originally Posted by Jackie Chan
Indeed.Quote:
Well no such thing as resource lacking though I have 1.5GHz, 512MB,20GB configuration. After huge language base of Perl and complexity of Java the C is like a refresher. So little to learn and understand. And after that just stay awake while coding.
If you want complexity, then I would say C++ is a dream for you. The amount of complexity it can amount to in incredible. It can become far more complex than C, even.
But you know, computers, having a lot of resources and all, you can use almost any language you see fit.
Well, what are you trying to do? Web? GUI? Games? Etc?Quote:
Plans? :)
:) GTK is ugly. GTK+ is for C++. I can try with WinAPI. But it is very scary as for now.Quote:
Originally Posted by Elysia
:) I can only write CGI using C. may be I will try that too for Web.
:) I will try to write games using OpenGL+SDL (both C libs).
:) In short all of the above and more.
> GTK+ is for C++
GTK+ is a C library. It's for C, C++, Perl, PHP (there are tonnes of bindings)
> I will try to write games using OpenGL+SDL (both C libs).
Yes, but C++ is a superset of C. You should be able to use most C libs with C++. Not to mention there are many bindings of OpenGL & SDL to other langauges.
I've done everything in your list before, all in C. Some things I longed for C++, or perl -- sometimes even PHP. I like Java, although I don't love it. Choose the language for the job, not one language for all jobs. You don't build a house with just a hammer do you?
I would go with C++. I started with C and changed to C++ a while ago.
Eh, GTK+ is a C library, and it is not the only GUI library out there (though you might find them all ugly, even with skinning, since that is a matter of taste). Perhaps you are thinking of Gtkmm when you say "GTK+ is for C++".Quote:
GTK is ugly. GTK+ is for C++.
There are CGI libraries available for C++, though these days web development is far more common in Java, PHP and Ruby than C or C++.Quote:
I can only write CGI using C, may be I will try that too for Web.
Actually, if you simply want to learn another programming language, all this talk about speed is useless, whether it be the speed of development or of program execution. Just learn the programming language you have in mind.Quote:
In short all of the above and more.
Seeing as you aren't going to write programs for embedded systems or other machines whose hardware isn't top notch, I would say that C++ would give you the best of both worlds since C++ is backwards compatible with C.
Many frameworks are C++-oriented simply because C++ is more suited for such tasks.
But this may all irrelevant to you.
You may try a language and stick with the one you find to suite your tastes best. Perhaps start off with C++ since books often do teach C basics before digging into C++ stuff. Then you can specialize yourself in one language if you want, or learn both.
Anyway, I think that's my recommendation if you want to go the C/C++ route.
I think I was just being a little ignorant and a little over enthusiastic about simplicity of C language.
:)
Speed of development is a compromise. You can have lots of freedom (which often translates to being able to write high-performing code), or you can have a language that gives you lots of functionality - but not quite as much freedom.
C is a low-level language. It gives the developer a good level of control of EXACTLY what is going on. But this also means that the language is quite complex to develop code in - because you need to give the compiler a lot of details of what you want done, and how you want it done, when you want it done, where you want it done, and which colour you want it done in. On the other extreme we have shell-scripts and batch-files for example. They don't allow much flexibility or detail on what gets done - but in a few lines you can write something that does quite a bit of work. However, if it's calculationally heavy, then it's going to take quite a bit of time to complete (assuming you can even express what you want done). And like Ford Model-T, you can have it in any colour you like, as long as black is the colour you like, and it's delivered when it's ready - whenever that may be.
Assembler goes a step further than C, and thus takes even longer to develop code in.
Unfortunately, it's hard to define a language that gives the programmer freedom and control, as well as simplicity in use. C++ gives the user some choices here, since if you want full control, you can use it like C (for the pedants who like to point out that C and C++ do not support exactly the same things, it is ALMOST the same language as C), but you can also use the Standard Template Libraries (STL), and various other "ready made" solutions that give a reasonable compromise between development speed and freedom.
Of course, to write high-speed code, you also need to use the right algorithms - if the programmer uses the most stupid bit of code in highly optimized assembler, it will probably not beat a "slow" language using a fast algorithm. Being clever about things beats having a fast language. We can estimate that the speed-up of a fast language is about 10x that of a slow one (it obviously varies a bit - 2x - 30x would be a likely range). But if we take an example of searching, where we have 1 million items in a list, and the "stupid programmer" chooses a linear search - on average, we will search half the list, so 500000 "hits" on the list. A binary search will do the same in maximum log2(1000000) "hits", which is 20 "hits". So it's about 2500x faster.
--
Mats
C is quicker, but I doubt you would see a big difference unless you are dealing with very large programs.
Thank you for a detailed well explained answer. But I am unable to see the point here. I see no flexibility loss when doing Perl. I want list of file names. Easy. I want them sorted. Easy. I want them based on a pattern. Easy. What I lost here? Flexible also. I can do whatever I want.Quote:
Originally Posted by matsp
I was impressed with how simply a language can be expressed. Which can do do much of stuff. I am not a fan of brain........ language. Which means being small is not my preference. But C being so small and still so useful is what I like. When I say C is slowing me, I mean, for example:Quote:
C is a low-level language. It gives the developer a good level of control of EXACTLY what is going on. But this also means that the language is quite complex to develop code in - because you need to give the compiler a lot of details of what you want done, and how you want it done, when you want it done, where you want it done, and which colour you want it done in. On the other extreme we have shell-scripts and batch-files for example. They don't allow much flexibility or detail on what gets done - but in a few lines you can write something that does quite a bit of work. However, if it's calculationally heavy, then it's going to take quite a bit of time to complete (assuming you can even express what you want done). And like Ford Model-T, you can have it in any colour you like, as long as black is the colour you like, and it's delivered when it's ready - whenever that may be.
in Perl I would read a line like this:
$line = <STDIN>;
In C I had to estimate my longest possible length of line. Then create a char[] large enough. Then after reading from stdin I had to make sure no data was left in input buffer.
But on a positive side, Perl can not write another Perl. C can write many Perl like languages.
Yeah. I just ordered my Pentium* manuals from intel. They are shipping for free. I am really excited about MMX/SSE* struff. I know nothing about them yet.Quote:
Assembler goes a step further than C, and thus takes even longer to develop code in.
Shell scripting is extreme example. It is more of command control language rather than a programming language. But I do not get the point of flexibility loss. Again.Quote:
Unfortunately, it's hard to define a language that gives the programmer freedom and control, as well as simplicity in use. C++ gives the user some choices here, since if you want full control, you can use it like C (for the pedants who like to point out that C and C++ do not support exactly the same things, it is ALMOST the same language as C), but you can also use the Standard Template Libraries (STL), and various other "ready made" solutions that give a reasonable compromise between development speed and freedom.
Yeah. In a book. This was the first thing that inspired me. That think better algorithms first. They will speed up in any language.Quote:
Of course, to write high-speed code, you also need to use the right algorithms - if the programmer uses the most stupid bit of code in highly optimized assembler, it will probably not beat a "slow" language using a fast algorithm. Being clever about things beats having a fast language. We can estimate that the speed-up of a fast language is about 10x that of a slow one (it obviously varies a bit - 2x - 30x would be a likely range). But if we take an example of searching, where we have 1 million items in a list, and the "stupid programmer" chooses a linear search - on average, we will search half the list, so 500000 "hits" on the list. A binary search will do the same in maximum log2(1000000) "hits", which is 20 "hits". So it's about 2500x faster.
:)
> But on a positive side, Perl can not write another Perl.
Sure it can.
Speedwise or coding wise?Quote:
Originally Posted by JFonseka
C++ way:Quote:
Originally Posted by Jackie Chan
So as mats says, C++ gives you high-level functionality for a lot of things, but still allows you to do low-level things such as C, which is why C++ is so terrific (it is also not as prone to security issues such as buffer overruns as C).Code:std::string line;
std::getline(stdin, line);
Obviously speedwise, coding wise it's longer because of the extra manual security you have to add in everywhereQuote:
Originally Posted by Elysia
In this case, flexibility means that YOU can choose how you want to do things, but also have a low enough level of function that you can DO whatever you like. It's no surprise that C is a language with low-level functionality, as it was originally written to be used for porting operating systems (in particular Unix) and the related tools and utilities that the OS needs.
Perl is a flexible language in the sense that it allows you to do many things - but it's flexible at a higher level - it gives you many functions that are pre-defined (or in libraries).
Perhaps flexible isn't quite the right term - detailed is probably a better term to use. The details of what is going on in Perl is vague (as in, you don't "know" what happens when you write- aside of course what it says on the tin: It reads a line of text from stdin - but what the tin doesn't say is what ingredients where used.Code:$line = <STDIN>;
And of course, you can write a function in C that reads a line of arbitrary length. You just have to do the same thing that Perl does: Allocate a small amount of memory (buffer), read a char at a time until either end of line or buffer is full. If the buffer is full, re-allocate a bigger buffer. Keep on doing this until end of line is found. Of course, you will also have to remember to free the string after you've finished using it. The drawback is that you don't get a function like that in C, but the benefit is that YOU get to decide whether it's flexible (here meaning reading as much as you like), or a bit less flexible with regards to the data size and a bit faster in execution (because it doesn't need to allocate and potentially re-allocate [maybe several times] the string).
However, once you have written a input function for "any length" string, you can of course use it in as many programs as you like. After a while, you get a good set of "useful functions" that you can use for all sorts of things, and you don't need to re-develop these for every project. Of course, some of the code is decidedly specific to a project, but a lot of functions are often quite frequently used in other projects.
One of the drawbacks with perl is just the management of variables and memory - because perl does this FOR you, it will also spend some of it's time "checking how much and what memory is used", and clearing up unused memory. In extreme cases, this can take almost as long as the actual code takes. In other case, it doesn't create much overhead at all - it all depends on what you are doing and how you go about doing it.
In C, it's up to you, as a programmer, to do the right things with memory. The language as such only give you the most primitive functions (malloc, free and realloc - and a few other related functions), but you can also store variables globally, or use local storage in a function. The overhead of using any of these is pretty minimal, and there's no "maintenance" aside from exactly what you have written - there's no code going round checking if something is still in use or not [not counting the overall memory handling of the OS, whcih happens whatever language you use]. Again, the "details" are up to the programmer, who can choose between several different solutions (including implementing something that resembles the garbage collection [which is the technical name for "maintaining which bits of memory are used] of Perl).
Because of the higher level of detail, it also means more work for the programmer.
--
Mats
I doubt you will see a speed difference between C/C++ at all for generic programs.Quote:
Originally Posted by JFonseka
And C is also slower due to everything you have to handle - from memory allocation and deallocation, to resource release, to testing time and debug and memory errors, etc, etc, etc.
It's the price you pay for extra power. If you want to avoid that yet still have a blazing fast language, try C++.
How is that so? If it's already built into C++ from the libraries it would be calling larger libraries and taking more time to do all the processing, whereas with C it is manual so you are selectively choosing what you want and hence cutting down on the behind the scenes code that is getting executed.Quote:
Originally Posted by Elysia
Ah, but the libraries are also insanely optimized, probably more than what you can do by hand, so by that definition, I'd definitely say it's faster.
C++ may be a little more overhead, but it's hardly that much. It's nowhere near dotNet or Java.
Subject to programmer doing the right things - and programmer not doing the right thing is where most security issues come from in the first place. I'm not saying that C++ isn't safer, just that it's based on using the correct forms of various functionality, and understanding for example buffer overrun problems and doing "stuff" to prevent it from causing problems (security or otherwise).Quote:
Originally Posted by Elysia
C++ as a language is very marginally safer than C - but such things as STL help making it easier for the programmer, because the programmer can use that directly, not have to write his/her own code to solve some particular problem.
When it comes to speed difference in C and C++, I can guarantee that there's no difference - the only difference is in which way someone chooses to solve the same problem. C++ is deemed slower because often people don't use it correctly (or put another way, they do things they wouldn't have done in C, either becasue they didn't understand what the C++ code does, or they couldn't do it that way in C in the first place, or simply "because the programmer made different choices"). If you understand what the code does (in fair detail), then C++ will be just as fast for doing the same thing as C.
There are a few things in particular that is common in C++:
* Unnecessary use of new/delete - where a statically sized allocated choice is just as good.
* Doing "tiny functions that do nearly nothing" - typically getters and setters that don't NEED to be such.
* Too much inheritance, leading to lots of calls to chained constructors, and virtual function calls.
Of course, just as there is "too much", "too little" can be wrong too - coding style and choices can be very important for getting things right, and getting the balance right between object design and the algorithms.
There are quite a few cases where, if you are not very clever with stuff, you can make C slower than C++ - the typical case would be where you want polymorphism. Calling a function on an object is almost free, whilst doing a switch-statement in every function to figure out which type of object this is, and how do deal with it, may be an extra overhead. The other C solution is to set a function pointer to the right routine for each object - in which case we're implementing C++'s virtual function in C, so the same solution, with the same type of overhead.
--
Mats
Of course, but it we don't use STL, then typically we must rely on C stuff (unless we use 3rd party, which probably uses STL), so we could argue that we're back into "C++/C" (C inside C++), so it isn't truly C++.Quote:
Originally Posted by matsp
C++ provides a safe(r) framework which we can use to avoid security issues, but is also backwards compatible with C, which means if you choose that route, you're back to those issues again.
So it's now clear that C# is the fastest, Java the next and so on and hence forth until C++ which is the slowest.
Other way around ;)Quote:
Originally Posted by JFonseka
C++ is one of the fastest portable languages you can get - obviously, as with all benchmarking, you can get other winners occassionally (particularly for situations where a language is written with some particular purpose in mind, and optimized for such).Quote:
Originally Posted by JFonseka
--
Mats
I was kidding matsp, Elysia got it :PQuote:
Originally Posted by matsp
Of course I understood. My comment wasn't meant to point out or be serious :pQuote:
Originally Posted by JFonseka
The ordering is absolutely correct!Quote:
Originally Posted by JFonseka
Fastest to Slowest in terms of developer time, and, no, not the user time!
Hahahaha, where does that put Microsoft? =DQuote:
Originally Posted by manav
The secret's out
I once found an article saying that Microsoft has 160 programmers :|
Is that true? Where would that put Microsoft? In the bottom? I mean, 160, for all of their projects?
But Microsoft is known for slow, buggy, incredibly complex programs. I'd definitely put Microsoft at the bottom!
The company I work for has MANY more than 160 programmers [1], in fact the department I work for is mostly programmers, and we're 80 or so - perhaps 50 or so programmers. The whole company has about 1000 employees, and probably about 70+% are programmers.Quote:
Originally Posted by Elysia
[1] That obviously depends on what you imply by the title programmer as well - I count all manner of people working in software engineering writing code - "People who write code". They may well have other titles, e.g. Senior Software Engineer, Software Developer, Test Development Engineer, Software Contractor, Technical Lead or any other of many titles that could be used for these rolls. It could be that the 160 programmer figure is that there are 160 people in MS with the exact title of "Programmer".
--
Mats
There are probably 1000's of programmers in Microsoft, if not more. There is no way there is 160 unless there are 100 hours in a day
Maybe that's why it takes 5-6 years to build a crap OS like Vista that has no new improvements? :p
Vista is the most legendary thing since sliced bread. It's just you need experts to understand the wizardry in there, experts like me. :pQuote:
Originally Posted by Elysia
Oh yeah, forgot to add: "and an OS that breaks 99% of the things or 99% of the things don't work as they should."
101% of the things in Vista work for me. That extra 1% includes things to be released in the future which I'm sure will work, after hours of tweaking, replaced monitors and added RAM.Quote:
Originally Posted by Elysia
Pick the language that suits your needs and you feel most comfortable with, and don't worry about speed unless you utterly absolutely have to (which I doubt you do).
What are generic programs?Quote:
Originally Posted by Elysia
The term I used for "a wide variety of programs, not limited to one type." Or maybe "programs you use daily for your own computer use or pleasure." Or the like.
You can subtract about 10% from that for every VB6 app out there that uses certain controls such as winsock. Another 10% for the problems I've been dealing with for adding Vista support to our product, and another 1% for the problems I'm sure we haven't seen yet.Quote:
Originally Posted by JFonseka
If we look at the programming side, I scoff at the pathetic UAC implementation.
Launching a new executable just to elevate is ridiculous. So subtract another 10% there.
And subtract another 10% when Vista can't do simple file operations properly (I just tried moving a lot of files and folders somewhere and it would just die randomly in the progress with no explanation as to why).
Thank you Magos.Quote:
Originally Posted by Magos
I am also getting a little overwhelmed by the choice and availability and usability of so many programing languages. I will take a break now. Will try to pursue my martial art hobby. Not the violence though just for exercise purpose.
I like your movies :)Quote:
I will take a break now. Will try to pursue my martial art hobby.
As I also stated earlier, choose the tool for the job.
Thank you zacs7.Quote:
Originally Posted by zacs7
I am not the real Jackie Chan (I know you are kidding). I love him and the movies also.
Right tool for right job is something that I will always try to remember.
Huh! You're lucky it is only VB... I have a simple C application, that uses Winsock... And Vista randomly closes the opened TCP connections without proper explanation of the cause...Quote:
Originally Posted by iMalc
I'm now looking for a good book on Vista programing like Jeffrey Richter "Programming Applications for Microsoft Windows" (it was good for XP but does not gives enough info about new tricks). Somebody knows good book like that? Or maybe a new edition of Richter's?
I always liked "Frustration: Programming in Windows (sledgehammer included)" ;)