Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: I was tempted to think that in the 2000 era we had gotten past the hump of "buy more hardware because it's cheap" stage. In fact the collapse of many sectors of domestic telecom/computer hardware industry in the 2000/2001/2002 timeframe made me think that perhaps we had gotten past that. But... no. It continues, and seems to have spread into the Peoplesoft/Oracle/Microsoft licensing stage ("oh heck, just buy a few thousand more licenses"). Some of the more interesting computers of the 60's and 70's are in fact telecom switches and the computers that controlled them, and as far as I can see these were built/bought/deployed entirely with good economic justification (reduced maintenance/ease of reprovisioning) rather than just industry buzzwords as justification. Maybe I'm looking at that era with rose-colored glasses :-). Tim.

Jules Richardson wrote: I don't think users understand how much they have spent for what they have "received". Take some old software and install it on a *new* machine and you will have folks drooling: "Where did you buy THAT machine?! It's 10 times faster than my 3GHZ frack-o-matic! I've got to have one! Imagine how GREAT my VIDeo GAMES would be on that box???!" And, to be honest, I think "we" (developers, etc.) also take advantage of the improvements in technology. Laziness creeps in. E.g., I had to write a nice little search algorithm to minimize a function. I didn't hesitate to pass int[50] arrays AS ARGUMENTS to the *recursive* function (e.g., it will recurse to a depth of ~50 and each invocation carries 200 bytes of int[] arguments). Sure, I could write something more elegant but it's a throw-away algorithm (to verify some parameters) that I *may* use twice more in my lifetime?? Now, how do you keep that mentality from creeping into your 9-to-5 if your boss is hounding you to get things done YESTERDAY? :< Telecom (and other embedded markets) tend to run off a different business model. Reliability is (was?) the driving force since you didn't want to have to replace your equipment (nor *service* it!) very often. I suspect telecom is moving away from this, now, and more towards the disposable mentality since It Ain't Your Plain Telephone Anymore (i.e. they EXPECT consumers to drive the technology so current investments are not LONG TERM investments). sheepish grin as I recall that when I installed the PBX I wired *both* bathrooms -- for phone, CAT5 *and* CATV! :>

woodelf wrote: <grin> When I ran the wires, I figured easier to be *consistent* than to want the wires *later*! :> I also added a second set of telco wires in each and provisions for a pullchain activated switch (THINK: "Help, I've fallen and I can't get up" commercial)

Bill Sudbrink wrote: I don't blame languages. I blame the folks who either don't fully understand the characteristics/consequences of certain language features *or* the folks who don't understand (nor appreciate) how to *test* things. Languages should give the developer freedom to express whatever algorithm he/she needs to without coloring it. The developer should be able to make realistic tradeoffs (development time, code size, data size, run-time efficiency, reliability, maintenance, etc.) to *justify* his/her implementation choices. Each of those tradeoffs has a REAL *cost* associated with it -- if those aren't visible to the developer (or whomever is making the decisions FOR the developer!) then No Good Results.

Ethan Dicks wrote: The "everything should be in assembler" (paraphrased) comment has some merit -- you get to see what the machine is *really* doing at your behest. Of course, doing *everything* that way quickly becomes counterproductive (and, doesn't eliminate the need for "quality programmers") Exactly. Like: for (x=0; x<XMAX; x++) for (y=0; y<YMAX; y++) foo[x][y] = ...; vs. for (y=0; y<YMAX; y++) for (x=0; x<XMAX; x++) foo[x][y] = ...; They *look* the same but *aren't*. And, in languages like C++, all of the machinery going on "behind the scenes" (automatic type conversion, constructor invocations, etc.) is so far out of the typical "programmer's" mind/scope of knowledge that it's a wonder *anything* works! :-( I found one piece of code that was literally counting bytes to determine the size of a file instead of stat(2)-ing it (no, it wasn't a sparse file, special device, etc. ... just a regular "box of bytes")

Bill Sudbrink wrote: Exactly. "X = Y" can consume a sh*tload of cycles depending on what X is, etc. I suspect the code was never "engineered", either. Just slapped together until it worked and then kept that way as a "fait accompli".

