clang is fairly early on, but so is PCC. PCC supports almost no GCC extensions (e.g. inline asm, attributes, etc), doesn't support C99 fully, and has many other problems. The clang parser is basically done for C and clang has support for several other source analysis tools other than "just code generation". See the slides linked of http://clang.llvm.org/ for details. I'd expect clang to be fully ready for C use in the next year.
llvm-gcc is quite mature (it has built huge amounts of code, including apps like Qt and Mozilla), supports C/C++/ObjC and bits of FORTRAN/Ada if that is your thing. Using llvm-gcc you get the advantages of the LLVM optimizer and code generator with the GCC front-end.
PCC is interesting, but it's based on technology from the 70's, doesn't support a lot of interesting architectures, and has no optimizer to speak of.
If you're interested in advanced compiler technology, check out LLVM, which is an ground up redesign of an optimizer and retargettable code generator. LLVM supports interprocedural cross-file optimizations, can be used for jit compilation (or not, at your choice) and has many other capabilities. The LLVM optimizer/code generator can already beat the performance of GCC compiled code in many cases, sometimes substantially.
For front-ends, LLVM supports two major ones for C family of languages: 1) llvm-gcc, which uses the GCC front-end to compile C/C++/ObjC code. This gives LLVM full compatibility with a broad range of crazy GNU extensions as well as full support for C++ and ObjC. 2) clang, which is a ground-up rewrite of a C/ObjC frontend (C++ will come later) that provides many advantages over GCC, including dramatically faster compilation and better warning/error information.
While LLVM is technologically ahead of both PCC and GCC, the biggest thing it has going is both size of community and the commercial contributors that are sponsoring work on the project.
LLVM is an aggressive compiler that is able to do many cool things. Best yet, it has a demo page here: http://llvm.org/demo, where you can try two different things and see how they compile.
One of the nice things about this is that the code is printed in a simple abstract assembly language that is easy to read and understand.
The compiler itself is very cool too btw, check it out.:)
Actually, this is incorrect. The LLVM-gcc front-end completely replaces all of the optimizations and code generation phases of GCC (if you're familiar with GCC, it eliminates all of the RTL related stuff).
llvmgcc is a very substantial change to GCC, and it doesn't use any of the retargetting features that GCC has. Also, LLVM provides its own optimizers and code generators, which produce substantially better code than GCC in many cases (e.g. 30% speedup for C++ codes is not uncommon).
LLVM is an active and vital project with a growing user base and active developer community. If you'd like to chat with some of the devs, stop in to the irc channel.
LLVM is a very young project (only 3 years old) but has already made dramatic progress in it's time. Check out the status updates on the left hand side of the main site to see the rate of progress.
It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases.:)
It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases.:)
Before IBM
downsized the former Sequent hardware division, Sequent was actively involved in IA64 platform design, and continues to be active in many open source IA64 projects...
In general, the Itanium has seen quite poor adoption rates and even Intel/HP admit that their initial public silicon is really only fit for software developers and platform work (due to low performance, and altready established players in the 64-bit field).
Do you think that IPF64 line will see any kind of broad industry adoption? Will it become just like rest of the (non-embedded) processor architectures designed since the x86 -- constantly fighting for 5% of the market? Do you think the AMD Hammer architecture will be a meaningful player in the field?
Since your group is a key player in the Linux on IA64 and GCC for IA64 projects, can you give us any status information about recent developments in the project since the IA-64 Summit?
Yes, perhaps, but you have to realize that G++ is portable to just about every single platform that GCC is... and that is a lot of them. The new G++ has an excellent C++ front end that is quite standard comformant.
One question though, is what platforms are you really winning by using C on? If there isn't a C++ compiler for the platform, are you really that interested in using a big groupware application on it? (assuming it's an older platform)...
Another way to look at it is that they are writing in a very low level language. That language, the wonderful and mysterious C, is well loved by the Gnome project. C is wonderful for low level small programs, but it tends to fall down a bit when scaling up to an application of this size.
One very important thing to remember about code size is that LOC is a very good indicator of # of bugs. Reducing the number of lines of code (obviously without reducing functionality) is a good way to reduce # of bugs, and also to make your hackers more productive.
There are many higher level languages available, in many different language families. Often high level languages get blasted for being in efficient... but this isn't neccesarily so. For example, with all of the "object" stuff implemented (the hard way) in C, you are paying exactly the same runtime overhead that C++ pays when it has an object. All you are gaining, is the joy of having to implement everything yourself and the possibility of your naming schemes getting out of whack.
I think it's great that Ximian is continuing to survive and is about to "unleash" their masterpiece onto the world. I just wonder how much faster it could have gotten here if they didn't use C.
I find it interesting that the open source community (for the most part), tends to stick with C as the language of choice. Lowest common denominator choices like this are usually not the best.
In my mind, there are two very important advantages to having/allowing a cash based society.
Cash is really the only means that we have for anonymous/semiprivate transactions. Everything can and is tracked. Big brother is watching you.</paranoia>
People with poor planning skills. To many many many people in this world (although perhaps the interection of slashdot readers and this particular group of people is not very large), money that you can't hold in your hand isn't really money: this means that it can and is spent on a whim with not "plan". This is why people get so down in credit card debt that they can't seem to pull themselves out of...
If people are allowed to spend "insubstantial" money that they can't feel slip through their fingers... then many people could have a problem with their personal finances...
Moderators: Note, this not a troll... I really do not understand what they were thinking... (see below/end)
From the perspective of a KDE developer (the primary users of QT fwik), I really have to wonder how much of this stuff is desirable:
"Database Programming: Qt 3.0 will include a platform- and database-independent API for accessing SQL databases": KDE already has put significant resources towards a uniform Database model, as has the GNOME project and even specific languages (DBI for perl, f.e.). Why do we need or want, yet another splinter in the market?
"Qt Designer: Qt Designer has now evolved from a dialog editor to a true GUI builder.": Okay, so they seem to have cloned some of the capabilities of KDevelop and others. My question is WHY? So they can sell it to windows users?
"Qt Assistant: Qt 3.0 features a separate application called Qt Assistant, which can be used to browse the Qt Class Documentation, as well as the Qt Designer and the Qt Linguist manuals. Qt Assistant offers index search, contents overview, bookmarks, history and search in pages. ": Again, KDevelop seems to have most if not all of this capability...
"International Text Display": Hrm... pango in a box.
"HTTP network protocol support": Proving the QT is not just a gui toolkit, they implement protocol support. What the heck for? Isn't this better implemented in the 'framework' kind of level as KDE has done? Konq obviously supports this, as does the protocol facilities in general...
"New Component model: Qt 3.0 will provide a platform-independent API for runtime loading of shared libraries and accessing of their functionality using a COM-like interface concept": WHY does QT want to develop their OWN object model? Isn't enough enough? Do they really have value add here? XPCOM is MUCH more portable than they could ever support QT with. Why would they want to add this?
Being a naive user, I have to wonder how much of this is actually useful for free software development. We seem to already have superior solutions for much of what they are providing. Some things (that I have not listed) will definately be nice (64bit portability, better unicode/localization, multiscreening, etc...) and actually seemed to be related to the core of QT: the graphics toolkit.
It seems to me that they are basically trying to reinvent what the freesoftware community has already developed in order to sell it to those less worthy (ie win32/commercial developers). Am I missing something here, or is there a reason a GUI toolkit should have its own incompatible object model?
Heh, just taking a quick glance at the language itself, not commenting about the nontechnical aspects, I found it really REALLY humorus what you find in the "Curl Advanced Features" document:
Classes
Class Members
Strings
Collections
Hash tables ...
Memory Management ...
Note that this documents follows the 200 page "beginners/basic features guide"...
I can see it now: "our language is so technologically advanced that you can use STRINGS if you become an expert in it." and "yeah well sure perl has nice hash's that they tell you about in the first chapter of learning perl. You can read about it on page 99 of the advanced features guide!"
SDL is a cool library. It is nice to not have to worry about a lot of the 'details' in game/demo/media/whatever programming. It does have some problems, but they are arguably not it's fault:
Performance: SDL does take advantage of hardware accelleration where it can (ie bitblts), but it is limited by the OS/environment it is running on. My impression is that windows device drivers, for example, do a much better job of this, than say, FBDEV.
Maturity: SDL is a relatively new library, and although it has been used in some large projects (by real companies [loki]), it still has a ways to go. Of course, this is where SDL is also making its greatest strides.
Industry support: This is the killer. The break or be broken issue. Direct* is well supported by all kinds of hardware devices (not just video, also sound and input devices). Until we can get really good support from the industry behind SDL, it will be lacking in comparison.
The one wonderful thing that is quite uncommon in the free software world is that there seems to be one defacto standard for games programming (SDL obviously). Although there are MANY MANY alternatives (having written a few myself), it is VERY good to have a standard that people/companies can rally around. (/me tries to avoid bringing up KDE/gnome foolishness:)
So anyways, yes, SDL is a good thing. Who knows, maybe Linux (and the other platforms SDL supports) will start getting more games out on them as primary platforms some day?
Idealogy, licensing and roots aside, how much difference (user-level) is there between *BSD and Linux? To me, it seems like they:
Are mostly posix
Are mostly gnu
Are mostly free (by some definition of free)
Are mostly X based
which seems to be pretty compatible. For example, KDE and Gnome can run on FreeBSD with little problems... so WHY would Linux be a better 'desktop' than FreeBSD? It doesn't provide any OS level services that make it a more 'seamless' experience that FreeBSD...
I bet if you were really whacko you could set up a freebsd box that was indistinguishable (in terms of user experience... installed packages, file system layout, etc) from a run of the mill Linux box.
So I guess the real question is: is linux a desktop OS yet?
Honestly, except for a very small number of rabid gamers, plus professionals with very special computing needs, who cares about this stuff?
Game developers.
In 18-24 months, the GF3 level of "computing" performance will be more accessible and commonplace. Incidently this is about the amount of time it takes to build a game... and developers like to be able to debug on REAL hardware.:)
Actually by making it pretty easy to put "flashy" effects in, this card might allow the developer to spend more time working on the other parts of the game.
Perhaps, but not likely. Almost every effect is a special case hack that is designed to look good, at the expense of generality. This means that the engines for games (Quake 2/3 is a perfect example) become very specialized. If you want to base a second game off of the same engine, you get exactly the same set of effects as before, because the design is not very extensible.
My reference to simpler games of yesteryear goes farther though... try to get a group of people together for a netparty, for example... how many people do you think will be able to run stuff that requires a Geforce 1, much less a brand new Geforce 3? Second quesion is: why would you want to?
It seems like the technology trend is to push the envelope to the next step (GF3 is a logical progression from GF2), and then software has to play catchup (no, not ketchup:). It seems that, especially with the first few games for a technology, games focus on doing things because they "can", not because they "should".
Instead of designing games with a clear focus, plot, and motivation, games tend to get dilluted to being flashy silly things. Sure they look cool and have nifty features, but are they really FUN to play? Where is the replay value and interactivity with other human players?
The problem with, for example, vertex shaders and the other DX8 features is that they are not a simple extension of a uniform graphics architecture.
Instead of being able to designing a simple graphics engine that supports a variety of features, and then enhancing it as the game progresses, they have to "Target" a "technology" (for example DX7 or DX8). Of course, they two are essentially completely different APIs, and they are mutually exclusive. This means that you get to rewrite your engine every time you want to support a new "technology".
In a lot of ways, I'm really happy that cards (specifically the radeon and GF3) are moving towards programmability and higher quality visuals. It's quite a different race than pushing fillrates and making up stats on textured poly's a second. Maybe when things are fully generalized, we won't NEED an API like DX that gets constantly mutated, torturing developers...
Oh wait, that's called OpenGL. (sorry, couldn't help it.;)
Slashdot Mirror
Lets try this again, logged in:
Ohloh doesn't have full version control history, but it does show a little over 30K commits to the LLVM and Clang compilers:
Time flies when you're having fun!
-Chris
Enough said!
-Chris
clang is fairly early on, but so is PCC. PCC supports almost no GCC extensions (e.g. inline asm, attributes, etc), doesn't support C99 fully, and has many other problems. The clang parser is basically done for C and clang has support for several other source analysis tools other than "just code generation". See the slides linked of http://clang.llvm.org/ for details. I'd expect clang to be fully ready for C use in the next year.
llvm-gcc is quite mature (it has built huge amounts of code, including apps like Qt and Mozilla), supports C/C++/ObjC and bits of FORTRAN/Ada if that is your thing. Using llvm-gcc you get the advantages of the LLVM optimizer and code generator with the GCC front-end.
-Chris
PCC is interesting, but it's based on technology from the 70's, doesn't support a lot of interesting architectures, and has no optimizer to speak of.
If you're interested in advanced compiler technology, check out LLVM, which is an ground up redesign of an optimizer and retargettable code generator. LLVM supports interprocedural cross-file optimizations, can be used for jit compilation (or not, at your choice) and has many other capabilities. The LLVM optimizer/code generator can already beat the performance of GCC compiled code in many cases, sometimes substantially.
For front-ends, LLVM supports two major ones for C family of languages: 1) llvm-gcc, which uses the GCC front-end to compile C/C++/ObjC code. This gives LLVM full compatibility with a broad range of crazy GNU extensions as well as full support for C++ and ObjC. 2) clang, which is a ground-up rewrite of a C/ObjC frontend (C++ will come later) that provides many advantages over GCC, including dramatically faster compilation and better warning/error information.
While LLVM is technologically ahead of both PCC and GCC, the biggest thing it has going is both size of community and the commercial contributors that are sponsoring work on the project.
-Chris
Apple already has released the source for it, under the standard LLVM BSD license:u ly/009817.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-J
LLVM is an aggressive compiler that is able to do many cool things. Best yet, it has a demo page here: http://llvm.org/demo, where you can try two different things and see how they compile.
:)
One of the nice things about this is that the code is printed in a simple abstract assembly language that is easy to read and understand.
The compiler itself is very cool too btw, check it out.
-Chris
Actually, this is incorrect. The LLVM-gcc front-end completely replaces all of the optimizations and code generation phases of GCC (if you're familiar with GCC, it eliminates all of the RTL related stuff).
llvmgcc is a very substantial change to GCC, and it doesn't use any of the retargetting features that GCC has. Also, LLVM provides its own optimizers and code generators, which produce substantially better code than GCC in many cases (e.g. 30% speedup for C++ codes is not uncommon).
-Chris
LLVM is a very young project (only 3 years old) but has already made dramatic progress in it's time. Check out the status updates on the left hand side of the main site to see the rate of progress.
Building a full C/C++ compiler is no small feat!
-Chris
Check out LLVM: http://llvm.cs.uiuc.edu/
:)
It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases.
-Chris
Check out LLVM: http://llvm.cs.uiuc.edu/
:)
It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases.
-Chris
-Chris
In general, the Itanium has seen quite poor adoption rates and even Intel/HP admit that their initial public silicon is really only fit for software developers and platform work (due to low performance, and altready established players in the 64-bit field).
Do you think that IPF64 line will see any kind of broad industry adoption? Will it become just like rest of the (non-embedded) processor architectures designed since the x86 -- constantly fighting for 5% of the market? Do you think the AMD Hammer architecture will be a meaningful player in the field?
Since your group is a key player in the Linux on IA64 and GCC for IA64 projects, can you give us any status information about recent developments in the project since the IA-64 Summit?
Thanks,
-Chris
-Chris
Thanks for answering your own question. It has nothing to do with their choice of language... it has to do with how they choose to use the OS.
-Chris
Yes, perhaps, but you have to realize that G++ is portable to just about every single platform that GCC is... and that is a lot of them. The new G++ has an excellent C++ front end that is quite standard comformant.
One question though, is what platforms are you really winning by using C on? If there isn't a C++ compiler for the platform, are you really that interested in using a big groupware application on it? (assuming it's an older platform)...
-Chris
One very important thing to remember about code size is that LOC is a very good indicator of # of bugs. Reducing the number of lines of code (obviously without reducing functionality) is a good way to reduce # of bugs, and also to make your hackers more productive.
There are many higher level languages available, in many different language families. Often high level languages get blasted for being in efficient... but this isn't neccesarily so. For example, with all of the "object" stuff implemented (the hard way) in C, you are paying exactly the same runtime overhead that C++ pays when it has an object. All you are gaining, is the joy of having to implement everything yourself and the possibility of your naming schemes getting out of whack.
I think it's great that Ximian is continuing to survive and is about to "unleash" their masterpiece onto the world. I just wonder how much faster it could have gotten here if they didn't use C.
I find it interesting that the open source community (for the most part), tends to stick with C as the language of choice. Lowest common denominator choices like this are usually not the best.
-Chris
- Cash is really the only means that we have for anonymous/semiprivate transactions. Everything can and is tracked. Big brother is watching you.</paranoia>
- People with poor planning skills. To many many many people in this world (although perhaps the interection of slashdot readers and this particular group of people is not very large), money that you can't hold in your hand isn't really money: this means that it can and is spent on a whim with not "plan". This is why people get so down in credit card debt that they can't seem to pull themselves out of...
If people are allowed to spend "insubstantial" money that they can't feel slip through their fingers... then many people could have a problem with their personal finances...IOW, credit cards are not for everyone. :)
-Chris
"Mostly highway miles"
hehe
-Chris
From the perspective of a KDE developer (the primary users of QT fwik), I really have to wonder how much of this stuff is desirable:
"Database Programming: Qt 3.0 will include a platform- and database-independent API for accessing SQL databases": KDE already has put significant resources towards a uniform Database model, as has the GNOME project and even specific languages (DBI for perl, f.e.). Why do we need or want, yet another splinter in the market?
"Qt Designer: Qt Designer has now evolved from a dialog editor to a true GUI builder.": Okay, so they seem to have cloned some of the capabilities of KDevelop and others. My question is WHY? So they can sell it to windows users?
"Qt Assistant: Qt 3.0 features a separate application called Qt Assistant, which can be used to browse the Qt Class Documentation, as well as the Qt Designer and the Qt Linguist manuals. Qt Assistant offers index search, contents overview, bookmarks, history and search in pages. ": Again, KDevelop seems to have most if not all of this capability...
"International Text Display": Hrm... pango in a box.
"HTTP network protocol support": Proving the QT is not just a gui toolkit, they implement protocol support. What the heck for? Isn't this better implemented in the 'framework' kind of level as KDE has done? Konq obviously supports this, as does the protocol facilities in general...
"New Component model: Qt 3.0 will provide a platform-independent API for runtime loading of shared libraries and accessing of their functionality using a COM-like interface concept": WHY does QT want to develop their OWN object model? Isn't enough enough? Do they really have value add here? XPCOM is MUCH more portable than they could ever support QT with. Why would they want to add this?
Being a naive user, I have to wonder how much of this is actually useful for free software development. We seem to already have superior solutions for much of what they are providing. Some things (that I have not listed) will definately be nice (64bit portability, better unicode/localization, multiscreening, etc...) and actually seemed to be related to the core of QT: the graphics toolkit.
It seems to me that they are basically trying to reinvent what the freesoftware community has already developed in order to sell it to those less worthy (ie win32/commercial developers). Am I missing something here, or is there a reason a GUI toolkit should have its own incompatible object model?
-Chris
- Classes
- Class Members
- Strings
- Collections
- Hash tables
...
- Memory Management
...
Note that this documents follows the 200 page "beginners/basic features guide"...I can see it now: "our language is so technologically advanced that you can use STRINGS if you become an expert in it." and "yeah well sure perl has nice hash's that they tell you about in the first chapter of learning perl. You can read about it on page 99 of the advanced features guide!"
-Chris
Are you a dog person or a cat person? Why?
-Chris
Performance: SDL does take advantage of hardware accelleration where it can (ie bitblts), but it is limited by the OS/environment it is running on. My impression is that windows device drivers, for example, do a much better job of this, than say, FBDEV.
Maturity: SDL is a relatively new library, and although it has been used in some large projects (by real companies [loki]), it still has a ways to go. Of course, this is where SDL is also making its greatest strides.
Industry support: This is the killer. The break or be broken issue. Direct* is well supported by all kinds of hardware devices (not just video, also sound and input devices). Until we can get really good support from the industry behind SDL, it will be lacking in comparison.
The one wonderful thing that is quite uncommon in the free software world is that there seems to be one defacto standard for games programming (SDL obviously). Although there are MANY MANY alternatives (having written a few myself), it is VERY good to have a standard that people/companies can rally around. (/me tries to avoid bringing up KDE/gnome foolishness :)
So anyways, yes, SDL is a good thing. Who knows, maybe Linux (and the other platforms SDL supports) will start getting more games out on them as primary platforms some day?
-Chris
- Are mostly posix
- Are mostly gnu
- Are mostly free (by some definition of free)
- Are mostly X based
which seems to be pretty compatible. For example, KDE and Gnome can run on FreeBSD with little problems... so WHY would Linux be a better 'desktop' than FreeBSD? It doesn't provide any OS level services that make it a more 'seamless' experience that FreeBSD...I bet if you were really whacko you could set up a freebsd box that was indistinguishable (in terms of user experience... installed packages, file system layout, etc) from a run of the mill Linux box.
So I guess the real question is: is linux a desktop OS yet?
-Chris
Game developers.
In 18-24 months, the GF3 level of "computing" performance will be more accessible and commonplace. Incidently this is about the amount of time it takes to build a game... and developers like to be able to debug on REAL hardware. :)
-Chris
Actually by making it pretty easy to put "flashy" effects in, this card might allow the developer to spend more time working on the other parts of the game.
Perhaps, but not likely. Almost every effect is a special case hack that is designed to look good, at the expense of generality. This means that the engines for games (Quake 2/3 is a perfect example) become very specialized. If you want to base a second game off of the same engine, you get exactly the same set of effects as before, because the design is not very extensible.
My reference to simpler games of yesteryear goes farther though... try to get a group of people together for a netparty, for example... how many people do you think will be able to run stuff that requires a Geforce 1, much less a brand new Geforce 3? Second quesion is: why would you want to?
It seems like the technology trend is to push the envelope to the next step (GF3 is a logical progression from GF2), and then software has to play catchup (no, not ketchup :). It seems that, especially with the first few games for a technology, games focus on doing things because they "can", not because they "should".
Instead of designing games with a clear focus, plot, and motivation, games tend to get dilluted to being flashy silly things. Sure they look cool and have nifty features, but are they really FUN to play? Where is the replay value and interactivity with other human players?
The problem with, for example, vertex shaders and the other DX8 features is that they are not a simple extension of a uniform graphics architecture.
Instead of being able to designing a simple graphics engine that supports a variety of features, and then enhancing it as the game progresses, they have to "Target" a "technology" (for example DX7 or DX8). Of course, they two are essentially completely different APIs, and they are mutually exclusive. This means that you get to rewrite your engine every time you want to support a new "technology".
In a lot of ways, I'm really happy that cards (specifically the radeon and GF3) are moving towards programmability and higher quality visuals. It's quite a different race than pushing fillrates and making up stats on textured poly's a second. Maybe when things are fully generalized, we won't NEED an API like DX that gets constantly mutated, torturing developers...
Oh wait, that's called OpenGL. (sorry, couldn't help it. ;)
-Chris