On a sunny day (Thu, 21 May 2009 06:40:59 -0700) it happened John Larkin wrote in :
DISPLAY)
Yes, a linear search is relatively simple. In case of for example a bubble sort, you have to go through the list again and again, until no more elements need swapping position. Although that is all pointer work, it does take worst case many times going through the loop. In case of a binary tree, you just store the info in a sorted way. When reading back the tree you get the sorted result.
But we're not using 32-bit ints. The input is 16-bit signed ADC data and the summing array is 32 bit signed ints. So padding the array up to 8 bytes is a waste of cache and memory bandwidth.
And besides, as noted, we are DMAing the ADC data into a contiguous memory buffer and don't have time to move it into slots in another structure.
And besides, I suspect that having more cache windows onto the RAM arrays is faster.
What would halp would be if we could be doing the add loop on two chunks of cache while others were being transferred to/from memory. I'm sure this can be done, but I don't know how.
John
It's interesting that people seem to be converging to around 0.22 seconds on various machines. I guess we all buy the same DRAM chips.
My down-count loop, in Basic, is hitting about 0.207 or so.
John
OO has nothing to do with concurrency either. You should do some rm -f on your bookshelf. Did you by any mistake got books from Ammeraal?
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
duration more reasonable.
functions.
The basic program calculates 64 million numbers, the C version 67.1 million. Very short tests are not very usefull to do exact comparison of run times because the OS timers aren't that precise. You should make the test last for at least 20 seconds to cancel effects of task switching. The powerbasic and C version should perform equally.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
It is dominated by memory speed under sustained sequential access. Has anyone tried it on a box with DDR3 ram?
It would be interesting to see the code it has generated. I see only a tiny difference at all between counting up and counting down. There is a slight gain in doing the opposite of your initialisation code since then the cache will be preloaded with useful data first time around.
It would also be interesting in a curious sort of way to see the code that gcc without optimisation generated that was so incredibly slow. It was way off the mark at 0.7s if the box was capable of 0.2s (even the Mickeysoft compiler manages 0.4s without any optimisation).
I changed my initialisation code to count down so that the cache would be preloaded with relevant data at the begining. It helps on the older P4s but does nothing at all on the fastest new box.
Regards, Martin Brown
The difference is that a branch-not-zero is faster than an immediate compare.
Any time you programmers need help understanding how computers work, feel free to ask an engineer.
John
On a sunny day (Thu, 21 May 2009 14:14:23 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :
Well, I have
and maintain that C++ is not really an OO language.
It also points out what I pointed out before, the relation between GUI related programming and object oriented programming that seems to exists.
For the rest I do not care, C gives me the freedom to write in any way I like, without the ++ crap getting in the way. The argument that C++ would be better for groups is killed by the existence of Linux, and many Linux applications.
In my view, that what is considered 'OO' is just a help for people who cannot program, or not have the ability to think analytically enough to construct a program that works in a normal way.
What really happened with C++, is what happened with me on a much smaller scale for example in comp.os.development.apps I needed at some point to compare 2 files, on 2 http servers, original and mirror. So I wondered if that was possible from my eeePC without actually downloading those long files as 1) it has only few bytes memory left as it is cram full of extra stuff I added, and 2) it wears out the FLASH if you store those files. So I googled, asked... there was no such utility like 'diff' via the network. So I started writing one, not a small job really. Then somebody mentioned why not use 'wget' and pipes. Now that was really attractive, so I wrote a very short C program that used wget and popen() to do the job, works perfectly. Then after that somebody said: 'you can do that in bash: cmp
program,
for example
mirror.
those long files
No.
The development of the mass software is a sweat shop production line at which the low wage employees work from 7:00 till 5:00.
You are the engineer. They are the farmers.
So they use the tools which allow them to put the things together so it somehow works. On schedule and within the budget.
What go back? Ship and forget. The product will be obsolete in less then one year anyway. All of the programmer staff will be turned arround by then as well.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
My best-selling product - over 3000 so far, one a day like clockwork - has been in production for about 13 years now. We still ship even older stuff now and then. A good VME module will make money for 10 years at least. I can go back and read/understand/modify/rebuild the code on these things quickly and easily. The code is archived and so are all the tools. If I do a rebuild today, the executable image will be precisely what the original was, byte for byte.
But annual programmer turnover? No wonder so much software is so bad!
John
I think a very good example of this is SPICE3: Even though it was specifically re-written in C (rather than FORTRAN) to make it easily extensible/changeable, anyone looking to actually implement some extensions faces a much tougher row to hoe than if it had been writte in C++ from the start.
Hmm... I wonder what Mike coded LTSpice in?
I think the first code I was actually *paid* to write might have been in REXX -- summer internship at IBM after my senior year of high school!
program,
for example
mirror.
those long files
Spice2 _was_ written in Fortran. I had to implement a modification of Gummel-Poon (~1980) so that Cbe was properly represented during forward bias... it doesn't keep increasing (as originally modeled)... it actually drops rapidly.
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC\'s and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
Stormy on the East Coast today... due to Bush\'s failed policies.
On a sunny day (Thu, 21 May 2009 19:27:05 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :
Did you actually read the link? Up to where its says Criticism?
Criticism object-oriented programming as a false annunciation. Usually this claim is founded upon the observation that there are no formal innovations in object-oriented programming -- that the paradigm never brought out a technique or characteristic of programming languages not known to academics by another name. Classes and inheritance are syntactic sugar, whereas polymorphism has long been known to Lisp developers as "dispatching on type." Overall, object-oriented programming, generic programming, and whatever else the designers of static programming languages[clarification needed (see discussion)] add to augment the expressivity of these languages have been formally known to programmers of Lisp for many years[citation needed]. What has been wanting in Lisp is efficiency, and the addition of these techniques to static languages[clarification needed (see discussion)] brings their efficiency to the fore Luca Cardelli wrote a paper titled 'BadEngineering Properties of Object-Oriented Languages'. Richard Stallman wrote in 1995, "Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program."[8] A study by Potok et al. [9] has shown no significant difference in productivity between OOP and procedural approaches. Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP.[10]. In [11], a theoretical foundation on OOP is proposed. Alexander Stepanov suggested that OOP provides a mathematically-limited viewpoint and called it, "almost as much of a hoax as Artificial Intelligence" (possibly referring to the Artificial Intelligence projects and marketing of the 1980s that are sometimes viewed as overzealous in retrospect).[12][13] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I like that one :-) :-) Right on!
Paul Graham, a successful web entrepreneur and programming author, has suggested that the purpose of OOP is to act as a herding mechanism which keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques. [1]
No it is not more logical, it borders on insanity. Or more precise on the notion of one who has no clue about how processors do things, someone who does not want to program, a Turing machine ignoramus to put it politely.
Bloated and slow. MS is an example how that ++ can get out of hand, adding nothing of real interest, real muscle, but tons of bloat and bugs.
I love REXX. Mike Cowlishaw wrote it explicitly to minimize nasty surprises, and (with one or two warts, mostly having to do with stem variable handling) he did a beautiful job. In C/C++ etc you have to be a language lawyer to avoid depending on undefined behaviour, e.g. the dependence of static variable initialization on the order of linking different translation units. In REXX, you just blast ahead and it always works.
Really a beautiful piece of work.
Cheers,
Phil Hobbs
-- Dr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
Yeah, but it might be 25 per week if they weren't using those languages/tricks/etc. :-)
In your case, John, I suspect that much of the benefit you derive in your programming practices comes from the fact that you seem to normally be doing the entire piece of software yourself, or with just a couple other people. Choice of language can help or hinder the likelihood of creating and then the ease of discovering bugs, but certainly the programmer's own attitude towards software development has a much, much larger influence. It's unfortunate that almost all companies now accept that there will be *numerous* bugs in version
1.0 of whatever it is they ship. What's even worse is that many companies know that publishing their bug list would potentially put them at a competitive disadvantage, so rather than just fixing their stupid bugs in the first place, they don't publish a bug list at all, causing various end-users to have to discover and work around the same bug over and over again. If that's not an incredibly customer-unfriendly attitude, I don't know what it!
interest, real muscle,
When you write a "language" that illiterates can program in, you get illiterate programmers. ;-)
Cheers! Rich
between OOP and
technologies,
proposed.
viewpoint and called it,
suggested that the
99.9% of all programmers world wide are using OO to make their jobs easier. Based on the opinions (I see no technical reasoning in the piece you quoted) of a few critics you say 99.9% of the programmers are wrong. If the critics where right, we would not have *any* piece of software available OR nobody would use OO. Therefore it is safe to say OO is a technique which has significant advantages.People tend to adopt technology that has an added value. I think the quick adoption of C# is a good example.
Paul Graham obviously likes to make a fool out of himself (I had a good laugh about so much nonsense and opinions posed as facts):
I'm inclined to recapture the text in noop.html as 'Don't know about OO. Don't want to know about OO. Therefore OO must be bad'. At least at the end of the piece Paul admits he has no clue and no experience with OO programming.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Bizarre. One of my guys just came in with a question from a customer as to whether this temperature controller would work at -175C. We looked at the assembly source code to make sure. It only took a minute or so to find the setpoint variable, and to search for the thing that sets it, and to verify that it errors when the user requests below
-200 or above +265C. Good comments, good labels. This code started in
1993 and the latest rev was in 2006.John
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.