hello all,
Am Mittwoch 17 August 2005 11:28 schrieb Gisle Fr0ysland:
[...snip...]
I have often been surprised by linux developers' seemingly lack of interest for anything that goes on outside their own application. The general attituse seems to be that 'the other stuff is not my responsibility, so I just have to blindly rely on what other coders are doing'. This is specially true for video apps where everybody seems to be closing their eyes for things like the lack of a unified high-quality playback-engine and free hq codecs.
some words about optimized code.....
a long time ago i was coding the vdsp stuff for jmax, vdsp was meant as a video extension for jmax. to get the best performance, i banged my head into mmx coding, with good results.
but, coding in mmx (or sse, sse2... i can only speak for the intel-compatible world here, and when i say mmx, i also mean the sse/etc...) requires some carefull thought, and some knowledge how those commands are processed inside the cpu. i think that many people just dont want to go through that effort, or they simply dont see that this effort is _really_ needed to produce some mmx code that is faster than native c.
you can _not_ just use some mmx and think it will give you a boost. if you dont take care about the execution pipelines, word alignment, etc, it may even happen that the mmx code is actually not faster, or even slower than the c counterpart. this has to do with the way those instructions are scheduled.
for example, in mmx the instructions are pipelined. but not every instruction can be executed in any pipeline. some instructions can bes executed in both, some only in a specific pipeline. now, if you dont care about the instruction sequence in mmx code, it can happen that the pipeline is blocked, so that the next instruction has to wait. if that happens, also the cache is flushed, etc. the result is that there will be many cycles lost for that, plus the new fetching of instructions, cache fill, etc. taking care of that is known as instruction-pairing.
unless there is taken care of those facts, using mmx instructions will not give you much gain.
i guess that some of those constraints also apply to altivec, but im not sure.
for the interrested, here you can find the mmx code i had written for some image operations: http://mamalala.de/mmx_ops.tgz they are really fast, feel free to use them wherever they make sense.
some good reads about mmx and optimizations: http://www.hayestechnologies.com/en/techsimd.htm#SSE2 http://www.gamedev.net/reference/articles/article1987.asp http://casl.csa.iisc.ernet.in/ComputerArchitecture/pentopt.html (there was also another site, but i lost the link ... some mr. tomasi, with pixel32 or the like ....)
after i have finished my current hardware stuff, i would be happy to help people out with optimizing some code. or at least give some hints and tips.
We should learn from the linux audio community and their effort to advocate the low-latency patches which is finally in the latest kernels. We not only need a video-jack but also a video-alsa!
yes !
cheers -gisle
greetings,
chris
ps - I hope we can continue these discussions during piksel05 and follow up on the efforts contained in the piksel video framework.
At the risk of being non-sequitor, I'd like to chip in here. I just caught this latest post in the thread, so many apologies if this has been covered or is off-topic.
Christian Klippel wrote:
I have often been surprised by linux developers' seemingly lack of interest for anything that goes on outside their own application. The general attituse seems to be that 'the other stuff is not my responsibility, so I just have to blindly rely on what other coders are doing'. This is specially true for video apps where everybody seems to be closing their eyes for things like the lack of a unified high-quality playback-engine and free hq codecs.
The problem here is largely that linux developers are developing for fun, and thus have no obligation to take on unwanted responsibilities. Until these developers are compensated in some way, they'll generally do whatever suits their fancy; which is better than the alternative, which is that we don't do any work at all.
We should learn from the linux audio community and their effort to advocate the low-latency patches which is finally in the latest kernels. We not only need a video-jack but also a video-alsa!
I have often thought about this, and the fact that video apps are generally behind audio apps in open source. I personally think there are two reasons for this: 1) Video requires a lot more in the way of system resources because of its high data rate (as compared to audio). This has slowed video FLOSS video development because FLOSS is generally developed on commodity hardware, which to this day has trouble doing fancy processing on video in RT. 2) (more theoretically) I think there's more of a tradition of technological innovation in music because music has always depended on technology (eg. instruments). Thus computer music is becoming a rather mature genre. OTOH, film has been around for about 100 years (as opposed to millions) and hasn't yet developed as mature of a culture of research and innovation as music. Of course, film is by its very nature technological, moreso even than music. But when multimedia computers debuted in the early nineties, music was already set to take advantage of them, while film took longer, both because of the increased demands film places on a system, and because film hadn't yet developed a need for such technology.
Yes? No? Just a little musing.
-Ian
-
Christian Klippel -
Ian Smith-Heisters