| |||||||||||||
Red Hat: no desktop products comingRed Hat: no desktop products comingPosted Apr 19, 2008 18:38 UTC (Sat) by nix (subscriber, #2304)In reply to: Red Hat: no desktop products coming by mmarq Parent article: Red Hat: no desktop products coming
Automatic bug detection? Are you joking? Do you have any *idea* how hard that would be?
(Log in to post comments)
Red Hat: no desktop products coming Posted Apr 20, 2008 17:03 UTC (Sun) by mmarq (guest, #2332) [Link] If a machine profile is generated before the installing from *source code* takes place, so to speack, and if a good debugging system is in place, i don't see why a proper formated compiler dump cannot be generated and sent "home"... Better!... much better... not only *obvious* bug squash but also dependency resolve...since the installation should be done from online, that is, the actual packages reside in the server, and as i mentioned above something like LLVM is used, i don't see why a distro cannot offer distribution in SSA IL format and vectorLLVM and or Gallium3D IL format!... that is, the distros can make a full good job debugging at compile and link-time and what mostly is used in the client/costumer machine is the backend infrastructure for native code generation and transformation and part of the "optimization" envelope. That is why i mentioned offering also *high profile* commercial apps and even for Windows(R) environment that could be run in a virtualization environment with proper format to take *wine*(ReactOS is basically wine on top of a microkernel if i'm not mistaken) into new levels. I doubt that if RH or any other distro approach Adobe, peoplesoft, PHP, Sage or other softhouse and say your source code will be transfered around *plainly* over the internet, they would accept... they would refuse!... obvious!... But if they say, don't worry they will go in SSA format, and we have good security measures any way, they will probably say *yes*... its all advantages. But, yes you are right, difficult to track bugs would be a completely different history... but that is why there will be all advantages for the distros to collaborate more closely.
Red Hat: no desktop products coming Posted Apr 20, 2008 18:13 UTC (Sun) by nix (subscriber, #2304) [Link] Why would RH or other distros *want* to approach a closed-source company with an offer to distribute their closed source for them? Offering code in some intermediate representation is plausible, except that said representation, if it is at all portable and stable across compiler releases (which it would have to be for your scheme to work) would also enable people to compile stuff with *other compilers* into that IR, and then hit them with GCC's optimizers: and RMS is dead set against that, so you won't ever see it happen with GCC. (What *is* happening with GCC is a completely compiler-specific 'don't expect this to work on another architecture or even with a copy of GCC built with different options' intermediate representation, for link-time optimizations. But that's definitely *not* a suitable format for distributing software in.) Most of the rest of your scheme seems identical to what many distros are already doing with separated debugging info and a core_pattern-hooked program which captures and compresses core dumps and optionally sends the backtrace or the core dump itself off to the distributor. (The latter especially has to ask permission: being a memory dump, coredumps can *easily* contain private information.) (I don't really know what a 'machine profile' is, so I can't say anything about that part.)
Red Hat: no desktop products coming Posted Apr 20, 2008 20:19 UTC (Sun) by mmarq (guest, #2332) [Link] "" Why would RH or other distros *want* to approach a closed-source company with an offer to distribute their closed source for them? "" Why not ?... if costumers what they want is a particular app, why not offer them what they want and take a small profit out of it ?... if i remember FOSS philosophy is not opposed to profit... If the idea is then to make those "close source" full optimized for vector & parallel architectures i can't see why the original softhouses would not want to cooperate. They could even do part of the job in partnership without revealing any source code if they want to. In this approach all apps will be half-way into transforming themselfs into a FOSS approach... The idea is to make a *CLOSE* to an *universal* OS, idea that would make all sort of shills and strong traditional views in flame... but sincerely believe that FOSS should stand by itself into any area where there is need of a particular application, because its a better model, not because of politics or auto-segregating approaches. There will be more incentive for native porting, because i believe that *FOSS CAN WIN* if developers want it to. But please lets face it. There will always be a "niche" for closed source applications and an important one if i may say so,... and i don't think is necessary to mention the extreme of Nuclear facilities and weapon building... --------------------------------------------------------------------------- ""Offering code in some intermediate representation is plausible, except that said representation, if it is at all portable and stable across compiler releases (which it would have to be for your scheme to work) would also enable people to compile stuff with *other compilers* into that IR, and then hit them with GCC's optimizers: and RMS is dead set against that, so you won't ever see it happen with GCC. (What *is* happening with GCC is a completely compiler-specific 'don't expect this to work on another architecture or even with a copy of GCC built with different options' intermediate representation, for link-time optimizations. But that's definitely *not* a suitable format for distributing software in.)"" Politics!?... Compiler specifics won't depend of IL, but IL should depend of compiler specifics, is that it ?... In other words GCC would not tolerate the dominance of something like LLVM... GCC would be made to diverge from LLVM. But why can't GCC co-opt something like LLVM which is copyleft BSD ?... it wouldn't be the first time that something similar happened!?... and them take a fork approach... or invent its own similar model ? But very important to have such kind of infrastructure independent of language front end and of ISA backend representations IMHO... if that IL is not completely suitable change it... fork your way or risk to be forked instead... "Offering code in some intermediate representation is plausible, except that said representation, if it is at all portable and stable across compiler releases" and " But that's definitely *not* a suitable format for distributing software in. " Seems a contradiction. IL should be more important IMHO. Modular "optimization" much more flexible and practical. LLVM was just an example. Its not perfect. What is not good about it, could be made much better in another similar approach... Compiler approaches IMHO are in need of a serious overhaul.. new ideas!... because the chips that are coming, and the development models needed are different from the usual... the clock is ticking, HW manufacturers wont wait for long debates... if FOSS loses this boat... we'll came to LWN, but with nostalgia... -------------------------------------------------------------------------- "" Most of the rest of your scheme seems identical to what many distros are already doing with separated debugging info and a core_pattern-hooked program which captures and compresses core dumps and optionally sends the backtrace or the core dump itself off to the distributor. (The latter especially has to ask permission: being a memory dump, coredumps can *easily* contain private information.) "" If the machine has nothing, the OS is about to be installed i can't see that happening. Besides that debug work could be done already at the server side... the code transfered in IL, possible generated dumps terribly diminished then, to the point that most of times there are none. "" I don't really know what a 'machine profile' is, so I can't say anything about that part.) "" Well its not my field really, but : how many cores present, GPGPU capabilities if any, IOMMU present or not, etc etc... Nevertheless if many utilities can detect all that, inclusive benchmark them, why not something like that running from the installation Live CD generating then a file that could be used to determine what versions of software and what compiler settings are more suitable ?
Red Hat: no desktop products coming Posted Apr 20, 2008 20:55 UTC (Sun) by danhah (guest, #51567) [Link] No offense but we are in 2008 not 3008. It is difficult enough to track bugs at the moment (hence the fact that I have one in amorok well actually not amorok, one of the libs) but can you imagine if every person on the planet was to compile there own software. How many different optimisations would there be. Where would the bug be. It could be in any of a hundred different optimised setting. And I could then imagine sun redhat etc only supporting the software if you bought there hardware because they could only test it on that. And even then the potential to fall over an optimisation bug. That could mean finding a missing ( in about 3 million lines of code. That os would cost quite a lot of money. Lets keep it simple. Try and reduce the number of bugs not increase them.
Red Hat: no desktop products coming Posted Apr 20, 2008 21:01 UTC (Sun) by nix (subscriber, #2304) [Link] We'd be running Gentoo or one of the BSDs. :) `Build from source' is not implausible. mmarq's IR-distribution thingy (I can't entirely work out what he's driving at but that's what it seems like to me) is.
Red Hat: no desktop products coming Posted Apr 20, 2008 21:22 UTC (Sun) by danhah (guest, #51567) [Link] Hey I dont mind build from source as long as everybody contributes to the same source and we try to simplify things. But 10 people could have the exact hardware and just one of them could have a bug how long do you think it take to track that down. Forever I would think. I tell you what he wants a super optimized system. The extra 1% gain just isnt worth the extra hassle. Speed is never a problem for (on my PIII 700) its just the bugs that are killing me.
Red Hat: no desktop products coming Posted Apr 21, 2008 0:42 UTC (Mon) by mmarq (guest, #2332) [Link] Have you read other of my postings ? hey!... but was you yourself that complained vigorously in this thread "" Can somebody explain to me why redhat, ubuntu, any commercial organisation can get enthusiasts to help them find bugs and stabilise a product, only for them, once stable, to sell it as a stable enterprise os."" Do you think that is what is really happening ?... without "life long optimization", that is, without a permanent tunning and seeing, what conflicts with what really, how can you tell that the apps and libs that you "guess" are conflicting, are not running great as ever in RH "commercial" or other offerings, and no need to issue patches and or warnings ? "" The solution was to upgrade, upgrade the app but when I tried, that the old problem of dependency hell ( now I know that has changed with yum . Ok mandrake had a slightly newer version so I installed that. Great that worked - oh no some other app now has a different bug so that means upgrade or down grade. dependency hell again."" Isn't that because all possible combinations are impossible to track ? But if a really optimization effort was made to be possible, because a revenue stream is been generated, and the projects specially in desktop, and many more projects developers could be supported and funded,... wouldn't this dependency hell me much more attenuated ? I was in your side, because you and thousand more are in cold right now... i was in the cold many times, and could be tomorrow again... but your arguments only give reasons for RH not get involved in the mainstream desktop. Your objections to my posts seem to be that; - what would be made "commercial" and installed from those repositorys from online, would be much different from the *free*, and there would be a permanent winter!? How much worst could it be from what is now ?... wouldn't a real catch the bug and dependency, generating much more involvement from the original projects, so that apps can be changed and evolve to be vectorized and parallelized... help a lot ? Source Code: awareness track marketing mobility, specially for that source code if 'exposed' in a practical way... profits can generate a lot of improvements, dead RH, or Ubuntu or Novell... no!... and how much different would it be from "box checking" a package manager that install a binary, from the same thing that downloads the pre-formated source code or IL representation, compiles it and installs it ????........... The changed/optimized source code must be available anyway... its in the license. But yes, the generated "profile file" and then aplayed compiler settings could not... But do not *fear*, because there would be plenty of FAQs, wikis and howtos availables... profile generators too, and that LLVM infrastructure *DOES LIFE LONG CHECK AND OPTIMIZATION*, you would never be *LEFT BEHIND*, if savvy and willing to waste several days doing everything possible to get the most optimization out of it... chances are that your installation could even be better than the "commercial" installation !!!....... The idea of *TAKING FROM THE HANDS* of final users, *INITIAL* debugging and dependency hell, by installing from online, is only a *VERY GOOD SERVICE DESERVING A HONEST PROFIT*, because there are plenty out there that have a *gross mania* that they know a lot about computers, but the only thing they do is f..k up real good!!.. Otherwise why would a company waste resources, good engineers and high qualified technicians time, to support a zoo ( i wont pay royalties) of the utmost imbecility and 'ubber' idiocy, that is not only scary but is an horror movie that defies believe... getting itself under because of it ? ...i know!... i once get a really angry boss, and not of a corner shop, complaining furiously against my little company because why was that Windows(R) installs completely in the C: partition !!??... we was right the technician "supposedly" could have installed it in D:, the only think that was not accounted for is that that boss 'thing', with admin rights, would render MSFT the service of changing what was inside of the windows folder from place, because he felt that then would make much more sense and be much more aesthetic appealing!!!.... its only an example!... Why do you think that MSFT never got directly involved in this kind of direct support of desktop end users ???.... it gots plenty of patsys!... So what could be more simple, on the exploding need for bug squashing and dependency hell, than to fund the original projects and projects developers for the task ?... yes... can only be done if there is profit to justify it. What is the difficulty of making *part* of that "optimization" using virtual machines that mimic very closely the intended targets ? Why would it be that pernicious of having several *different optimizations* if there gonna be several different machine configurations, with different possible ISAs to support, and not only in the CPU ? 3008 ?... stream computing is already possible now and not only for HPC jobs, Fusion chips will be out in 2009, and the same for Intel Larabee, and Nvidia similar approaches... watch the news...
Red Hat: no desktop products coming Posted Apr 21, 2008 10:45 UTC (Mon) by danhah (guest, #51567) [Link] I am sure we have similar goals. All I am saying is lets try to simplify things to where it just works. Be it source or binary packages. Once that happens then lets look at optimisation. All that you are saying is a great idea and obviously something to aim for but I think we need to walk a little faster before flat out sprinting. Dependency hell will always be possible because if libc changes compatibility then things break. It is about acknowledging that and fitting that into a stable system.
Red Hat: no desktop products coming Posted Apr 21, 2008 19:11 UTC (Mon) by nix (subscriber, #2304) [Link] libc isn't going to break, full stop. However, what *is* a concern is a more general case of something which we did see in the last major upgrade. Remember the wtmp format change? Remember the GCC exception-handler errors, back when libgcc was always statically linked? This is a special case of a more general problem, which is that if some library code manages some shared resource, and more than one variety of it gets to run in the same address space (as happens with static linking, and with differing-soname shared linking), and those varieties have different expectations of some shared resource, things will break. Unix doesn't really have a good answer to this other than `soname breaks that affect shared libraries that are linked both into libraries and into the users of those libraries should force relinking of all those libraries at once, or changes of the intermediate libraries' sonames', both of which avoid having multiple copies of different versions of the same shared libraries in the same address space at once. Neither of these situations are exactly ideal, but as far as I know nobody's thought of a better way. (Has anyone?)
Red Hat: no desktop products coming Posted Apr 21, 2008 19:46 UTC (Mon) by danhah (guest, #51567) [Link] Wasn't there a problem with native threads? and libc. I remember a whole back some of the audio guys complaining about a problem with debian but a workaround was to use -ntpl or something like that. Interesting thread though, pity there is only 3 people reading it. :)
Red Hat: no desktop products coming Posted Apr 20, 2008 21:20 UTC (Sun) by nix (subscriber, #2304) [Link] Why not ?... if costumers what they want is a particular app, why not offer them what they want and take a small profit out of it ?... if i remember FOSS philosophy is not opposed to profit...No, but it is opposed to distributing closed-source vendors' code for them. I'd have thought this would be obvious. Nuclear facilities and weapon buildingWell, the nuke embedded systems are classic examples of vertical apps, passed around among interested parties (largely by technology transfer and outright spying). The toolchains that build those, well, I'd be surprised to find all of them devoid of GNAT, which is of course free as in copyrighted by FSF and based on code written by RMS :) Politics!?... Compiler specifics won't depend of IL, but IL should depend of compiler specifics, is that it ?RMS's objection was that a persistent IL in any form would provide an irresistible temptation to others to provide ways to effectively replace parts of GCC with non-free software. He was eventually persuaded that enough other free compilers now exist that GCC alone cannot prevent this, and that further an IL which is written with no particular attempt to make it GCC-independent is unlikely to be used by many non-free GCC-replacers. We shall see if this is right :) But why can't GCC co-opt something like LLVM which is copyleft BSD ?Last I looked LLVM's copyright wasn't owned by the FSF (though neither is ecj, which is now used as GCJ's parser). There is substantial feedback between LLVM and GCC: some people work on both projects. Co-opting it whole is probably impractical, the architectures are too different: if you did that you'd basically end up with LLVM, in which case why not use that to start with? But very important to have such kind of infrastructure independent of language front end and of ISA backend representations IMHO...Well, duh. Depending on how you look at it, this has been present since the early 2000s (in the form of tree-ssa and the GENERIC and GIMPLE representations), or since the start of GCC (in the form of RTL). You simply can't write a multilanguage or multitarget compiler without some form of IR. if that IL is not completely suitable change it...It's hard to make major changes to an IR once you have dozens of passes depending on it. e.g. the mem-ssa changes (which were changes to *representation* not semantics) were really quite difficult and substantial. Making changes to semantics, particularly the semantics of something like RTL which is wired into the quasidocumented and heavily-coupled guts of Ancient GCC, is dramatically harder. Seems a contradiction. IL should be more important IMHO. Modular "optimization" much more flexible and practical. LLVM was just an example. Its not perfect. What is not good about it, could be made much better in another similar approach... Compiler approaches IMHO are in need of a serious overhaul.. new ideas!... because the chips that are coming, and the development models needed are different from the usual... the clock is ticking, HW manufacturers wont wait for long debates... if FOSS loses this boat... we'll came to LWN, but with nostalgia...I'm afraid this makes no sense at all to me. Why would hardware manufacturers care how code was distributed? Rereading your older posts in this thread, you seem to be suffering under the misconception that there's some sort of magic representation we could use to ship J. Random Unix Program so that it would Just Work, only faster, on massively multiprocessor systems, GPUs, and so on. This simply isn't the case. Making programs capable of effective massive parallelization requires pervasive algorithmic changes: worse, the field is young, and we don't even know in many cases what the right algorithms are (e.g. lockless algorithms are obviously preferable to locky ones, but so far comparatively few lockless algorithms are known, and they're substantially harder to understand than those that use locks). It's trivial, in a built-from-source distro like gentoo, to probe hardware requirements and set compiler flags appropriately (although this is also largely pointless with GCC on x86 these days thanks to -march=native, -mtune=generic and friends). But magically turning single-threaded CPU hogs into multithreaded processes that run on your graphics card isn't going to happen anytime soon, I'm afraid.
Red Hat: no desktop products coming Posted Apr 21, 2008 2:44 UTC (Mon) by mmarq (guest, #2332) [Link]
"" No, but it is opposed to distributing closed-source vendors' code for them. I'd have
thought this would be obvious.""
You mean,... who ever puts in their repositorys win4lin or the free vmware player that anyone
can download and install for free... ha! not to mention the commercial version of crossover
that always lags several months what is then release to the wine tree... is gonna to be
banished from the community. I 'm a strong supporter of FOSS, under my possibilities probably
is not you that is more supportive... but i really find that an hypocrisy...
Happily is not true. Doesn't anyone offer close source apps ?... Linspire CNR ?, Mandriva Club
?,... Xandros ?.... i haven't really checked but i believe they do. ah!... Adobe reader is not
FOSS and i have installed it from my distro repository...
"" RMS's objection was that a persistent IL in any form would provide an irresistible
temptation to others to provide ways to effectively replace parts of GCC with non-free
software. ""
And so what!?... if GCC gets in the same kind of agglutination paradigma, that Linux with its
LSF gets with everybody wanting to participate eagerly including big industry players, then
GCC has nothing to fear, because GCC will always be better... let them try !?
Better GCC can be in GPLv3, and be very watchful of the Industry lobbying and influence. What
GCC should not do, IMHO, is be in the fear and refuse splendid ideas and and potential tech
innovations because of the fear that other can do of abuse.
I'm not implying that GCC and RMS should loose their principals... never!
What i'm saying is that GCC and RMS have nothing to fear from abuse if they can get the clear
technologic superiority...
Its like the so much talked about court of law prove about GPL validity. People have abused
GPL several times, but abusers have always steped back,... FOSS is too dynamic and technologic
acute for law suits. What is the point of litigation even if an abuser think in his mind that
he can win , if by the time it is settled, things have moved so rapidly that the pieces of
code involved don't make sense anymore?...
Now if GCC is left behind technologically, it will be much more prone to abuse, than if it
risks and gets into techs that are clearly not screen free from abuse.
ILs... nothing should be set in stone forever, specially an IR format... there can be always
jumps... new headings... new ideas...
"" I'm afraid this makes no sense at all to me. Why would hardware manufacturers care how code
was distributed? ""
Well that is the whole point, they don't.... but the whole idea about "Fusion" style chips,
and "streaming" optimizations being for ATI/SSE5 or Intel AVX or whatever Nvidia cooks, is
going to be here fast, and its going to catch the whole set on fire... multicore, manycore,
will be even on entry level desktops and wont take that many years to be in embedded...
Many users will be wonting "streaming", i want it too... the current approach of GCC doesn't
seam to me completely adequate... its not an insult... its only a temporary and minor issue i
want to believe...
Get "bold" please.
Red Hat: no desktop products coming Posted Apr 21, 2008 6:57 UTC (Mon) by nix (subscriber, #2304) [Link] You mean,... who ever puts in their repositorys win4lin or the free vmware player that anyone can download and install for free... ha! not to mention the commercial version of crossover that always lags several months what is then release to the wine tree... is gonna to be banished from the community.No, simply that free software vendors are unlikely to do it, because a compiler intermediate representation of Adobe Whatever is not free software. GCC has nothing to fear, because GCC will always be better...Unfortunately, GCC is not better at single-machine optimization than many vendor compilers (although it is getting better). So this really would be a temptation. (What's worse is the temptation of hooking up a new frontend, and this has been tried: if GCC had been partitionable as you suggest, we wouldn't have a free Objective C frontend today.) Better GCC can be in GPLv3sigh. GCC has been GPLv3 since that license's release. Do pay attention. Now if GCC is left behind technologically, it will be much more prone to abuse, than if it risks and gets into techs that are clearly not screen free from abuse.If GCC gets left behind technologically, nobody will want to stick their favourite proprietary frontend on it. (Anyway, it's not me you've got to convince; it's RMS. Getting RMS to change his mind when he has reasons to think one thing is hard. Good luck. I'd not even bother trying until your ideas are much more coherently presented.) Get "bold" please.I just don't think optimizers are magic. You seem to think they are. (Again, the magic autoparallelize-everything optimizer does not exist. It's not just that oh look nobody's written one: nobody knows how such a thing might be written.)
Red Hat: no desktop products coming Posted Apr 21, 2008 16:46 UTC (Mon) by mmarq (guest, #2332) [Link] Really don't understand your objections!... "" No, simply that free software vendors are unlikely to do it, because a compiler intermediate representation of Adobe Whatever is not free software."" Neither is the binary, even packed in RPM format, that Adobe does using GCC, and that distros include in their repositorys. "" Unfortunately, GCC is not better at single-machine optimization than many vendor compilers (although it is getting better). So this really would be a temptation. (What's worse is the temptation of hooking up a new frontend, and this has been tried: if GCC had been partitionable as you suggest, we wouldn't have a free Objective C frontend today.) "" Why not ?... is the Objective C frontend close source ?... Doesn't LLVM include an open source Objective C/C++ frontend, and isn't LLVM partitioned and modular like you say ? "" If GCC gets left behind technologically, nobody will want to stick their favourite proprietary frontend on it."" So its better that way, be left behind so that nobody will be tempted to abuse, is that it ?... my way or no way ? But if that happens wouldn't it be a clear GPL violation ?... Why would anybody risk it, if they can enjoy all the advantages of distributed development and the power that FOSS enjoys, instead of law suits ? Still i believe the biggest problem would be in the backend... But taking an example, isn't AMD CTM/CAL open sourced ?... what is so terrible wrong about cooperation so that the lower parts of that driver could be modular and treated by GCC the same way that Linux treats firmware ?... (only an example because i don't know if CTM/CAL is really open sourced all the way into the clear naked metal) They might do exactly that, putting that lower level as firmware for HW, if they feel that they are being accepted. And who says AMD, can say Intel or Nvidia... "" (Anyway, it's not me you've got to convince; it's RMS. Getting RMS to change his mind when he has reasons to think one thing is hard. Good luck. I'd not even bother trying until your ideas are much more coherently presented.) "" I don't have to convince nobody. Time is a cure for everything. I'm sorry about the coherency anyway. But i think what i'm saying is that, is about time, to GCC to open a new development tree!... yes, like in the time there was a stable and development Linux tree. Certainly is not that easy, nor even magic or something like that... but certainly would prove the power of GCC. The current GCC tree can still be supported for many more years... But what is the point of supporting archaic language front ends, that only 3 guys are using, and one is 80 years old and is forgetting constantly where the return key is ?!... That way would be close to impossible for GCC to evolve, there would be more PITA than anything else, and tech forums would be full of "exposed" technical impediments and hurdles... nobody would bother even to start... the new tree should tackle new problems and new ideas!...
Red Hat: no desktop products coming Posted Apr 21, 2008 19:21 UTC (Mon) by nix (subscriber, #2304) [Link] Neither is the binary, even packed in RPM format, that Adobe does using GCC, and that distros include in their repositorys.Distros that don't ship non-free software don't ship that binary (assuming you mean Flash). (Is it even redistributable? I thought most distros shipped a script that downloaded it from Adobe.) No, but had it been easy to get it to emit something that GCC's backend could have processed, the frontend would have been closed-source. (This is a matter of historical record by this point. If I'm wrong, Joe Buck can tell me I'm full of crap, if he's still reading.)if GCC had been partitionable as you suggest, we wouldn't have a free Objective C frontend today.)Why not ?... is the Objective C frontend close source ? But if that happens wouldn't it be a clear GPL violation ?If GCC emits a stable intermediate representation (as it would have to for distros to usefully ship things in that form), and accepts that representation for further processing, then having some closed-source program emit it probably would not be a GPL violation: at least it would be very hard to prove. This is why GCC doesn't, and won't, emit a stable intermediate representation. (The representation used for link-time optimizations is, as I understand it, by design not stable enough to be usefully emittable by anything but GCC, and definitely not intended as a medium to transport code between machines in.) isn't AMD CTM/CAL open sourced ?... what is so terrible wrong about cooperation so that the lower parts of that driver could be modular and treated by GCC the same way that Linux treats firmware ?This is already doable by implementing a GCC backend that accepts whatever representation the CTM/CAL code generator accepts. It's just like cross-compilation, in fact it is cross-compilation: exactly the same mechanism is used to generate code for the Cell SPUs. But it's not something that magically kicks in: there'd be a different version of a package that had code like this in it, or perhaps a new glibc hwcap and corresponding subdirectories searched by the dynamic linker for shared libraries containing object files in the appropriate form. I don't have to convince nobody. Time is a cure for everything.If you want to get GCC to emit a stable intermediate representation, you have to convince RMS :)
Red Hat: no desktop products coming Posted Apr 21, 2008 3:28 UTC (Mon) by mmarq (guest, #2332) [Link] I forgot to mention; "" But magically turning single-threaded CPU hogs into multithreaded processes that run on your graphics card isn't going to happen anytime soon, I'm afraid. "" Of course not. Wild guess, but i believe that 50% of what is in a normal desktop installation, in a foreseeable future, wont see any vectorization and only mild parallelization if any at all. Start with the obvious ones So benchmarks, of which i urled one in my first post show possibilities of more than 2 orders of magnitude improvement, for hand tuned and for that code base that can benefice higly. All in all, if only 50% of the code base installed gets improvements of only a little more than 1 order of magnitude average, in overall the improvement can still be in the various of thens of % (Amdahl law). And here is the beauty of source code!. It shouldn't just be a recompile. FOSS permits always some sort of hand tunning... start with the obvious, start conservative... i don't think that everything will be possible... but in the end it can prove more than worthed.
Red Hat: no desktop products coming Posted Apr 21, 2008 6:59 UTC (Mon) by nix (subscriber, #2304) [Link] If you use OpenMP (which has a really nasty #pragma-based syntax but works quite well, and which recent GCCs have native support for) then there is no need to recompile at all: you just compile with OpenMP, and the program itself probes for the number of cores at startup. I see no reason why an enhanced OpenMP runtime couldn't probe for a GPGPU and run bits on there if it wanted to, all without any need for this elaborate IR-shipping you seem to be discussing.
Red Hat: no desktop products coming Posted Apr 21, 2008 17:01 UTC (Mon) by mmarq (guest, #2332) [Link] Others also obvious targets are Intel open sourced IBB, and AMD open sourced "framewave"... and you can bet that similar approaches would be getting here like the rain.
|
|||||||||||||