Larkin, Power BASIC cannot be THAT good:

I don't know about them, but to my knowledge ffmpeg and mplayer use a lot of asm.

As far as I know, there isn't much of automatic vectorization in C compilers either, so any non-trivial use of SSE and such needs hand coded assembly.

OTOH, I think there was a fairly recent "survey" on slashdot about assembly. The result was that few slashdot readers use it, but then I read it as "slashdot reading perl and php coders don't use assembly". Kind of no brainer...

Reply to
Anssi Saari
Loading thread data ...

On a sunny day (Wed, 10 Jun 2009 21:58:36 +0300) it happened Anssi Saari wrote in :

Yes, those do. And I use ffmpeg mplayer :-) Those are just building blocks. I use libmpeg3 too....

Well, it makes your code non-portable for a start. And, how much is the real gain in speed? With ever more powerful processors and 30 fps or 25 fps TV systems it may no longer matter, except for encoding. And for encoding H264 is the bottle neck ATM, and for that they now start using the Nvidia API.

It can be fun programming in asm to get max speed, I have done video on a PIC in asm for example, but if you have enough processing power why bother?

Reply to
Jan Panteltje

On a sunny day (Wed, 10 Jun 2009 12:23:44 -0700 (PDT)) it happened snipped-for-privacy@gmail.com wrote in :

My Duron 950 supports SSE in mplayer:

MPlayer 1.0pre7try2-3.3.6 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices Duron Spitfire (Family: 6, Stepping: 1) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx

Fast as a speeding bullet!

AMD rocks :-)

Reply to
Jan Panteltje

On a sunny day (Wed, 10 Jun 2009 19:33:52 GMT) it happened Jan Panteltje wrote in :

Oops, correction,. no SSE either, so who needs it :-) I think 3DNow makes it faste.

grml: ~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Duron(tm) Processor stepping : 1 cpu MHz : 959.555 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1920.76 clflush size : 32

Reply to
Jan Panteltje

Such as being impossible to debug.

I'm with John on spreadsheets (though not on BASIC)--they're famous for generating reasonable-looking wrong answers, and (unlike programming languages) their testing facilities are zilch. Sort of like the old Royal-McBee drum memory computers, where every instruction contained the address of the next instruction--every line had a GOTO.

Brr. Give me Mathcad or Octave for numbers, and little scripts for other sorts of data. Spreadsheets--blech.

Cheers,

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
 Click to see the full signature
Reply to
Phil Hobbs

Niche software is generally both low quality and expensive; the alternative would often be reasonable quality and unaffordable.

True, but that's not created on a commercial basis.

And a lot of the worst software is also free.

Free software is liberated from the need to turn a profit, so there's no product sabotage to preserve sales of the enhanced version, or chasing meaningless bullet points at the expense of useful functionality.

OTOH, it's also liberated from the need to cater to what users actually want (as opposed to e.g. what the developer thinks they ought to want).

Reply to
Nobody

On a sunny day (Wed, 10 Jun 2009 20:44:08 +0100) it happened Nobody wrote in :

Most important perhaps with much open source software is that it is written by somebody actually *USING* it, created to do some function the person needed, at least in my case. So it will likely do that :-)

That is very different from a CEO saying: Let's write a xxx package, competition is making millions with it. And the programmer never even uses it... so it will suck.

Reply to
Jan Panteltje

Whether the compiler can make use of it may depend upon your algorithm.

E.g. one of Quake's key optimisations was that it only performs one perspective division for every 16 pixels. This is much faster than performing a division per pixel, but visually almost as good; you won't see the difference unless you're looking for it.

Why 16 pixels? Because that's how many pixels it can render using the integer ALU while the FPU is (concurrently) performing the division.

You could write in C and still get the optimisation (with a sufficiently good compiler), but you would need a reasonable understanding of the x86 in order to structure the code in such a way as to enable the optimisation.

The compiler won't perform approximations for you, and you can't test every possible approximation for performance.

Reply to
Nobody

n.

Yep. But clearly, Jan is not interested in programming a Quake graphics engine, or an Unreal graphics engine...

Michael

Reply to
mrdarrett

You are making the common argument that better software has to cost more. What I see is that some people write good code and some don't.

