Quad FX fragging Conroe Quad
An old benchmark as a refreshing piece of information-- if people know how to read.
Cinebench: Quad FX leads QX6700 by 13% and leads Con XE6800 by 68%.
PovRay: Quad FX leads QX6700 by 23% and leads Con XE 6800 by 130%.
MyriMatch: Quad FX leads QX6700 by 5%, but pay attention to scalability from single to four threads, AMD is far superior.
As you can see, once you eliminate those retarded results which show Con XE 6800 faster than QX6700, in true multithreading scenario, Quad FX wins hands down.
posted by Sharikou, Ph. D. @ 12/29/2006 05:38:00 PM
43 Comments:
Hey Sharikou, have you received your free Vista laptop yet?
QFA:
Between the two quad-core systems we tested, the Core 2 Extreme QX6700 is faster overall.
As you can see, in multithreading scenario, Quad FX wins hands down.
Hands down? I can prove you WRONG by listing a single counterexample.
http://techreport.com/reviews/2006q4/quad-fx/index.x?pg=7
see "Valve VRAD map compilation".
Hands down? I can prove you WRONG by listing a single counterexample.
http://techreport.com/reviews/2006q4/quad-fx/index.x?pg=7
see "Valve VRAD map compilation".
This result should be discounted, because the QX6700 is more than 2x of a Con XE6800, which is theoretically impossible.
OK Shari-kook, for New Year's you need to make a resolution to lay off the booze before blogging...
From that very same link:
"The thing [4x4]uses nearly as much power at idle as the Core 2 Extreme X6800 system does while rendering, and when both FX-74s are rendering, power use peaks at around 450W. I believe that's the highest we've seen for any PC system. Yow."
"Between the two quad-core systems we tested, the Core 2 Extreme QX6700 is faster overall."
"Unfortunately, the Quad FX concept hasn't entirely escaped its roots in excess and exclusivity. Most notably, the Asus L1N64-SLI WS is too expensive, and it raises the overall cost of the platform."
And perhaps the best summary:
"For now, though, Intel's quad-core processors offer better performance, lower power draw with correspondingly lower fan noise, and a range of excellent motherboard choices, almost all of which will fit into a standard ATX enclosure. Perhaps what AMD needs most is to make the transition to 65nm chip fabrication technology, so that quad-core computing doesn't require an additional socket."
It was good of you to pick just a couple of favorable benchmarks, one would think with your advanced degree you would not be so narrow-minded and have an ability to look at the overall benchmark performance (obviously your degree was not in mathematics or statistics)
"Hands down? I can prove you WRONG by listing a single counterexample.
http://techreport.com/reviews/2006q4/quad-fx/index.x?pg=7
see "Valve VRAD map compilation".
Sharikou response - This result should be discounted, because the QX6700 is more than 2x of a Con XE6800, which is theoretically impossible.
Actually you are wrong here (VRAD map calucation):
QX6700 - 145sec
X6800 - 238sec
(FYI: AMD was 173s and 331sec, so I guess you could say AMD was better able to scale their crappy result between single socket, dual core and dual socket, dual core. Of course absolute perfomance was worse, not that that matters...)
You were looking at the wrong graph you idiot!
"This result should be discounted, because the QX6700 is more than 2x of a Con XE6800, which is theoretically impossible."
So if this result is discounted - why shouldn't we discount the results where AMD fares better, we all know that is theoretically impossible as well for the $x$
Holy Sh!t look at that price...
"Holy Sh!t look at that price..."
Well you can always get the board that Sharikou said would cost around $300... Sharikou could you provide some additional info on that board again? I must have lost it...
I find it funny that the board is almost as much as 2 FX70's... at least there's othe MOBO choices as AMD always takes special care to enable the "ecosystem"
NO!!!!!!!!!!!!!!!!!! Why would you even link this page???????????????
You are a sell out a$$hole.
"As you can see, once you eliminate those retarded results which show Con XE 6800 faster than QX6700, in true multithreading scenario, Quad FX wins hands down"
Well, in that file compression x6800 won but in the below there was "PC mark CPU multitasking" benchmark showing that C2Q was more capable than 4x4.
Also you could read this about the cinebench:
"At 3GHz, the FX-74 proves faster than the QX6700 with only one thread, and thus one core, in action. When we move to four threads, that gap is only magnified."
Also on that same page you can see that C2Q wins in 3dsmax, piccolor. c2q was >2x faster than x6800 in valve's particle simulator but not in its map compilation. There it was quite a bit faster than 4x4.
This is definitely a retarded question, but the documentation on newegg.com is equally retarded. Is that 2 processors in that box?
Who's FRAGGING who?
http://www.legitreviews.com/article/425/12/
I thought QuadFX was the ultimate gaming rig...
"Holy Sh!t look at that price..."
Costs more that twice as much as the P5B deluxe.
Sharikou managed to find a very limited number of hand picked benchmark results where Quad-FX was in the lead, if only by a rather small percentage. But one also needs to take into consideration that the Kentsfield is running at a lower clock speed on stock than the FX-74, but it can run at a much higher clock speed than the FX-74 can.
So, the FX-74 is actually a much slower processor, it only wins (in a very select few cases) if you don't touch the BIOS settings. Which is sort of like how I can win a boxing match against a professional boxer if he promises not to hit too hard.
By retarted results, you mean synthetic tests?
So there is actually a benchmark where two AMD CPUs manage to edge out a single Intel CPU? Wow, impressive.
I think these are good benchmarks, but for a different reason. We're talking about an older to-be-replaced K8 core (which gets a serious drubbing normally) taking on Core 2 when the OS doesn't support NUMA. By rights Quad FX shouldn't be within ten miles of Kentsfield. But it is, and the strength of the platform shines through in places.
If Quad FX, as a platform, can take a core which gets steamrollered and make it win here and there, just imagine what it can do for K8L, with Vista. Now THAT'S a result we can all appreciate.
I'm by far a benchmark expert! Actually I never really cared much for benchmark scores. When purchasing servers for my clients, the first thing I would check would be mother-board, RAM, HDD, ethernet, etc, stability and reliability ratings. It may be 10% to 15% slower than XYZ configuration, but at least they are up and running (without a shutdown for years).
Anyone who would purchase based on benchmark scores has absolutely no sense of professionalism.
Anyway, the point is this: With all these recent blogs about such and such benchmark outperforming this platform and that platform has made me sick. Especially when it comes to dual/quad core systems on 1 way, 2 way and 4 way systems.
How can one sit here and run a copy of Benchmark XYZ on a 2P, 4 core machine? This does not represent reality in any way!!
Look at reality...
Desktop: An average desktop system these days will have over a hundred processes and an average of a thousand threads. Each consuming IO, CPU and memory resources simultaneously.
Workstation: Usually very intensive CPU work (3D/modeling) all the while doing heavy IO (memory/HDD) on files over 1GB in size.
Server: Usually 3 or more services (JVM/Application server/Database) will be running, with thousands of threads and millions of requests per day.
In no way can a benchmark calculating FPS, math or IO in an isolated fasion be representative of a systems performance.
I'm concidering creating a Java benchmark suite which will be extremely multi-threaded, CPU, memory and IO intensive simultaneously. It could be run in one of several modes (desktop, workstation, server, etc). Where the desktop would try and create a few hundred threads, creating little memory, IO and CPU processing to simulate an antivirus, spam and email agent, a torrent/p2p application, etc, etc.
While the server would run a dummy application server, servicing clients, requesting database queries, etc.
Before (and if) I get started on this, I would like peoples 'constructive' advice, experience, comments, suggestion.
I'm not interested in doing a graphical/FPS benchmark. The gaming market does not interest me at all.
I'm aware of the JVM issues, such as class loading, GC, JIT, etc, but I believe that these issues could be made minimal.
The advantage of such a benchmark suite would be that it could be run on a Power, Itanium, Sun, etc system (with bias towards JVM implementation). But this could give very interesting comparisions!!
Anyway, help is appreciated in conducting my feasability study!!
Jeach!
re: a java-based benchmarking platform - it's an interesting idea, although you're still stuck with the variance in quality of JVMs.
We've used SLAMD in the past to benchmark our LDAP server. SLAMD is written in Java, OpenLDAP is written in C. We found that in all cases the SLAMD load generators were too slow to generate sufficient load to max out the LDAP server, unless dozens of client/load generator machines were used. On the other hand, using load generators written in C, we could generate sufficiently high load with only 3-4 load generators.
For this reason, I'm pretty negative on any benchmarking tools that rely on Java. JVM inefficiencies will tend to mask the real performance potential of the underlying system. You'll get inflated latency measurements that have no relation to real-world performance. I'm also pretty negative about any servers written in Java, where performance is a requirement.
Profiling our code shows that, barring about 10-15% overhead per CPU for context switching, we can deliver useful results for all of the available CPU power in a multicore machine. When you're running in a JVM, there's even more system overhead that's unavoidable. No amount of JIT optimization can make that overhead disappear, and the CPU time consumed by the JIT profiler would be better spent servicing actual user requests.
Java is simply unacceptable when performance matters.
You can try to put as much lipstick on the 4X4 pig it's still going to be a fat ugly pig.
Sharikou says that Amd can afford to sell their chips at a lower price then Intel since it cost Amd less to make their chips, but if this is true then shouldn't Amd's gross margins be higher then Intel's gross margins? Q3 had them both around 50% and when you take into account that Intel includes the lower margin business of flash, mobos, chip sets, then it appears that Intel actually has slightly higher margins no? With Amd ramping 65nm in 2007 their gross margins should improve but as things stand today it actually cost Intel less to make chips then it does Amd. Q4 predictions anyone? BTW you can't say Intel will go BK or get fragged or something stupid like that.
When you're running in a JVM, there's even more system overhead that's unavoidable.
There are benchmarks out there showing Java is close to C++. But if you look closer, those benchmarks are simple loops of primitive operations. If one tries to do some real code with a lot of objects and I/O, Java is only 10% of the C++ speed. My experience tell me Java is about 20% of PERL in speed.
The benchmarks can say what they want. Java is a drag.
The benchmarks are so clear, INTEL is the clear ahead winner at performance, performance/ watt, performance/dollar.
So sad.. looks like I'm not going to be seing any more BK comments anymore.. Ho Ho Ho
My experience tell me Java is about 20% of PERL in speed.
Your experience is simply...manure then. You have no idea what you're talking about. In any domain other than string parsing and regular expressions Java has much higher performance than Perl.
See for example: http://www.tempest-sw.com/benchmark/
In short, you've shown again that you have no idea what you're talking about.
Do you even know what Perl and Java are?
"For this reason, I'm pretty negative on any benchmarking tools that rely on Java"
Have you ever used JMeter? We use it at work for benchmarking sever applications. Under windows there is a little OS flaw that you can't have >8 concurrent requests but with Linux there is no such limit and even a single 3GHz P4 is enough for simulating 200 concurrent users one 2P Opeteron server.
"I'm also pretty negative about any servers written in Java, where performance is a requirement"
Why are you negative? Personal belief or real-world experience with Java based servers? If Java would really be as bad as most people here think it is then why is there such thing as Javapolis?
"Java is simply unacceptable when performance matters."
It depends on the application. Most server applications are limited by database throughput and using Java as front-end to those databases has almost no performance impact.
"If one tries to do some real code with a lot of objects and I/O, Java is only 10% of the C++ speed"
Well, I would say it can really easily be the exact opposite. Java is lightyears ahead of C++ when it comes to managing insanely big amounts of data with lots of threads. By IO you mean database IO? If so then most databases are implemented in low-level languages to give that extra boost they might need.
Now compare the time and effort you need to code each program in Java and in C++ and tell me what is cheaper, throwing more HW at the problem or more human recources? You can get loads of 4P servers for one programmers year salary.
"My experience tell me Java is about 20% of PERL in speed."
Could you describe what kind of experience have you had with Java and Perl? I would like to see soem Perl programs that work at half the speed of C++.
For some reason I think you either have no experience with Java or you have only run some microbenches where hotspot haven't got the chanche to kick in.
"There are benchmarks out there showing Java is close to C++. But if you look closer, those benchmarks are simple loops of primitive operations."
Java is not meant for tasks that run for two seconds and then give you the result. It is meant for tasks that you start once and stop only when there are some problems with the HW that you can't fix with hotswap or when there is a version upgrade.
Long story short, Java is better with long running processes and worse with short microbenches.
http://www.tempest-sw.com/benchmark/
Looking at the results from 5 to 100 digits, Java is 20% the speed of PERL. However, going for more digits, PERL becomes 5% of the Java. The conclusion is clear, the perl code was badly written.
I don't want this to become a Java vs. other languages debate!
But a few things are for certain...
a) Most people who proclaim that Java sucks, 'usually' don't know what they are talking about and/or are very biased.
b) For sure Java has its issues with various things, but there are a lot of bad Java programmers out there that don't help much either in the performance cause.
c) Sun is not helping at all in making Java the success it can be.
I'd like to concentrate on the third point (c). I don't expect Sun's JVM to be the most performant of them all. But I do expect most inovation to come out of the Sun camp. The unfortunate truth is that most inovations don't come from Sun. I may be wrong on the exact origin of the following, but I do know they don't come from Sun.
For example, the JIT inovation comes from some asian IBM division.
The faster boot/execution is from Apple. Apple has also engineered some sort of technology where you load the JVM once, dump the memory foot-print to a file and memory-map it in order to share like 10% of all classes from other Java apps.
Since Java is so memory intensive it almost makes it impossible to have hosting services at an affordable price. Sun needs to concentrate on this in order to make it feasable for a company to have thousands of Java hosting client with a few servers.
You could go on and on about this, but the fact is Sun is more interested in writing up new specs than inovating the language.
Jesus, you are comparing C++ and Perl with Java 1.3? And that on a VM that is running on ~8y old HW?
Let's get the obvious out of the way:
"Looking at the results from 5 to 100 digits, Java is 20% the speed of PERL."
Have you ever heard of a VM startup time? Even if not then anyone with a half a brain would see that when N<1000 the runtime numbers for Java are pretty much useless.
Run the same benchmark against Java1.6 (Java6) to see what it can really do. Also, did you see that Java was about half the speed of fastest C++ one at larger numbers even back then?
I ran those Java, C++, Python and Perl benchmarks on my 3GHz C2D.
#g++ -v
gcc version 4.1.1 (Gentoo 4.1.1-r2)
#java -version
Java(TM) SE Runtime Environment (build 1.6.0-b105)
#python -V
Python 2.4.4
#perl -v
This is perl, v5.8.8 built for i686-linux-thread-multi
C++ compiled with only -O2 as that has shown me the best results over thousands of things I've compiled and benchmarked. Others were compiled/ran with their default flags.
Results #time program N N.txt for N=8k, 16k, 32k, 64k. Only real time shown:
C++: 0.951s, 3.829s, 14.496s, 55.888s
Java: 1.075s, 4.315s, 14.619s, 53.731s
Python: 3m10.314s, 12m59.019s
Perl: 2m2.186s, 8m3.599s
Last two times I didn't run with Perl and Python, I have better things to do than wait. I estimate those times to be around 30-40 minutes and 2-3 hours.
Yes, that is really correct what you see there, Java narrowly beats C++ with higher N. I ran the test several times and it was about the same every time.
The conclusion is clear: you know nothing about Java, C++ or Perl and you can't interpret the data you give as proof of your claims
ROFLMAO! Somebody must have fed you that URL, because there is no way anyone could be stupid enough to think we would not look at the rest of the tests.
What the rest of their tests show is Core 2 Quad and Core 2 Duo putting the smackdown on AMD.
AMD convinced us its all about performance per watt. Then AMD lost the lead in IPC, raw performance and performance per watt. Why would AMD be so stupid as to crown this trifecta with a power whore like 4x4. WTF is AMD thinking. WTF are YOU thinking?
Anonymous said...
"For this reason, I'm pretty negative on any benchmarking tools that rely on Java"
Have you ever used JMeter? We use it at work for benchmarking sever applications.
This conversation would be easier to take seriously if you weren't anonymous. But anyway, you've already established that you think servers written in Java are OK.
We obviously work in different areas. I write OpenLDAP and other infrastructure services. These things have to be fast because so much else in an enterprise relies on them; we measure response latencies in microseconds. Servers talking to web frontends generally don't have those requirements, they respond in milliseconds or seconds and people think they're just fine.
"I'm also pretty negative about any servers written in Java, where performance is a requirement"
Why are you negative? Personal belief or real-world experience with Java based servers? If Java would really be as bad as most people here think it is then why is there such thing as Javapolis?
Personal experience of course. Java seems to be an extremely popular programming language. It's a truism in our society that things get popular not based on their merit, but on their marketing. That alone should be a warning...
But yes, I've written servers in Java as well as a dozen other languages, I know what it is capable of, and the cost at which it's delivered.
"Java is simply unacceptable when performance matters."
It depends on the application. Most server applications are limited by database throughput and using Java as front-end to those databases has almost no performance impact.
Do you have any idea how much crappy code exists in the world today because "it's talking to something slower, it'll have almost no performance impact"? It all adds up. That's probably why the database is slow in the first place, and every suboptimal piece you layer on top of it just makes it worse.
"If one tries to do some real code with a lot of objects and I/O, Java is only 10% of the C++ speed"
Well, I would say it can really easily be the exact opposite. Java is lightyears ahead of C++ when it comes to managing insanely big amounts of data with lots of threads. By IO you mean database IO? If so then most databases are implemented in low-level languages to give that extra boost they might need.
You seem to believe that it's acceptable for code to be slow. Try telling Google that it's OK for their frontend server app to be slow because their backend is slower already. Servers are designed to be used heavily, by lots of users, that's why they're servers in the first place. Any time you write code that's not as tight as it could be, you're doing a disservice to your users.
Now compare the time and effort you need to code each program in Java and in C++ and tell me what is cheaper, throwing more HW at the problem or more human recources? You can get loads of 4P servers for one programmers year salary.
Depending on who the programmer is, that may or may not be a good tradeoff. Most programmers aren't good at their jobs and should have chosen a different profession. And it's easy to get a year's worth of competent programming for cheap in India or China.
On the other hand, once your program is deployed and is getting banged on by millions or billions of users, every millisecond of wasted time you didn't shave is costing THE WORLD in countless resources. No matter how much it costs a handful of programmers to tighten up their code, when you're writing for a mass audience, the effort is worth it.
There's another side to this too - code I write in C can be directly called from any other computer language. That's the ultimate in reusability. Code written in Java can only be directly called by Java, anything else has to go thru a glorified RPC mechanism. To make a long story short, you get far more bang for your buck in the long term by using C.
This conversation would be easier to take seriously if you weren't anonymous. But anyway, you've already established that you think servers written in Java are OK.
Java simply failed on the desktop and in the enterprise. Otherwise, SUN wouldn't have opened source Java. Just pay attention, how many programs are written in Java? A couple years back, anything written in Java was pretty much unusable. Today, CPUs are running at GHZ speed, and Java apps are still sluggish. Java is inefficient by design. On servers, it's the same story. I know companies who used Java and J2EE switched to .NET for performance reasons.
code I write in C can be directly called from any other computer language.
I took a look at the D language, seems to be good. C++ has become too complex. In the old days, everything is explained in the ARM. Today, the language specification is > 1000 pages.
Looking at the results from 5 to 100 digits, Java is 20% the speed of PERL. However, going for more digits, PERL becomes 5% of the Java. The conclusion is clear, the perl code was badly written.
The conclusion is clear, you are making a fool of yourself. There is startup time associated with a Java VM. Hence, for very short running tasks this overhead causes Java to appear slow.
When running longer running tests (mimicing real world loads) the startup time is insignificant.
You are really good at embarassing yourself with your clear lack of understanding in any domain computing.
There's another side to this too - code I write in C can be directly called from any other computer language. That's the ultimate in reusability. Code written in Java can only be directly called by Java, anything else has to go thru a glorified RPC mechanism. To make a long story short, you get far more bang for your buck in the long term by using C.
This is laughably false, and you clearly don't really know what you're talking about.
Let me educate you. There are some application domains where raw assembler is required. These are few and far between - some drivers, some realtime code, debuggers, compilers, etc...
There are more domains where C/C++ type speed is required. Some games, some scientific applications, some very performance sensitive server scenarios. Others.
The _vast_ majority of other application domains are well served by something like .NET or Java because real programmers understand that architecture and design is far more important than raw processing speef in the majority of application domains.
It's a corrolary to "optimize last". "Develop in C/C++ _last_". Most of the time Java and a decent architecture will work for almost any business application scenario. And don't take my word for it, it's been done and is done every day.
You can be a luddite contrarian and swear up and down Java sucks because it's popular, but you're going to be left behind as a dinosaur if you haven't already been.
So in some domains - C/C++ or even assembly language is required and will provide obvious benefits.
Most of the time, this isn't true and you're ripping off your employer by using C/C++ because it's slow to develop in and much more costly to maintain. It's also more complicated to fix bugs and add enhancements, which is 9 times out of 10 more important than raw processing speed.
The conclusion is clear, you are making a fool of yourself. There is startup time associated with a Java VM. Hence, for very short running tasks this overhead causes Java to appear slow.
Yet another retard repeating the stuff written by another retard, trying to defend the failed Java project.
I took a look at the source code, it was basically two simple loops of integer operations (see the C version ). As I pointed out prviously, Java can be fast in doing loops of primitive operations. The fact that the benchmarker didn't measure the time taken to perform the calculation but merely used the "time" command to get the real time spent by the whole program from start to finish further prove the benchmark is crap.
The PERL version of the code is very badly written. It was a straight translation of the C code, but array access is a very slow operation in PERL. With PERL, one can easily inline C code into the PERL code. SUN sued Microsoft for failing to implement JNI, SUN sought preliminary injucntions under copyright law, but the 9th circuit reverse the district court and the latter found breaking JNI was breach of contract. In the end, Microsoft simply dropped Java and developed C#.
This is laughably false, and you clearly don't really know what you're talking about.
Show any shred of proof that anything I wrote is false.
Let me educate you. There are some application domains where raw assembler is required. These are few and far between - some drivers, some realtime code, debuggers, compilers, etc...
There are more domains where C/C++ type speed is required. Some games, some scientific applications, some very performance sensitive server scenarios. Others.
Educate away. I've written and successfully deployed all of the above, and can easily prove it. Can you? Search for "hyc" or "Howard Chu" in any source tree on any Unix or Linux system in the world. I've contributed to gcc, gdb, gmake, Linux, BSD, Kerberos, OpenSSL, Mozilla etc. etc. I've written code used on the Space Shuttle, in realtime (and have an award from NASA for it). (That's actually a pretty good story, and they still talk about it back at JPL. A critical piece of communication hardware failed just after launch and I wrote a C program in 20 minutes to duplicate the failed hardware's functions. Oh, and yes, it worked the first time; you seldom get two chances with failures like that. Never mind the fact that the other engineers believed it couldn't even be done in software, that's why it was in hardware in the first place... Without me the mission would have been a complete failure; because of me it succeeded and went on for more launches after that.) What have you done?
The _vast_ majority of other application domains are well served by something like .NET or Java because real programmers understand that architecture and design is far more important than raw processing speef in the majority of application domains.
Real programmers understand that architecture and design are only *equal* in importance to a competent implementation. Only ivory-towered computer scientists believe design is the most important factor.
It's a corrolary to "optimize last". "Develop in C/C++ _last_". Most of the time Java and a decent architecture will work for almost any business application scenario. And don't take my word for it, it's been done and is done every day.
Just because it's done every day doesn't make it right. "Use the right tool for the job" is the more important adage. Clearly you're the one who doesn't know what you're talking about.
So in some domains - C/C++ or even assembly language is required and will provide obvious benefits.
Most of the time, this isn't true and you're ripping off your employer by using C/C++ because it's slow to develop in and much more costly to maintain. It's also more complicated to fix bugs and add enhancements, which is 9 times out of 10 more important than raw processing speed.
You're just spewing the same propaganda that was hyped about C++ vs C, and every other language war that's come and gone. Been there and done that. Bugs are hard to fix in poorly designed and poorly implemented code, regardless of language. Enhancements that require a major change in a design are expensive in any language. Enhancements that are trivial are trivial in any language. In that respect, all that matters is having discipline and a clear design to begin with, there's nothing special about Java there.
I write code fast, in any language. I also write fast code, in any language. Not that I'm much concerned about ripping off my employer, since I own my own company.
Anyway, we were talking about a benchmark framework here, whose purpose is ostensibly to measure performance of some other system. The Heisenberg principle applies here, and if you want results that don't distort reality too much you want your measurement framework to be as invisible as possible. Using Java with this as a goal is a mistake. When the target server was competently built what you end up with is a target server that demonstrates the (lack of) performance of your JVM, not a Java system that demonstrates the performance of your target server.
"As I pointed out prviously, Java can be fast in doing loops of primitive operations. The fact that the benchmarker didn't measure the time taken to perform the calculation but merely used the "time" command to get the real time spent by the whole program from start to finish further prove the benchmark is crap."
Then why the heck did you bring it as an example? Such blunders make me wonder why should anyone trust any other sources you bring as examples in your other posts.
"The PERL version of the code is very badly written. It was a straight translation of the C code, but array access is a very slow operation in PERL"
You were supposed to be some kind of a C++/Perl Guru. Please write some better benchmarks then.
"The PERL version of the code is very badly written. It was a straight translation of the C code, but array access is a very slow operation in PERL. With PERL, one can easily inline C code into the PERL code."
A code is not badly written if it performs well/better in small scale. The fact that array access is very slow in perl indicates perl being a slow programming language (for anything with array accesses).
You argument of inlining C into perl is lame, too. You don't inline programming language when benchmarking the speed of the programming languages. Maybe you'd say Unix shell programming are fast, too, since you can run any compiled C programs in it.
Whoever it is that wrote the following, it is so TRUE, that I figured I would repost it in bold:
There are some application domains where raw assembler is required. These are few and far between - some drivers, some realtime code, debuggers, compilers, etc...
There are more domains where C/C++ type speed is required. Some games, some scientific applications, some very performance sensitive server scenarios. Others.
Also, this guy is more than likely a very experience developer, because these words are also amazingly true.
Most of the time [...] you're ripping off your employer by using C/C++ because it's slow to develop in and much more costly to maintain. It's also more complicated to fix bugs and add enhancements, which is 9 times out of 10 more important than raw processing speed.
Unfortunately anonymous, most developers are not professional enough to learn and understand each language's potential and most importantly, KNOW WHEN TO USE IT.
See Java isn't really about performance... its about programmer ego! For the following, I will write the unspoken though process of a bias programmer...
Hello, I'm Mr X! I've been programming for over 15 years. I'm one of the best out there! I can read core dumps like a book. I can debug your code quicker than you can say 'fix it'!
When we hire new kids I teach them the ropes around here! These new guys look up to me (and they should).
Why should I learn Java? I've been using C for 15 years and it has always worked, no need to change! Besides there is no new kid that's going to come here and show me how to program in this new language! Heck, these guys might end up being my new boss... no F!@#$@# way that is going to happen! No Way!
THE END
And this thought process goes on and on and on. The truth is most programmers who reject the 4th GPL's (Java/.Net) are the older ones. Most of the new programmers accept them.
Its really too bad because our industry really needs the knowledge and experience of these old programmers. I wish some could come around look at reality!
"Yet another retard repeating the stuff written by another retard, trying to defend the failed Java project."
Yet more proof that you are a fraud and not a ph.d. A person with an "advanced degree" as you've so stated in the past, especially one as advanced as a doctorate, would *never* resort to this childish dribble.
Congratulations on making yourself look even more assinine...
Why should I learn Java? I've been using C for 15 years and it has always worked, no need to change!
I think this language war is not needed. Java sucks in terms of performance, period. Very few real world applications are written in Java. SUN tried on desktop, failed, tried on server, failed, they are still trying it on mobile phones, I believe.
SUN was very reluctant in openning Java, but it had to do it in the end. Otherwise, Java may die. Hopefully, the open source community will get Java done right.
Then why the heck did you bring it as an example? Such blunders make me wonder why should anyone trust any other sources you bring as examples in your other posts.
No. I didn't bring it as an example. Some anonymous dude did.
Post a Comment
<< Home