Ethan Dicks wrote: Unfortunately, it seems to be the "normal way of doing business" technique. :-(

Sean Conner wrote: The problem here is when someone walks in and says, "Oh, I need to init the array to '1's instead of '0's" and replaces that with: memset(foo,1,sizeof(foo)); which chokes if sizeof(foo[0]) > 1 If this appears in a seldom invoked place, I prefer the more explicit (i.e. former) code fragment. :-(

It was thus said that the Great Chuck Guzis once stated: Ah, but see, an ANSI C compiler is free to treat memset() "specially" if you include <string.h>. In fact, ANSI C is free to treat any function in the Standard C Library (assuming the appropriate header files are included) specially, and usually anything in <string.h> is handled by inlining the code. First off, you still have to open the file to use fseek()/ftell(). But okay, given that, how is the file opened? If in binary mode, yes, this will work as expected as ftell() for a binary file will return the number of charcters from the beginning of the file [1], but for a text file, the value returned has no defined meaning except that when passed to fseek() it will position the file pointer back to the place when ftell() was called. Why the distinction? Mainly, it comes down to how the end of line is handled, and under Windows (derived from DOS), the following bit of code will behave differently if the file is opened for text vs. binary mode: pos = ftell(fpin); c = fgetc(fpin); if (c == '\n') { newpos = ftell(fpin); printf("End of file character is %d characters long\n",newpos - pos); } If the C runtime detects a CR/LF pair in a text file, it will suck both up and only return an LF, whereas on a binary file, it won't do that. And even the standard says as much about ftell(): For a text stream, its file position indicator contains unspecified information, usable by the fseek() function for returning the file position indicator for the stream to its position at the time of the ftell() call; the difference between two such return values is not necessarily a meaningful measure of the number of characters written or read. Okay, so we need to make sure the file is opened in binary mode, but reading the fine print on fseek(): A binary stream need not meaningfully support fseek() calls with a whence value of SEEK_END. So (if we're being pedantic about portability) we're stuck. fseek(SEEK_END) is only fully defined on text streams, but the result of ftell() is only meaningful on binary streams. Now, reading further about fseek(): For a text stream, either offset shall be zero, or offset shall be a value returned by an earlier call to the ftell() function on the same stream and whence shall be SEEK_SET. In restrospect, if the programmer *was* coding to ANSI C only calls, then maybe it wasn't such a stupid thing to read through the entire file to get the size (since I code under Unix, I'll use stat() and be done with it---if the code gets ported to a system that doesn't support stat(), then maybe I'll write my own stat() that will Do The Right Thing on whatever platform it runs on). Such is the nature of writing portable code. -spc (Granted, I'm being overly pedantic here, but if you want your code to run predictably across platforms, you need to understand what you can and can't do with C) [1] Note: characters, not *bytes*. This from the actual ISO C standard states. What a "character" is is implementation defined.

Idiot? Perhaps the code was just written for Unix. I've written plenty of code with no attempt to make it portable to non-Unix, or non-SPARC, or non-VMS, or non-32-bit, or non-whatever. Does that make me an idiot? Well, perhaps, if such portability should have been designed in, but absent such a reason, I don't think so. Not for suitable values of "portable". I really can't see it as a fault of C if code not written to be portable to non-Unix is not portable to non-Unix. (It may be a fault of the programmer, if porting attempts to non-Unix were reasonably to be expected, but even then it wouldn't be the fault of the *language*.) C co-evolved with Unix. I don't see this as a failing of the language; I see it as a failing of people who not only try to use C on non-Unix but then proceed to blame C for the inevitable mismatch. Whatever is necessary to refer to c[52]. By definition. If char is smaller than the machine's addressing granularity, a pointer-to-char is - must be! - more complicated than a simple memory address. Figuring out how to handle/avoid such things is part of building a C implementation for an architecture. Portable, well, perhaps, if you write in an old enough dialect. (Though, again, "portable" immediately raises the question "to what?".) Nice? Not really, unless you're doing heavy numerical code. That's what FORTRAN was designed for and what it shines at. Like most languages, it fares rather badly outside its design domain. Quite possibly, provided you don't drop Unix in your counterfactual too. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Chuck Guzis wrote: Never trust an optimization unless you see it for yourself. Looking at a real-world example of generated code, I wrote #include <string.h> extern char x1[1024]; extern char x2[1024]; void clear() { // For loop for (int i = 0; i < 1024; i++) { x1[i] = 0; } // memset memset(x2, 1, 1024); } x1 and x2 were declared external so that the optimizer won't optimize references to them away. This generated the following output using O3 level optimization [kevin at kevin temp]$ gcc --version gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [kevin at kevin temp]$ gcc -S -O3 -std=c99 opt.c [kevin at kevin temp]$ cat opt.s .file "opt.c" .text .p2align 2,,3 .globl clear .type clear, at function clear: pushl %ebp movl %esp, %ebp xorl %eax, %eax subl $8, %esp .p2align 2,,3 .L6: movb $0, x1(%eax) ; ** for loop incl %eax cmpl $1023, %eax jle .L6 pushl %eax ; **memset pushl $1024 pushl $1 pushl $x2 call memset leave ret .Lfe1: .size clear,.Lfe1-clear .ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)" So, in this case the loop operates inline, while the memset version pushes parameters onto the stack, then calls an external function. I suspect that the loop version, which generates inline code with hardwired values, is likely to be slightly faster than the call to memset, unless memset is doing something very odd. gcc 4.1.2 generates similiar, but different code. memset still calls an external routine. Which doesn't generate accurate values on VMS.