We use PADS for pcb layout; it has no known-to-me bugs, it's fast, and it never crashes. LT Spice is great. Agilent's Appcad ditto. Irfanview and Crimson are great. Firefox and Thunderbird too. Most Microsoft and Adobe products are slow and buggy. Why is Hyperterminal still messed up? Adobe Reader is a train wreck.

Free software is also usually written by one or a few people (beasts like Linux excepted; but even Linux is better than Windows.)

John

Reply to
John Larkin

et

This is the best free software I could find for composing music:

formatting link

If I knew Windows programming, I might help volunteer with a port. Alas, ...

Michael

Reply to
mrdarrett

Video? In ASM? Hah, just the other day I tried getting my breadboarded Z80 to produce NTSC composite. Just bit banging out of a spare data bit or two.

No good, one instruction takes about an inch of scan, no time even to read the next line, and the horizontal sync is terribly unreliable due to the variable interrupt latency. With lots of prodding I made a few stable pictures, nothing interactive. Definitely needs support hardware. An AVR at 16MHz would probably do nicely though.

Tim

--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms
Reply to
Tim Williams

;-)

Cheers! Rich

Reply to
Rich Grise

On a sunny day (Wed, 10 Jun 2009 16:45:32 -0500) it happened "Tim Williams" wrote in :

Hi, Tim, well, the 'video' PIC runs on the internal oscillator of about 4 MHz... What it does is remove those annoying pulses that some DVD players insert, the Dutch word is 'beeldverbeteraar', in English 'picture improver'. This is the complete project files, including asm: ftp://panteltje.com/pub/mvp-0.2.zip This is what the thing look like: ftp://panteltje.com/mpv-0.2-pcb.jpg

What it does is: It first finds the V sync pulse, then samples the video black level for an empty line, using a HC4053, then waits until just before where those nasty pulses occur, and then replaces that area with the sampled black level. Simple.

You may think it is illegal to remove those M * cr * v *s * on pulses, as normally those are only inserted to prevent copying, but my DVD player, a Mustek,

*always* added those pulses, also on my own DVDs that I created myself, so I had to design this to be able to make VHS tapes of my own DVDs.

Maybe helpful to somebody who has the same crap DVD player (I have put that one with the garbage some time ago). There was more wrong with that player.

Reply to
Jan Panteltje

Spreadsheets are debugable, at least as much as any interpreted language.

I'm certainly not. I use them all the time to debug everything from BOMs to database errors. They also make great tables and simple charts-n-graphs.

They're perfectly acceptable tools, with the understanding that they are just tools.

Reply to
krw

You imply that the "meaningless bullet points" are somehow different.

Reply to
krw

AIUI, our part number and ECO tracking software company has been bought out by Oracle so some day we'll have to migrate over. It's a mess now so I can only imagine what an adventure of Titanic proportions that'll be.

Reply to
krw

In a normal interpreted language, each statement follows the one ahead of it, unless there's an explicit control structure. (Or a named label, but we're assuming reasonable practice here--use GOTOs to escape from a deeply nested loop to a nearby point, say, but not otherwise.)

Any spreadsheet cell, on the other hand, can depend on any other spreadsheet cell, without warning and without any way of finding that out in general other than an exhaustive examination of each cell.

_Your_ spreadsheets, I'm quite sure, are sensibly structured and reasonably comprehensible in outline. But that is far from the general case, even for spreadsheets that have real money depending on them. A nontrivial spreadsheet that has had more than a couple of people working on it is a disaster to debug--far worse than spaghetti code.

Yep, tables and graphs are about it.

Well, they're widely accepted, all right, but they still stink.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
 Click to see the full signature
Reply to
Phil Hobbs

Not that it *has* to, just that it often does.

Once upon a time, IBM estimated that the computer market amounted to around 20 computers in the entire world. Nowadays, everyone has one, and the software industry is so large that there simply aren't enough "good" programmers to go around. In this environment, some degree of mediocrity is inevitable.

That's because Microsoft and Adobe are trying to corner the market, which means that their products have to do absolutely everything that any similar product might possibly want to do, otherwise they leave enough of a market for a competitor to survive. This pretty much guarantees bloatware.

Free software (or even less ambitious commercial software) will tend to stick to what it's good at; or at least not bother trying to do what it's particularly unsuited for.

Reply to
Nobody

Gee, Phil, ever tried LabView?

It's definitely more of a "write only" language, particular if you weren't the original author.

Reply to
Joel Koltner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.