What is Digg?Sponsored by Dragon Age: Origins
See the new YouTube feature trailer for Dragon Age: Origins view!
youtube.com/DragonAge - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
84 Comments
- dazparkour, on 06/02/2009, -1/+31Nice to look at, interesting to know.
The truth is, big iron is cheap.
If you have a programming language like Python where 3 people can do the work of 20 people programming in assembly, you go for Python. Even if Python runs 10 times slower, you still go for Python?
Why? Developers are much more expensive than servers.
That matters - you want the work finished and running. Unless you make the next Crysis, modern processors can cope with slower languages much better than people can deal with archaic coding practices. - shinkou, on 06/02/2009, -1/+22Very interesting visualization. Now I'm wondering where the optimized Javascript (in Chrome and Firefox) will be.
- nicodemus26, on 06/02/2009, -3/+18The problem with this is that you can't know if each implementation was as optimized as it possibly could be. In fact, the two axes point this out clearly. Often a programmer can trade brevity/conciseness for performance, or vice versa. Who knows what balance the implementers chose for each program (data point.)
- rlbond86, on 06/02/2009, -4/+18Interesting to see C++ vs C results -- though I wish I could see the implementations, as C++ algorithms and funtion objects often can be optimized to faster-than-C code. As expected, python and perl win for lowest number of lines. Java seems to be beaten in most cases by C# in the Applications Development category.
- klco, on 06/02/2009, -2/+16Not necessarily true, when working with extremely high volume systems speed can be a huge factor.
- HeavyWave, on 06/02/2009, -1/+12Yet totally unreadable.
- billricardi, on 06/02/2009, -0/+11A strange but worthy effort to 'review' the efficiency and ease of use of some of the more arcane languages out there. It would have to be done with a lot more points of reference to be somewhat more scientific, but this is an interesting snapshot.
It also confirms that Haskell is some form of wonderful voodoo, which is what I suspected all along! - Myztry, on 06/02/2009, -0/+10Even though I grew up writing (hand & source) assembly on 8 bit, 16 bit and 32 bit (C64, CoCo & Amiga) processors during the 80's - I would like to see IML (InterMediate Language) take over as the 'binary executable' format for computing.
In these days of brute force aplenty (well that's more the attitude then the reality) people forget about the humble opcode, and what a difference it makes. Let's assume the high level language is perfect, and so is the compiler. That's not the basic problem.
The x86 began as a 16 bit non-supervisor (multitasking) processor with a sparse register count, and paging to overcome the fact that even a mere 640k was well above 16bit addressing. The result is that the opcodes needed to be expanded while maintaining many old opcodes and registers that should have been redundant as the functionallity was drawn out to 32bit and then again to 64bit.
IML could undo all that less than optimal hardware hacking required to draw new life out of an old beast. Clock speeds can only take you so far, as is becoming the major issue. If the opcodes can be enumerated back down to what is actually useful - then opcodes could take half the memory, which would allow twice the code to fit on the cache, which would require half the bandwidth to fetch from main memory,which would require half the bandwidth to load. Fixing the base issue has a cascaded effect across the system.
Furthermore, software could be moved to more suitable processors not so reliant on brute force. Parts could be compiled across to GPU's or other co-processors. The opcodes could translate to opcode sets designed for Object Orientated execution with it's indexed object nature and features such as fully re-entrant code. Register counts could be adjusted to alleviate the need to push registers out to memory and the like. Execution ordering could be mostly done at first run to simplify and reduce costs of processors. A processor with native extended function support (floating point, matrices, etc) could execute native code without branching into external libraries, just in case it's not supported.
IML is where true write once, run anywhere could become a reality, as long as an implementation of the external (non-application) functions exist. The code would need to be pass by the execution system compiler greatly simplifying malware preventions. If a certain API function is not allowed in that category on application - don't try to catch the call - just refuse to generate it which means the privileged application no longer need to pass checks that take time but never can fail. - NeoTechni, on 06/02/2009, -1/+11Odd, they left out Visual Basic
- covertbadger, on 06/02/2009, -0/+10Objective-C isn't a gui front-end, it's a language. Apple's Cocoa toolkits and Interface Builder are not part of the language.
- superkendall, on 06/02/2009, -3/+12Interesting, but no Objecive-C results at all...
- lashtal, on 06/02/2009, -1/+10I don't think the graph is anywhere near accurate. Take the 'Code Size' thing: in some languages you'll need 50 lines to get something done; in others the same will take just one line of code, but it will be incomprehensible.
Performance is another story: measuring average of benchmarks is absurd. Different languages have different application fields, so you can't really compare Ruby and gcc.
Everyone knows scripts are slower than JIT or VM-based langs, which in turn are slowed than 'real' compiled gcc or pascal-based langs.
** btw there are updated charts I didn't notice at first:
http://gmarceau.qc.ca/blog/uploaded_images/size-vs ... - Cerolobo, on 06/02/2009, -1/+9No. I am not an expert in every language listed on the site. As such, it is not my place to attempt to optimize a language I don’t know much about.
The point of accepting code from other people is to remove as much bias as possible, by allowing them to work on what ever language they know. - domenics, on 06/02/2009, -0/+8FTA: "The shape of the Haskell star, specifically the way that it bends up, suggest to me that writing high-performance programs in Haskell is a bit of a black art, and that some of the benchmarks submissions could be improved if someone got around to it."
I think you might have missed it, or as the kids say, "failed" it yourself. - HeavyWave, on 06/02/2009, -0/+7Extremely high volume are rare.
- Cerolobo, on 06/02/2009, -0/+6Apparently you’ve never been to the Computer Language Benchmark Game website. The source code for all the programs is available for peer review.
- inactive, on 06/02/2009, -1/+7I did too
- HonoredMule, on 06/02/2009, -0/+6That kind of exploding cost comes from poor design and implementation, not a poor language. Poor design is more likely to arise when failing to choose an expressive and maintainable language. With the possible exception of Ruby, no modern, popular programming language performs so terribly as to become a major factor in the choice, even in high-volume projects.
If you knew anything about programming, you'd know that the difference performance of various languages is so negligible in practice that even the largest difference can be mitigated by a 5% increase in the hardware budget. Conversely, poor algorithm design, a poor relational data model, or a system design that ignores needs for scalability/distribution of processing can all lead to i/o bound operations or exponential increases in processing/bandwidth requirements even for small increases in job size...all completely regardless of programming language, operating system, or system architecture.
Readability. Maintainability. Writeability. Traceability. These are everything...whether you're hiring seasoned gurus or fresh recruits. It is this understanding that gives rise to the very existence of object-oriented programming principles and design (even though OOP is not the be-all and end-all of achieving these values). - inactive, on 06/02/2009, -0/+5A good FORTRAN programmer can write FORTRAN code in any language
- covertbadger, on 06/02/2009, -1/+6You're being ridiculously naive. Not all problems are parallelisable. There are many fields other than 3D graphics where raw performance is vital. Writing websites is not a hard problem and is known to scale horizontally, but writing websites is not the be-all and end-all of software development.
- wolfing, on 06/02/2009, -0/+510 Print "Basic FTW"
20 Goto 10 - GordonV, on 06/02/2009, -0/+5qbasic? yes? no?
- nicodemus26, on 06/02/2009, -2/+7Haskell is indeed magical, and will become more so as parallelism becomes more and more important (driven by processor design, because they can't get much faster/smaller, so they just have more cores.)
Also, for the data points off of the top of the chart (large code size): you're doing it wrong. Haskell is so rediculously compact it stuns me every time.
For example, here is quicksort on two lines. Behold:
qsort [] = []
qsort (p:xs) = qsort [ y | y <- xs, y < p ] ++ [p] ++ qsort [ y | y <- xs, y >= p ] - billricardi, on 06/02/2009, -0/+4Yeah, 6 core AMD Istanbul's were just put out. Haskell's black arts will thrive! :)
- SteveMax, on 06/02/2009, -0/+4No, you are not. g77 still generates faster code than gcc/g++/gfortran for many HPC applications, and other compilers for big iron are even better.
Besides, text after column 72 has always been comments, and that is the way God intended programs to be :) - Myztry, on 06/02/2009, -0/+4Code bandwidth is only part of the issue. The important aspect is that improvement can cascade down through the various bandwidth limited systems. The less the cache overflows, the less execution goes outside and the faster execution remains. It would be like getting a larger cache for free.
Now, it's obviously more complex than just opcode sizes. Addressing and Data registers also form part of that stream. You claim knowledge of MC68K, so you should also know that these can be reduce-able as well. MOVEQ.L #-1,D0 was only 1 opcode (16 bits) long yet could fill an entire 32 bit register. Even common opcode sequences could be macro'd into single instructions on the right processor.
IML is already used by the major compilers but only as an intermediatry to processor specific executables being packaged. That's a darn shame, as all it usually end up producing is x86/x64 - and usually the lowest expected processor type on the architecture. If the executable was shipped as IML then the JIT compiler could transparently take advantage of processor advances - without the programmer even needing to code detections for them. - cgbspender, on 06/14/2009, -0/+3Where is C# (Microsoft)? Microsoft .NET vs. Mono would be interesting.
- HonoredMule, on 06/03/2009, -0/+3I didn't say a thing about "some social media app" because what I did say applies equally to almost any serious software project, on or off the web and whether it be for public or private/corporate consumption. Your statement is the literary equivalent of throwing out a few crumbs and making the main reality look like an edge case. Yes I am being contrary, and make no apology. The qualifiers you are trying to apply are grossly misleading, and you're straining at a gnat just because no one else mentioned it, while making the camel look like a hazy afterimage.
I'd rather my staff pay the lion's share of attention to the obstinate camel, and don't give a rat's ass if no one notices the gnat. - darkened, on 06/03/2009, -0/+3Java clobbers C#? BAWHAHAAHAHA
Unless you're talking about bigger numbers in: Memory Usage, Time to Execute, lines of code, etc etc. - cosmotic, on 06/02/2009, -0/+3????????? Java borrowed from C++, does that mean Java has similar performance as C++?
- eruanno, on 06/03/2009, -0/+3STL is clean and simple, but i wouldn't call it fast. C++ only outperforms C sometimes because some of the higher level concepts it provides can be better optimized by the compiler, with less effort on the part of the programmer. Oh and published C++ "gurus" suck.
- cosmotic, on 06/02/2009, -0/+3Seems to be beaten? Are you looking at the same page I am? Java clobbers C# (running in mono).
- HonoredMule, on 06/02/2009, -0/+3No, I'm pretty sure I'm saying the exact opposite, but nice try. I didn't "take it to the next level." I replied to the original level, in the context of the original subject: economics related to *programming languages.*
Are you going to stick with a rebuttal that basically says you took a single statement out of context just so you could spout your pipe? Besides which, that "false economy" spiel is total ***** if applied to software development. People "in the biz" would know that costing more later is a perfectly acceptable tradeoff for the "short term" benefit of actually bringing a product to market and at least getting to start. It doesn't even matter how much corporate backing or venture capital you've got. Even the most meticulously designed software is all theory until it actually manages to survive deployment.
The only constant is the need for accessible and expressive code that current and future developers will be able to first off build, and secondly maintain and continue to improve and extend. It's also the only factor that can offer significant savings now AND over time, and it's a savings in developer time, not hardware cost or performance. The only time a bad tradeoff really comes into play is when you try to cheap out with incompetent developers. - giantnegro, on 06/02/2009, -0/+3Am I the only person still using FORTAN77?
- FastZ, on 06/02/2009, -1/+4I don't really know what this is, but I'm digging it because it's nerdy.
- rlbond86, on 06/02/2009, -1/+4For starters, check Effective STL, by Scott Meyers, item 46. Or just try it yourself -- qsort vs std::sort with full optimization, on large arrays. std::sort always wins. std::transform is almost always faster than a hand-coded loop if the function object has an inlined operator(). Once again, try it.
- hawksfan03, on 06/02/2009, -0/+3no coldfusion?
- RoboDonut, on 06/02/2009, -0/+3>C++ algorithms and funtion objects often can be optimized to faster-than-C code
[citation needed] - ripter, on 06/02/2009, -0/+3I noticed that too :(
The benchmark lists Object-C http://shootout.alioth.debian.org/debian/benchmark ...
He just didn't include it apparently. - stuwanker, on 06/02/2009, -0/+3i <3 prolog
- inactive, on 06/03/2009, -0/+2o sry guys my bad :x
- Myztry, on 06/06/2009, -0/+2LOL. I didn't even expect you would read my reply (It was days late).
As for digging you down - I can't do multiple buries, or multiple diggs...
Well technically I could if I had multiple accounts. But that is not the case.
Oh, and being vague on technical aspects from 20 years ago. That's not flaky. That's life :) - dazparkour, on 06/02/2009, -2/+4A factor does not mean *the* factor.
It's possible to get those three people to profile and optimize post construction if it needs it.
The tipping point where you write things in assembly for run-speed is likely to be in 3D graphics or a related area. - int19h, on 06/17/2009, -0/+2LuaJit and FreeBasic came surprisingly well out of this compared to what I thought about them from before.
Perhaps I'll give LuaJit a try. - nicodemus26, on 06/02/2009, -0/+2Don't bury smcnow too much. Sheesh.
Haskell was on the graphs, under the label "ghc."
http://haskell.org/ghc/ - 4degrees, on 06/02/2009, -0/+2anyone else find it strange that LISP was not evaluated?
- igouy, on 06/02/2009, -0/+2Days ago you might have had the excuse that you didn't know SBCL or CMUCL were Lisp.
Now in the first row of charts there's one labelled "Lisp SBCL". - Myztry, on 06/04/2009, -0/+21. Advantage is advantage. NET compiles to IML, but then they do stupid things like wrap it inside setup.exe defeating the ultimate purpose.
2. JIT compilers would only need to be done at installation, or at worst first run - then it could be cached. But I'll admit we have the chicken and the egg. The gain a hold, it needs to be used. And it won't be used till it gains a hold.
3. Moveq was 3 bit (or maybe 4 bit, +-7 decimal I think) sign extended from memory (albeit 20 years ago). Moveq.l #0,d0 was actually quicker than clr.l d0. I believe ARM was faster. That's fine. 68k is dead. Your referenced ARM probably is too. The point is the software could take advantage of ANY processor, current or new. - Myztry, on 06/08/2009, -0/+2Okay. You have been buried already, and no - it wasn't me. Don't be so sensitive. Digg doesn't even display buries correctly. Often two buries result in 0/-1 for some strange reason. Diggs/Buries don't have any defined meaning. They can be anything from a pseudo bookmarks (for stories), to disagreement (for opinions), to corrections (for facts), to plain mood statements. You are taking it too seriously. It's only Digg mate. It's not an experts forum which is what I think you wish it was.
Sure, I would like to think discussions could be fruitful. As fond as I am of eras (that are now becoming vaguely remembered) I do not over-estimate the value of the forum, or the relevance of the subject. I would like to think I am sowing the seed of thought. Maybe I am - maybe not. Really Digg is just my mental chewing gum.
I'm comfortable with being wrong with which opcode contained 3 bit/8 bit encodings. It didn't bother to look it because it's irrelevant. I don't even program any more. Got married, had kids, yada yada. My programming mate is still 'in the game'. (he's the author of PlayBasic) but then he's far from married (then divorced) with kids. I'm too busy co-managing a multi-million dollar family business. My life is now quite different.
Anyway, this has degraded into an 'un-fruitful' exercise despite what you may have wished. Good luck with your endeavours. I in no way hold anything against you, even if we have disagreed. Cheers. - Myztry, on 06/08/2009, -0/+2LOL, and I didn't bury that last reply either... OMG someone is following you, and it's not me.
You have a nice day too... And I'll digg that comment, and leave that one of the great mysteries.
(leaves you at +0/-0 : strange how Digg does that)
AND on a final note, only two obsessive compulsives can have a Digg discussion lasting 6 days :) -
Show 51 - 89 of 89 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is 