It was thus said that the Great Kevin Handy once stated: [ some C code to test a loop vs. memset() ] [ Assembly code from GCC ] Well ... how ... disappointing. I played around with GCC 2.7.2.3 (yes, old) and the code produced wasn't different at all, and I tried several different varients to the memset() call (declaring the variable local, reducing the amount set to 4 bytes, changing the type, etc). Now, I could understand if the clear routine accepted a char pointer as a parameter---then you have issues of alignment that the compiler can't make, but that wasn't the case (since you were calling memset() directly on arrays which will have proper alignment). The only thing I can think that memset() might do that is unusual is that on Pentium class machines, using the floating point hardware to write to memory is faster than using the 32 bit registers, but I could only see that being used for Pentium specific code (and even then, only certain generations of the Pentium). Sigh. -spc (Maybe they felt that adding compiler support for memset() wasn't worth the time since most code uses explicit loops?)

It was thus said that the Great der Mouse once stated: Which is why I wish C supported a syntax of: sometype_t foo [MAX]; foo = SOME_VALUE; But then, that wouldn't be C anymore 8-P If foo is declared as sometype_t foo [MAX]; then sizeof(foo) == sizeof(sometype_t) * MAX But if foo is declared as: sometype_t *foo; then yes, sizeof(foo) != sizeof(sometype_t) * MAX -spc (Who still writes CGI based programs in C ... )

Don wrote: Personally I think it's more like "every programmer should have sufficient knowledge of the compiler they're using". By "sufficient" I don't mean that they should know how it'll optimise things in every situation - but they should have a working knowledge of what sorts of constructs will be targets for optimisation. I don't mind people using whatever language they want providing that it's capable of being efficient for the task at hand - but they do need a knowledge of how what they write will be converted into what the computer will actually run. That's one of the things I don't like about languages like C and PHP - they give you 14 different ways of doing any one thing, which makes the learning curve needed to be proficient rather steep. I suppose it's a little like comparing a RISC to a CISC CPU... some languages offer less flexibility and more effort on the part of the programmer, but they tend to result in a faster, more efficient product. -- A. Because it destroys the natural flow of conversation. Q. What's wrong with top posting ?

Sean Conner wrote: Yes and no. What I was optimizing was "make it produce the correct results (numbers) the first time" (since spotting any errors would be a painfully tedious manual task, I wanted to *know* it was bug free from the start).

Jules Richardson wrote: It's already too late. You can meet all of the requirements of your last paragraph with crackberries, sidekicks, via SMS, email, instant pester, and even cell phones. We've all got our leashes.

And thusly were the wise words spake by Dave McGuire That is, until they use power from *you*... Anyone remember B.A.T. for the Amiga? ( http://www.lemonamiga.com/games/details.php?id=128 ) The character you played had a computer implanted into his wrist. Cheers, Bryan

It was thus said that the Great Patrick Finnegan once stated: GPUs do pretty much nothing but vector operations on large data sets. So if your problem matches that domain, you can use a GPS, thus leaving the CPU to tackle other problems. Google could make a killing licensing their GoogleOS (or parts thereof). They manage to use off-the-shelf PCs (and not even the fastest ones) as plug in replacements for their operations. The technology of the software is very impressive. -spc (But I suspect this is getting to be a bit off topic ...)

Paul Heller wrote: Nope -- the millions and millions wall warts!!! I hate them.

Paul Heller wrote: computers. Or we can go back to the days of timesharing and give up all the wonderful user oriented capabilities that a modern UI offers, but if you include the end terminals in the comparison then it was not really a single computer in my mind. No, you don't have to go back to typewriters, but what about just using what is there ? What about workgroups of around 16 X-Terminals, attached to one computer ? Just one computer to update, just one to do backups, just one virus-scanner ? I know, it is an M$ nightmare, but for the rest of us ?