Comparision of C Sharp and C performance
spinoza1111
19 factorial one million times, using both the iterative and recursive
methods to solve (and compare) the results
Here is the C code.
#include <stdio.h>
#include <time.h>
long long factorial(long long N)
{
long long nFactorialRecursive;
long long nFactorialIterative;
long long Nwork;
if (N <= 2) return N;
for ( nFactorialIterative = 1, Nwork = N;
Nwork > 1;
Nwork-- )
nFactorialIterative *= Nwork;
nFactorialRecursive = N * factorial(N-1);
if (nFactorialRecursive != nFactorialIterative)
printf("%I64d! is %I64d recursively but %I64d iteratively wtf!
\n",
N,
nFactorialIterative,
nFactorialRecursive);
return nFactorialRecursive;
}
int main(void)
{
long long N;
long long Nfactorial;
double dif;
long long i;
long long K;
time_t start;
time_t end;
N = 19;
K = 1000000;
time (&start);
for (i = 0; i < K; i++)
Nfactorial = factorial(N);
time (&end);
dif = difftime (end,start);
printf("%I64d! is %I64d: %.2f seconds to calculate %I64d times
\n",
N, Nfactorial, dif, K);
return 0; // Gee is that right?
}
Here is the C Sharp code.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace N_factorial
{
class Program
{
static void Main(string[] args)
{
long N;
long Nfactorial = 0;
TimeSpan dif;
long i;
long K;
DateTime start;
DateTime end;
N = 19;
K = 1000000;
start = DateTime.Now;
for (i = 0; i < K; i++)
Nfactorial = factorial(N);
end = DateTime.Now;
dif = end - start;
Console.WriteLine
("The factorial of " +
N.ToString() + " is " +
Nfactorial.ToString() + ": " +
dif.ToString() + " " +
"seconds to calculate " +
K.ToString() + " times");
return;
}
static long factorial(long N)
{
long nFactorialRecursive;
long nFactorialIterative;
long Nwork;
if (N <= 2) return N;
for ( nFactorialIterative = 1, Nwork = N;
Nwork > 1;
Nwork-- )
nFactorialIterative *= Nwork;
nFactorialRecursive = N * factorial(N-1);
if (nFactorialRecursive != nFactorialIterative)
Console.WriteLine
("The iterative factorial of " +
N.ToString() + " " +
"is " +
nFactorialIterative.ToString() + " " +
"but its recursive factorial is " +
nFactorialRecursive.ToString());
return nFactorialRecursive;
}
}
}
The C Sharp code runs at 110% of the speed of the C code, which may
seem to "prove" the half-literate Urban Legend that "C is more
efficient than C Sharp or VM/bytecode languages in general, d'oh".
As I take pains to point out in my book, "Build Your Own .Net Language
and Compiler" (Apress 2004) (buy it now buy it now), it's not even
grammatical to say that a programming language is more "efficient"
than another pl.
But far more significantly: the ten percent "overhead" would be
several orders of magnitude were C Sharp to be an "inefficient,
interpreted language" which many C programmers claim it is. That is
because a true interpreter parses and/or unpacks each instruction when
it is executed, and both of the above examples execute their
instructions millions of times.
Were C Sharp to be interpreted, the above C Sharp code would run very,
very slowly, but C Sharp isn't interpreted.
Instead, a one-time modification is made to the byte code upon loading
to thread the codes together. This explains part of the ten percent
"overhead". For the remainder of execution, a sort of switch statement
is operating in which the code for individual byte codes using go to
to transfer control. This means that C and C Sharp execute at the same
effective rate of speed, and the ONLY efficiency-based reason for
choosing C is avoiding the initial overhead of setting up the .Net
virtual machine.
But what does this virtual machine provide? Almost 100 percent safety
against memory leaks and many other bad things.
Indeed, C is like the (unwritten) British constitution. In that
arrangement, Parliament cannot "entrench" an act that would bind all
subsequent Parliaments, because Parliamentary supremacy (like the
putative power of C) must at all costs be preserved: this was the
innovation of 1688/9, when Parliament hired King William and his
Better Half as Kingie and Queenie on condition that they be nice and
obey Parliament. This means that in fact the British constitution
contains no protection against a runaway, tyrannical, "long"
Parliament. It promised not to do so in 1911 and confirmed that it
would be nice in 1949, but there is nothing in the British
constitution to prevent Parliament from enacting a new bill, as long
as it could get enough Peers in the House of Lords to wake up and
permit it to do so (Lords approval being required unlike money bills),
and HM the Queen to give Royal Assent.
When Kurt Godel was studying the booklet given him in Princeton to
pass the US Citizenship test, he claimed to find a bug that would
allow America to be a dictatorship. I think he'd be even more
terrified of the British constitution, for like his self-reflexive
paradoxical statement in his incompleteness/inconsistency result, the
very power of Parliament renders it impotent to write a Constitution!
Whereas .Net and Java provide "Constitutional" safeguards against code
doing nasty things even as the American constitution was intended to
be, and to some practical extent is, "a machine that runs of itself".
Both constitutions can fail, but the British constitution is more
likely to. It enabled Margaret Thatcher to rule by decree and override
even her own Cabinet, and ramrod through a medieval "poll tax" in 1990
that produced civil disturbances. Britons enjoy human rights mostly
through the EU. Whereas misuse of the American constitution during
Bush's administration was more vigorously resisted especially in its
courts, where the judges are truly independent.
It is true that a massive "bug" in the American constitution developed
in 1860 with the outbreak of civil war, but this was extra-
Constitutional. It resulted from a deliberate misinterpretation of
state's rights under the Tenth Amendment in which the states retained
a "nullifying" level of sovereignity, but their assent to the
Constitution in 1789 had itself nullified this strong interpretation
of "state's rights".
Since 1689, no such "bug" has occured in the British constitution.
However, the British constitution existed before 1689, and its bug was
just as serious, for it produced the English civil war. This was
because there is no provision in the British constitution for a pig-
headed king, and King Charles II could conceivably in the future
refuse Royal Assent to needed legislation, or use the British Army
(which is NOT under the control of Parliament, but of the Monarch to
whom officers swear fealty) against his own people.
C Sharp programs can fail as can the American Constitution. But the
idiotic equation of the reliability of C and C Sharp in fact resembles
the political passivity of Britons who talk darkly of the EU being a
"new world order" destroying their "rights as Englishmen" when in fact
it's the best thing that ever happened to them. And, I've not
addressed how the rights of Irishmen have been abused under the
British constitution.
I'm for one tired of the Urban Legends of the lower middle class,
whether in programming or politics.
scattered
OT, but *much* more interesting than your rambles about "C:The
Complete Nonsense", etc.
What about the memory footprint of C vs C#? Sure, .Net code is
compiled rather than interpreted so it doesn't have a huge time
penalty - but it is compiled to an intermediate language designed to
run in a *huge* virtual machine. Bloatware which is only slightly
slower than nonbloated code is still bloated and still slower. Also, a
much more interesting question (than simple factorial calculations) is
how something like Microsoft Excel would work if its code base was
rewritten from C to C#. I suspect that the cummulative slowdowns would
result in a spreadsheet which was annoyingly slower.
Out of curiousity, what rules of grammar does the sentence "C is more
effecient than C#." violate?
bartc
news:c3d9c29f-0f7b-41e3...@d4g2000pra.googlegroups.com...
>A C and a C Sharp program was written to calculate the 64-bit value of
> 19 factorial one million times, using both the iterative and recursive
> methods to solve (and compare) the results
>
> Here is the C code.
> Here is the C Sharp code.
> The C Sharp code runs at 110% of the speed of the C code, which may
> seem to "prove" the half-literate Urban Legend that "C is more
> efficient than C Sharp or VM/bytecode languages in general, d'oh".
C# was 10% faster? On my 32-bit machine, the C code was generally faster,
depending on compilers and options.
But changing both to use 32-bit arithmetic, the C was nearly double the
speed of C#, which is what is to be expected.
That's not bad, but C# does need a very complex environment to run, so
cannot be used as a replacement for many uses of C, and it is still slower.
(BTW your timing routines in the C code seem to round to the nearest second;
not very useful for that purpose.)
> Were C Sharp to be interpreted, the above C Sharp code would run very,
> very slowly, but C Sharp isn't interpreted.
There are interpreters, and interpreters. You could be looking at
slow-downs, compared with C, of 3x to 300x, but usually there will be some
benefits that make up for performance deficiencies in these kinds of
benchmarks.
C#, I believe, is executed as native code, after translation from MSIL or
CIL or some such acronym.
--
Bartc
Jens Stuckelberger
> The C Sharp code runs at 110% of the speed of the C code, which may seem
> to "prove" the half-literate Urban Legend that "C is more efficient than
> C Sharp or VM/bytecode languages in general, d'oh".
Really? I would have thought that, at best, it proves that a
particular C# implementation of a particular algorithm, when using a
particular C# virtual machine, on a particular platform, has beaten a
particular C implementation of a particular algorithm, with some
particular C compiler and some particular compile-time settings, on a
particular platform. This, assuming that one can believe you - and why
should we?
If anything, you seem to have proved that you know nothing much
about rigor, and that in this occasion to indulged in forcing facts to
fit your preconceived notions. Way to go.
As for your ranting on the American and British constitutions -
what kind of mental condition affects you?
jacob navia
it does that 10 million times.
Note that the difftime function is not accurate. I used the utility "timethis".
Machine: Intel i7 (8 cores) with 12GB RAM
The results are:
-------------------------------------------------------------------------------------
D:\temp>csc /o tfact.cs C# Optimizations ON
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.
D:\temp>timethis tfact
TimeThis : Command Line : tfact
TimeThis : Start Time : Sun Dec 27 18:33:53 2009
The factorial of 20 is 2432902008176640000: 00:00:03.7460000 seconds to calculate 10000000 times
TimeThis : Command Line : tfact
TimeThis : Start Time : Sun Dec 27 18:33:53 2009
TimeThis : End Time : Sun Dec 27 18:33:57 2009
TimeThis : Elapsed Time : 00:00:03.804
---------------------------------------------------------------------------------------
D:\temp>cl -Ox tfact.c C optimizations ON
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
tfact.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
/out:tfact.exe
tfact.obj
D:\temp>timethis tfact
TimeThis : Command Line : tfact
TimeThis : Start Time : Sun Dec 27 18:34:10 2009
The factorial of 20 is 2432902008176640000: 3.00 seconds to calculate 10000000 times
TimeThis : Command Line : tfact
TimeThis : Start Time : Sun Dec 27 18:34:10 2009
TimeThis : End Time : Sun Dec 27 18:34:13 2009
TimeThis : Elapsed Time : 00:00:02.666
D:\temp>
----------------------------------------------------------------------------------------
The result is clear: C takes 2.666 seconds, C# takes 3.804 seconds
Seebs
> long long factorial(long long N)
> {
> long long nFactorialRecursive;
> long long nFactorialIterative;
> long long Nwork;
> if (N <= 2) return N;
> for ( nFactorialIterative = 1, Nwork = N;
> Nwork > 1;
> Nwork-- )
> nFactorialIterative *= Nwork;
> nFactorialRecursive = N * factorial(N-1);
> if (nFactorialRecursive != nFactorialIterative)
> printf("%I64d! is %I64d recursively but %I64d iteratively wtf!
> \n",
> N,
> nFactorialIterative,
> nFactorialRecursive);
> return nFactorialRecursive;
>
> }
I'm impressed. Very few people could define an N^2 algorithm for calculating
factorials.
Hint: When you call factorial(19), you calculate factorial(19) iteratively,
and then you calculate 19 * factorial(18). You then calculate factorial(18)
iteratively, then calcualte 18 * factorial(17). Etcetera.
In short, for factorial(19), instead of performing 38 multiplications and
19 calls, you perform 19 multiplications and 19 calls for the recursive
calculation, plus 164 multiplications for the iterative calculations.
This is not a reasonable way to go about things. This is a pretty
impressive screwup on your part, and you can't blame the language design;
this is purely at the algorithm-design level, not any kind of mysterious
quirk of C.
Again, the problem isn't with C's design; it's that you are too muddled
to design even a basic test using two algorithms, as you embedded one
in another.
Here's two test programs. One's yours, but I switched to 'long double'
and used 24! instead of 19! as the test case, and multiplied the number
of trials by 10.
The main loop is unchanged except for the change in N and the switch to
%Lf.
Yours:
long double factorial(long double N)
{
long double nFactorialRecursive;
long double nFactorialIterative;
long double Nwork;
if (N <= 2) return N;
for ( nFactorialIterative = 1, Nwork = N; Nwork > 1; Nwork-- )
nFactorialIterative *= Nwork;
nFactorialRecursive = N * factorial(N-1);
if (nFactorialRecursive != nFactorialIterative)
printf("%Lf! is %Lf recursively but %Lf iteratively wtf!\n",
N,
nFactorialIterative,
nFactorialRecursive);
return nFactorialRecursive;
}
Mine:
long double ifactorial(long double N)
{
long double nFactorialIterative;
long double Nwork;
if (N <= 2) return N;
for ( nFactorialIterative = 1, Nwork = N; Nwork > 1; Nwork-- )
nFactorialIterative *= Nwork;
return nFactorialIterative;
}
long double rfactorial(long double N)
{
long double nFactorialRecursive;
if (N <= 2) return N;
nFactorialRecursive = N * rfactorial(N-1);
return nFactorialRecursive;
}
long double factorial(long double N)
{
long double nFactorialRecursive;
long double nFactorialIterative;
nFactorialIterative = ifactorial(N);
nFactorialRecursive = rfactorial(N);
if (nFactorialRecursive != nFactorialIterative)
printf("%Lf! is %Lf recursively but %Lf iteratively wtf!\n",
N,
nFactorialIterative,
nFactorialRecursive);
return nFactorialRecursive;
}
Output from the main loops:
24! is 620448401733239409999872: 14.00 seconds to calculate 10000000 times
24! is 620448401733239409999872: 5.00 seconds to calculate 10000000 times
... Which is to say, no one cares whether C# is faster or slower than C
by a few percent, when non-idiotic code is faster than idiotic code by
nearly a factor of three.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
bartc
"Seebs" <usenet...@seebs.net> wrote in message
news:slrnhjfgf3.7fu...@guild.seebs.net...
>> On Dec 27, 9:36 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>> Here is the C code.
>
>> long long factorial(long long N)
>> {
>> }
>
> I'm impressed. Very few people could define an N^2 algorithm for
> calculating
> factorials.
> Here's two test programs. One's yours, but I switched to 'long double'
> and used 24! instead of 19! as the test case, and multiplied the number
> of trials by 10.
>
> The main loop is unchanged except for the change in N and the switch to
> %Lf.
> Output from the main loops:
>
> 24! is 620448401733239409999872: 14.00 seconds to calculate 10000000 times
> 24! is 620448401733239409999872: 5.00 seconds to calculate 10000000 times
>
> ... Which is to say, no one cares whether C# is faster or slower than C
> by a few percent, when non-idiotic code is faster than idiotic code by
> nearly a factor of three.
It doesn't matter too much that the code was idiotic, provided both
languages were executing the same idiotic algorithm.
The original code wasn't a bad test of long long multiplication in each
language.
--
Bartc
BGB / cr88192
"bartc" <ba...@freeuk.com> wrote in message
news:CMMZm.19365$Ym4....@text.news.virginmedia.com...
> "spinoza1111" <spino...@yahoo.com> wrote in message
> news:c3d9c29f-0f7b-41e3...@d4g2000pra.googlegroups.com...
>>A C and a C Sharp program was written to calculate the 64-bit value of
>> 19 factorial one million times, using both the iterative and recursive
>> methods to solve (and compare) the results
>>
>> Here is the C code.
>
>> Here is the C Sharp code.
>
>> The C Sharp code runs at 110% of the speed of the C code, which may
>> seem to "prove" the half-literate Urban Legend that "C is more
>> efficient than C Sharp or VM/bytecode languages in general, d'oh".
>
> C# was 10% faster? On my 32-bit machine, the C code was generally faster,
> depending on compilers and options.
>
yeah, much more significant may well be what the code actually does...
micro-benchmarks of this sort are rarely telling of overall performance.
something a little larger, such as a ray-tracer, would likely be a better
example.
> But changing both to use 32-bit arithmetic, the C was nearly double the
> speed of C#, which is what is to be expected.
>
yes, but to be fair, C# 'long' == C 'long long'...
(since C# followed Java in making long always 64-bits).
> That's not bad, but C# does need a very complex environment to run, so
> cannot be used as a replacement for many uses of C, and it is still
> slower.
>
> (BTW your timing routines in the C code seem to round to the nearest
> second; not very useful for that purpose.)
>
>> Were C Sharp to be interpreted, the above C Sharp code would run very,
>> very slowly, but C Sharp isn't interpreted.
>
> There are interpreters, and interpreters. You could be looking at
> slow-downs, compared with C, of 3x to 300x, but usually there will be some
> benefits that make up for performance deficiencies in these kinds of
> benchmarks.
>
> C#, I believe, is executed as native code, after translation from MSIL or
> CIL or some such acronym.
>
yeah.
MSIL is the older / original term.
the IL was latter redubbed CIL.
it is much the same as the difference between x86-64, x64, and AMD64 or
EMT64T...
C# is first compiled to MSIL / CIL, and then the JIT stage does further
compilation and optimization.
MSIL is not, in itself, inherently slow.
rather, what usually adds some slowdown is the OO facilities, array
handling, ... this is because the OO is hard to fine-tune to the same extent
as in, say, C++, and because of the use of bounds-checking of arrays
(although there are many cases where bounds checking can be eliminated by
"proving" that it will never fail).
like Java, it uses a particular approach to GC which tends to make GC
inevitable (although, they may do like what many JVM's do, and essentially
pay a slight up-front cost to free objects known-garbage up-front, or
possibly use ref-counting as a culling method).
actually, simple stack machines I have found are underrated.
granted, SSA is a little easier to optimize, but I have gradually learned
from experience what was my original intuition:
a stack machine is generally a much nicer IL stage than trying to connect
the frontend and backend directly with SSA. SSA is nasty, IMO, and it is
much better IME to unwind these internal stack-machines to a pseudo-SSA form
during low-level compilation.
it also leads to the "nicety" that one has a much better idea where the
temporaries and phi's are located, since these tend to emerge "naturally"
from the operations on the virtual stack.
actually, AFAICT, it is much easier to unwind a stack into SSA form than it
is to try to coerce ASTs into SSA. I am not sure then why most other
compilers seem to take the direct AST -> SSA route, since there would not
seem to be a whole lot of difference in terms of the quality of the final
code produced, even though there is a notable difference WRT how much
difference it is to work on the compiler.
nevermind that I may at some point want to redesign RPNIL some (my personal
RPN-based IL), probably essentially "flipping" the stack (IOW: putting
everything in left-to-right ordering, rather than x86-style right-to-left).
this would make it more in-line with pretty much every other RPN.
originally, I chose an essentially backwards ordering, as I had assumed more
or less 1:1 mapping with the underlying x86, and so everything was laid out
to allow a "naive" translator (my original lower-end was rather naive, but
as a cost it has left me with a fairly ugly IL with extra funky rules and a
"backwards" stack ordering).
FWIW, this is no longer with good reason, so I may consider eventual
redesign (and probably also for a lot of the syntax, such as making it
properly token-based, ...).
> --
> Bartc
Seebs
> It doesn't matter too much that the code was idiotic, provided both
> languages were executing the same idiotic algorithm.
True.
> The original code wasn't a bad test of long long multiplication in each
> language.
Fair enough. It's not exactly what I'd call an interesting test case for
real-world code. I'd be a lot more interested in performance of, say,
large lists or hash tables.
spinoza1111
Newer spreadsheets such as Google's are faster but they're mostly
written in C, probably (by highly competent people) owing to
inertia...not in Java and not in C Sharp.
In the example, the C DLL is 5120 bytes whereas the C Sharp DLL is
7680 bytes. Again, not even an order of magnitude, and you get greater
safety for the so-called "bloat".
It's barbaric, given Moore's law, to so overfocus in such a Puritan
way on "bloat" when the number one issue, as Dijkstra said in 2000, is
"not making a mess of it".
spinoza1111
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:c3d9c29f-0f7b-41e3...@d4g2000pra.googlegroups.com...
>
> >A C and a C Sharp program was written to calculate the 64-bit value of
> > 19 factorial one million times, using both the iterative and recursive
> > methods to solve (and compare) the results
>
> > Here is the C code.
> > Here is the C Sharp code.
> > The C Sharp code runs at 110% of the speed of the C code, which may
> > seem to "prove" the half-literate Urban Legend that "C is more
> > efficient than C Sharp or VM/bytecode languages in general, d'oh".
>
> C# was 10% faster? On my 32-bit machine, the C code was generally faster,
> depending on compilers and options.
No, dear boy. 110% means that C Sharp is ten percent SLOWER, and it
means I don't care that it is.
>
> But changing both to use 32-bit arithmetic, the C was nearly double the
> speed of C#, which is what is to be expected.
OK, let's try that at home...
...of course, you do know that the value overflows for C Sharp int and
C long arithmetic. The maximum value we can compute is 12 factorial...
...to maintain realistic execution times, we must change both versions
to execute ten million times.
Oops. Check this out! Here, C Sharp is actually faster!
C Sharp result: The factorial of 12 is 479001600: 00:00:06.8750000
seconds to calculate 10000000 times
C result: 12! is 479001600: 8.00 seconds to calculate 10000000 times
In other words, you changed your version of the code to calculate the
wrong answer "twice as fast" as C Sharp. In other words, you made the
code significantly less "powerful" to get the wrong result, and when
we fix it, C runs slower. This is probably because cache usage, which
is easily implemented safely in a hosted VM, becomes more and more
important the more the same code is executed on similar data.
>
> That's not bad, but C# does need a very complex environment to run, so
> cannot be used as a replacement for many uses of C, and it is still slower.
Excuse me, but that's a canard. C, to run efficiently, needs a
complete optimizer. A VM is less complex. Architectures have in fact
been tuned in very complex ways to run C adequately in ways that have
caused errors, perhaps including the Intel arithmetic bug.
Whereas in OO designs such as are effectively supported by VM-hosted
languages like C Sharp and Java, data can be retained in stateful
objects making cacheing at all levels a natural gesture. For example,
a stateful factorial class can save each factorial calculated over its
execution lifetime. A C program cannot do this without saving material
at a global level thats overly visible to other modules.
>
> (BTW your timing routines in the C code seem to round to the nearest second;
> not very useful for that purpose.)
Yes...the timing routines standard in C SHARP EXPRESS, shipped free to
script kiddies and even girl programmers world wide, are superior to
the stuff in C.
>
> > Were C Sharp to be interpreted, the above C Sharp code would run very,
> > very slowly, but C Sharp isn't interpreted.
>
> There are interpreters, and interpreters. You could be looking at
> slow-downs, compared with C, of 3x to 300x, but usually there will be some
> benefits that make up for performance deficiencies in these kinds of
> benchmarks.
No. An interpreter has a fixed overhead K for each instruction, and in
programs like this, K is multipled many, many times. C Sharp is not
interpreted save in the male programmer subconscious which because of
the very real emasculation he faces in the corporation, fears a
fantasy emasculation implicit in not using his father's language.
C sharp doesn't have this.
>
> C#, I believe, is executed as native code, after translation from MSIL or
> CIL or some such acronym.
That is more or less correct.
>
> --
> Bartc
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
>Newer spreadsheets such as Google's are faster but they're mostly
>written in C, probably (by highly competent people) owing to
>inertia...not in Java and not in C Sharp.
>
>In the example, the C DLL is 5120 bytes whereas the C Sharp DLL is
>7680 bytes. Again, not even an order of magnitude, and you get greater
>safety for the so-called "bloat".
>
>It's barbaric, given Moore's law, to so overfocus in such a Puritan
>way on "bloat" when the number one issue, as Dijkstra said in 2000, is
>"not making a mess of it".
Obviously, neither you nor Dijkstra understand the true economic
underpinnings of the software biz. The whole point is to be hot, sexy,
and broken. Repeat that a few times to get the point.
Because, as I've said so many times, if they ever actually solve the
problem in the software world, the business is dead. And this has
serious economic consequences for everyone. Think job-loss, which is
generally considered the worst thing imaginable.
There are many examples of situations where programmers did actually
solve their problem and ended up on unemployment as a result. At the
bigger, company level, think Windows XP. MS basically solved the OS
problem with Windows XP. They were thus forced to tear it up and start
over with Vista/Windows 7/etc.
spinoza1111
<Jens_Stuckelber...@nowhere.net> wrote:
> On Sun, 27 Dec 2009 06:36:54 -0800,spinoza1111wrote:
> > The C Sharp code runs at 110% of the speed of the C code, which may seem
> > to "prove" the half-literate Urban Legend that "C is more efficient than
> > C Sharp or VM/bytecode languages in general, d'oh".
>
> Really? I would have thought that, at best, it proves that a
> particular C# implementation of a particular algorithm, when using a
> particular C# virtual machine, on a particular platform, has beaten a
> particular C implementation of a particular algorithm, with some
> particular C compiler and some particular compile-time settings, on a
> particular platform. This, assuming that one can believe you - and why
> should we?
>
> If anything, you seem to have proved that you know nothing much
> about rigor, and that in this occasion to indulged in forcing facts to
> fit your preconceived notions. Way to go.
Blow me, dear chap. In fact, we can generalize from what we see, as
long as we take the results cum grano salis.
>
> As for your ranting on the American and British constitutions -
> what kind of mental condition affects you?
I'd call it literacy, dear boy. You see, to help a student, I read AV
Dicey's Introduction to the Study of the Law of the Constitution and
Ian Loveland's Constitutional Law, Administrative Law, and Human
Rights cover to cover over a couple of weeks. Like Godel, I noticed
some quasi-mathematical paradoxes, in my case in the British
constitution. I thought them amusing.
spinoza1111
Previous chap had a glimmer of insight with which I partly agreed. We
do have to take individual results cum grano salis. We need to think
here only in terms of orders of magnitude, and you haven't shown, Mr.
Navia, and with all due respect, that C Sharp runs an order of
magnitude or more slower, which it would be if *le canard* that "C
Sharp is for girls and script kiddies because it is interpreted" were
true, which we have falsified.
Thanks for the better timer. However, part of the C problem is the
fact that suboptimal library routines appear first in documentation
whereas in C Sharp, best of breed is at the top.
spinoza1111
> > On Dec 27, 9:36 am,spinoza1111<spinoza1...@yahoo.com> wrote:
> > Here is the C code.
> > long long factorial(long long N)
> > {
> > long long nFactorialRecursive;
> > long long nFactorialIterative;
> > long long Nwork;
> > if (N <= 2) return N;
> > for ( nFactorialIterative = 1, Nwork = N;
> > Nwork > 1;
> > Nwork-- )
> > nFactorialIterative *= Nwork;
> > nFactorialRecursive = N * factorial(N-1);
> > if (nFactorialRecursive != nFactorialIterative)
> > printf("%I64d! is %I64d recursively but %I64d iteratively wtf!
> > \n",
> > N,
> > nFactorialIterative,
> > nFactorialRecursive);
> > return nFactorialRecursive;
>
> > }
>
> I'm impressed. Very few people could define an N^2 algorithm for calculating
> factorials.
Hold on to your hats, it's Scripto Boy, who's never taken a computer
science class..
You misunderstood the solution, Scripto boy, just as you misunderstood
Schildt; and as in the case of Schildt, you use your own mental
confusion to attack the credibility of your elders and betters. I
don't care that within each recursion I recalculate the next value of
N both ways, recursively and iteratively. Indeed, it was my goal to
get meaningful performance numbers by executing many, many
instructions repeatedly. Since I can look up factorials in seconds, I
did not need a new factorial program, as you so very foolishly seem to
believe.
My point was the absence of "interpretive overhead" in the C sharp
caused it to run at (far) less than 1 order of magnitude slower than
the C code, and that by migrating to C sharp one avoids the legacy
unsafety and stupidity of C, as well as its fragmentation into
mutually warring tribes, with the attendant bad feeling and politics
of personalities.
I suggest you return to school and acquire academic qualifications and
the ability to behave like a professional before ruining people's
reputations with falsehoods, Scripto boy.
>
> -s
> --
> Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
Also, it's a mistake to use "long double" for a mathematical function
that is defined only for integers in terms of stylistic
communication...although it is not likely here that double precision
errors would play a role. Long double doesn't even make a difference
in Microsoft C++ as far as I know.
So, "we" are not impressed with your stunt. You optimized code not
meant to be optimized, removing "our" ability to detect, at some
sufficiently long execution time to confirm that "C is an order of
magnitude faster than C sharp", at which point, and only at which
point, would "we" be interested in converting back to C. You
calculated the exact value of 24 factorial faster for no reason,
whereas I ran code side by side to test whether C provides
sufficiently dramatic and repeatable performance savings to warrant
even considering its use. I proved it does not.
As to lists and hash tables: C Sharp provides these precoded using
state of the art and best of breed algorithms written by really cool
guys, perhaps Ray Chen and Adam Barr. Whereas in C, one's always being
advised to visit some really creepy site to download some creep's
code, bypassing exhortations to come to Jesus and advertisements for
ammo. As King Lear said, it would be a "delicate stratagem", not to
shoe a troop of horse with felt, but to write lists and hash tables,
but us grownups have better things to do at this time.
Peter Seebach, we are not amused.
spinoza1111
wrote:
ROTFLMAO. Hey is that why I'm a teacher in Asia? Izzit cuz I was such
a great programmer, actually providing Bell Northern Research and
Princeton which stuff that worked, instead of posting nasty notes
about Herb Schildt? I like to think I prefer to be a teacher, but
perhaps I'm Deludo Boy.
Thanks as always for another five star and amusing remark. Have one on
me.
She's hot sexy and broke
And that ain't no joke
spinoza1111
Glad you asked. It violates a semantic rule. A LANGUAGE cannot be
"efficient" unless it must be executed by a strict interpreter (code
that unlike a Java or .Net virtual machine does something each time
each instruction is executed that takes K time). But, of course, C
Sharp can be compiled. Sure, extra instructions are compiled in that
check array bounds, but these are very nice things if one takes
responsibility for one's code after some clown has changed it.
Bjarne Stroustrup somewhere writes about programmers who claim that it
is "inefficient" to keep run time tests and asserts() in code after it
is released to "production". He compares them to sailors who leave
port without lifeboats or life jackets.
Most programmers have only a crude and overly normative understanding
of what "efficiency" is. It's not raw and blinding speed. For example,
Peter Seebach thinks it was more "efficient" to take loops out that
needed to stay in code meant to be a simple benchmarks.
Indeed, many times, "inefficient" means "I don't want to think".
"Far from perceiving such prohibitions on thought as something
hostile, the candidates – and all scientists are candidates – feel
relieved. Because thinking burdens them with a subjective
responsibility, which their objective position in the production-
process prevents them from fulfilling, they renounce it, shake a bit
and run over to the other side. The displeasure of thinking soon turns
into the incapacity to think at all: people who effortlessly invent
the most refined statistical objections, when it is a question of
sabotaging a cognition, are not capable of making the simplest
predictions of content ex cathedra [Latin: from the chair, e.g. Papal
decision]. They lash out at the speculation and in it kill common
sense. The more intelligent of them have an inkling of what ails their
mental faculties, because the symptoms are not universal, but appear
in the organs, whose service they sell. Many still wait in fear and
shame, at being caught with their defect. All however find it raised
publicly to a moral service and see themselves being recognized for a
scientific asceticism, which is nothing of the sort, but the secret
contour of their weakness. Their resentment is socially rationalized
under the formula: thinking is unscientific. Their intellectual energy
is thereby amplified in many dimensions to the utmost by the mechanism
of control. The collective stupidity of research technicians is not
simply the absence or regression of intellectual capacities, but an
overgrowth of the capacity of thought itself, which eats away at the
latter with its own energy. The masochistic malice [Bosheit] of young
intellectuals derives from the malevolence [Bösartigkeit] of their
illness."
TW Adorno, Minima Moralia (Reflections on Damaged Life) 1948
stan
>
> In article <786af291-2bc3-4f43...@d20g2000yqh.googlegroups.com>,
> spinoza1111 <spino...@yahoo.com> wrote:
> ...
>>Newer spreadsheets such as Google's are faster but they're mostly
>>written in C, probably (by highly competent people) owing to
>>inertia...not in Java and not in C Sharp.
>>
>>In the example, the C DLL is 5120 bytes whereas the C Sharp DLL is
>>7680 bytes. Again, not even an order of magnitude, and you get greater
>>safety for the so-called "bloat".
>>
>>It's barbaric, given Moore's law, to so overfocus in such a Puritan
>>way on "bloat" when the number one issue, as Dijkstra said in 2000, is
>>"not making a mess of it".
>
> Obviously, neither you nor Dijkstra understand the true economic
> underpinnings of the software biz. The whole point is to be hot, sexy,
> and broken. Repeat that a few times to get the point.
It seems that you consider yourself quite knowledgeable and expert,
even superior to Dijkstra, yet you offer so little actual news or
information actually about C.
In fact I have to wonder, do you ever actually contribute anything
about the C programming language?
> Because, as I've said so many times, if they ever actually solve the
> problem in the software world, the business is dead. And this has
> serious economic consequences for everyone. Think job-loss, which is
> generally considered the worst thing imaginable.
>
> There are many examples of situations where programmers did actually
> solve their problem and ended up on unemployment as a result. At the
> bigger, company level, think Windows XP. MS basically solved the OS
> problem with Windows XP. They were thus forced to tear it up and start
> over with Vista/Windows 7/etc.
This sort of sarcasm, petty whining, attempted humor, ... can get
boorish when applied, in your words, "many times". Just a thought but
the phrase "you can be part of the problem, or you can be part of the
solution" springs to mind often when trying to follow threads.
As for the topic/rant in question, if I ever set out to develop a
project for only a MS proprietary platform I'll probably care about C#
vs options but since my normal development world is not MS the
question isn't really important for me personally. My world also
slants more towards system stuff than the latest shiny user app - in
other words I'm not fascinated by eye candy. I seem to be in a
minority admittedly. But in my world the fact that C is used to build
C tools intuitively feels like a win. No intended swipe here but does
a C# compiler for C# exist? With source for study?
bartc
> On Dec 28, 1:25 am, "bartc" <ba...@freeuk.com> wrote:
>> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>>
>> news:c3d9c29f-0f7b-41e3...@d4g2000pra.googlegroups.com...
>>
>>> A C and a C Sharp program was written to calculate the 64-bit value
>>> of 19 factorial one million times, using both the iterative and
>>> recursive methods to solve (and compare) the results
>>
>>> Here is the C code.
>>> Here is the C Sharp code.
>>> The C Sharp code runs at 110% of the speed of the C code, which may
>>> seem to "prove" the half-literate Urban Legend that "C is more
>>> efficient than C Sharp or VM/bytecode languages in general, d'oh".
>>
>> C# was 10% faster? On my 32-bit machine, the C code was generally
>> faster, depending on compilers and options.
>
> No, dear boy. 110% means that C Sharp is ten percent SLOWER, and it
> means I don't care that it is.
So about 90% of the speed of C.
>>
>> But changing both to use 32-bit arithmetic, the C was nearly double
>> the speed of C#, which is what is to be expected.
>
> OK, let's try that at home...
>
> ...of course, you do know that the value overflows for C Sharp int and
> C long arithmetic. The maximum value we can compute is 12 factorial...
I didn't care; both versions overflowed to give the same wrong result. I
just didn't want the results dominated by the attempting 64-bit multiplies
on my 32-bit machine.
> ...to maintain realistic execution times, we must change both versions
> to execute ten million times.
>
> Oops. Check this out! Here, C Sharp is actually faster!
>
> C Sharp result: The factorial of 12 is 479001600: 00:00:06.8750000
> seconds to calculate 10000000 times
> C result: 12! is 479001600: 8.00 seconds to calculate 10000000 times
Check again. I got 5.4 seconds for C# and 3.0 seconds for C. Are you using
32-bits in C, where it's not always obvious?
> In other words, you changed your version of the code to calculate the
> wrong answer "twice as fast" as C Sharp. In other words, you made the
> code significantly less "powerful" to get the wrong result, and when
> we fix it, C runs slower. This is probably because cache usage, which
> is easily implemented safely in a hosted VM, becomes more and more
> important the more the same code is executed on similar data.
In this tiny program everything should fit into the cache.
>> That's not bad, but C# does need a very complex environment to run,
>> so cannot be used as a replacement for many uses of C, and it is
>> still slower.
>
> Excuse me, but that's a canard. C, to run efficiently, needs a
> complete optimizer. A VM is less complex. Architectures have in fact
> been tuned in very complex ways to run C adequately in ways that have
> caused errors, perhaps including the Intel arithmetic bug.
An optimising C compiler is a few MB, and is not needed to run the result.
To compile your C# code, I needed a 63MB download. Then I needed .NET which
probably was already in my OS, but appears to 'take up to 500MB of hard disk
space'.
The C version would have required a few tens of KB in total to run.
>> (BTW your timing routines in the C code seem to round to the nearest
>> second; not very useful for that purpose.)
>
> Yes...the timing routines standard in C SHARP EXPRESS, shipped free to
> script kiddies and even girl programmers world wide, are superior to
> the stuff in C.
C's clock() function gives elapsed times in msec.
--
Bartc
Kenny McCormack
attempted a bunch of lame flames in my direction:
(snip)
What rock did you just climb out from under?
(Or, equivalently, which reg are you a sock puppet of?)
Seebs
> In fact I have to wonder, do you ever actually contribute anything
> about the C programming language?
I saw it happen once.
Oddly, over in comp.unix.shell, he actually contributes topical material
and shows technical understanding, so it's not a general incapacity. I
guess he's just butthurt about comp.lang.c for some reason.
-s
--
Keith Thompson
[...]
> C's clock() function gives elapsed times in msec.
No, it gives CPU time (not elapsed time), expressed as a value
of type clock_t. To get the time in seconds, the result must be
scaled by dividing by CLOCKS_PER_SEC.
On one system I just tried, clock_t is compatible with signed long,
and CLOCKS_PER_SEC is 1000000; on another, clock_t is compatible
with unsigned long, and CLOCKS_PER_SEC is 1000. (Note that on the
first system I tried, clock_t values will overflow in less than 36
CPU minutes.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
stan
>
>
> On 2009-12-28, stan <smo...@exis.net> wrote:
>> In fact I have to wonder, do you ever actually contribute anything
>> about the C programming language?
>
> I saw it happen once.
>
> Oddly, over in comp.unix.shell, he actually contributes topical material
> and shows technical understanding, so it's not a general incapacity. I
> guess he's just butthurt about comp.lang.c for some reason.
I can add the same observation for awk stuff where he appears lucid,
but I have to admit I question more and more of what I see from
him. When I find myself agreeing with him I start to wonder if I AM wrong.
I must agree with your word choice "odd".
spinoza1111
The fact is that corporate programmers do have short careers which
tend not to be adequate to raise a family: studies have found that
many programmers find it almost impossible to get work after more than
ten years of experience, even if they retrain.
I was an anomaly not because I retrained, although I learned C in the
1980s and .Net more recently, but because I work out regularly even
today and therefore look significantly younger than I am, with the
result that I worked continuously from Nov 1971 to 2005.
Slogans from the 1960s don't change the fact that programmers, as
people who carry out the will of most uncaring managements in the most
excruciating detail, are treated like dirt, and respond not with
solidarity but with regression, here, to what Adorno called "the
nightmare of childhood": Fascism.
>
> As for the topic/rant in question, if I ever set out to develop a
> project for only a MS proprietary platform I'll probably care about C#
> vs options but since my normal development world is not MS the
> question isn't really important for me personally. My world also
> slants more towards system stuff than the latest shiny user app - in
> other words I'm not fascinated by eye candy. I seem to be in a
> minority admittedly. But in my world the fact that C is used to build
> C tools intuitively feels like a win. No intended swipe here but does
> a C# compiler for C# exist? With source for study?
I wrote and published a Visual Basic .Net compiler for most of Quick
Basic for study. Cf. "Build Your Own .Net Language and Compiler",
Edward G Nilges, Apress 2004.
There's no reason why a C Sharp compiler couldn't be written for C
Sharp.
spinoza1111
> spinoza1111wrote:
> > On Dec 28, 1:25 am, "bartc" <ba...@freeuk.com> wrote:
> >> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> >>news:c3d9c29f-0f7b-41e3...@d4g2000pra.googlegroups.com...
>
> >>> A C and a C Sharp program was written to calculate the 64-bit value
> >>> of 19 factorial one million times, using both the iterative and
> >>> recursive methods to solve (and compare) the results
>
> >>> Here is the C code.
> >>> Here is the C Sharp code.
> >>> The C Sharp code runs at 110% of the speed of the C code, which may
> >>> seem to "prove" the half-literate Urban Legend that "C is more
> >>> efficient than C Sharp or VM/bytecode languages in general, d'oh".
>
> >> C# was 10% faster? On my 32-bit machine, the C code was generally
> >> faster, depending on compilers and options.
>
> > No, dear boy. 110% means that C Sharp is ten percent SLOWER, and it
> > means I don't care that it is.
>
> So about 90% of the speed of C.
Yes. And you get much higher levels of built-in reality for that ten
percent.
>
>
>
> >> But changing both to use 32-bit arithmetic, the C was nearly double
> >> the speed of C#, which is what is to be expected.
>
> > OK, let's try that at home...
>
> > ...of course, you do know that the value overflows for C Sharp int and
> > C long arithmetic. The maximum value we can compute is 12 factorial...
>
> I didn't care; both versions overflowed to give the same wrong result. I
> just didn't want the results dominated by the attempting 64-bit multiplies
> on my 32-bit machine.
>
> > ...to maintain realistic execution times, we must change both versions
> > to execute ten million times.
>
> > Oops. Check this out! Here, C Sharp is actually faster!
>
> > C Sharp result: The factorial of 12 is 479001600: 00:00:06.8750000
> > seconds to calculate 10000000 times
> > C result: 12! is 479001600: 8.00 seconds to calculate 10000000 times
>
> Check again. I got 5.4 seconds for C# and 3.0 seconds for C. Are you using
> 32-bits in C, where it's not always obvious?
Yes, and it's obvious. I am using int in C Sharp and long in C, where
"int" in C Sharp means 32 bits and "long" in C means 32 bits.
>
> > In other words, you changed your version of the code to calculate the
> > wrong answer "twice as fast" as C Sharp. In other words, you made the
> > code significantly less "powerful" to get the wrong result, and when
> > we fix it, C runs slower. This is probably because cache usage, which
> > is easily implemented safely in a hosted VM, becomes more and more
> > important the more the same code is executed on similar data.
>
> In this tiny program everything should fit into the cache.
Hmm..."the" cache. There is "a" stack at runtime, and Schildt was
correct in using the definite article. But "the" cache? Anyway, it
appears that if there was "a" cache, it worked better in .Net.
>
> >> That's not bad, but C# does need a very complex environment to run,
> >> so cannot be used as a replacement for many uses of C, and it is
> >> still slower.
>
> > Excuse me, but that's a canard. C, to run efficiently, needs a
> > complete optimizer. A VM is less complex. Architectures have in fact
> > been tuned in very complex ways to run C adequately in ways that have
> > caused errors, perhaps including the Intel arithmetic bug.
>
> An optimising C compiler is a few MB, and is not needed to run the result.
> To compile your C# code, I needed a 63MB download. Then I needed .NET which
> probably was already in my OS, but appears to 'take up to 500MB of hard disk
> space'.
Boo hoo. If safety means anything, then 500MB is worth it. Were not
running our Commodore 64 in Mom's basement any more.
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote his usual good stuff:
...
Be aware that this "stan" character is a toad. Let's not bother with him.
He is almost certainly also a sock of one of the regs - probably Seebs.
spinoza1111
> On 2009-12-27, bartc <ba...@freeuk.com> wrote:
>
> > It doesn't matter too much that the code was idiotic, provided both
> > languages were executing the same idiotic algorithm.
>
> True.
>
> > The original code wasn't a bad test of long long multiplication in each
> > language.
>
> Fair enough. It's not exactly what I'd call an interesting test case for
> real-world code. I'd be a lot more interested in performance of, say,
> large lists or hash tables.
>
> -s
> --
C code to hash several numbers, iterated to get somewhat better
performance numbers.
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#define ARRAY_SIZE 1000
#define SESSIONS 100000
int main(void)
{
int hash[ARRAY_SIZE];
int i;
int r;
int j;
int k;
int collisions;
time_t start;
time_t end;
double dif;
int tests;
int sessions;
time (&start);
for (sessions = 0; sessions < SESSIONS; sessions++)
{
for (i = 0; i < ARRAY_SIZE; i++) hash[i] = 0;
collisions = 0;
tests = ARRAY_SIZE;
for (i = 0; i < tests; i++)
{
r = rand();
j = r % ARRAY_SIZE;
k = j;
if (hash[j] != 0) collisions++;
while(hash[j] != r && hash[j] != 0)
{
if (j >= ARRAY_SIZE) j = 0; else j++;
if (j==k)
{
printf("Table is full\n");
break;
}
}
if (hash[j] == 0) hash[j] = r;
}
}
time (&end);
dif = difftime (end,start);
printf("It took C %.2f seconds to hash %d numbers with %d
collisions, %d times\n",
dif, tests, collisions, sessions);
return 0; // Gee is that right?
}
C Sharp code to do the same:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
HashSet<int> hash = null;
hash = new HashSet<int>();
Random R = new Random(1);
int i;
int j;
TimeSpan dif;
DateTime start;
DateTime end;
start = DateTime.Now;
int sessions = 100000;
int tests = 1000;
for (i = 0; i < sessions; i++)
{
hash.Clear();
for (j = 0; j < tests; j++)
hash.Add(R.Next(32767));
}
end = DateTime.Now;
dif = end - start;
Console.WriteLine
("It took C Sharp " +
dif.ToString() + " " +
"seconds to hash " +
tests.ToString() + " numbers " +
sessions.ToString() + " times");
return; // Ha ha I don't have to worry about the
shibboleth
}
}
}
The C Sharp code is not only smaller above, it runs dramatically
faster: 24 secs on my machine as contrasted with 35 secs for the C
code.
This is because the HashSet (also available in Java) can be written as
fast as you like in that it's a part of the extended "os". It may
itself be written in C, and please note that this does NOT mean that
YOU should write in C after all, because the HashSet was written state
of the art by studly guys and gals at Microsoft, and painstakingly
reviewed by other studly guys and gals.
And no, I don't want to visit some creepy site to get best C practise
for hashing. The fact is that the research it takes at creepy come-to-
Jesus and ammo sites to find "good" C, quite apart from its being a
waste of spirit in an expense of shame, provides no "forensic"
assurance that the creepy guy who gave you the code didn't screw up or
insert a time bomb. HashSet is available, shrink-wrapped and out of
the box, and IT RUNS TWICE AS FAST.
HashSet can even safely run as managed code but be developed as Java
bytecode or .Net MSIL as a form of safe assembler language. When it is
maintained by the vendor, you get the benefit. Whereas el Creepo's
code is all you get, period, unless you call him a year later, only to
find that his ex-wife has thrown him out the house.
C is NOT more "efficient" than C Sharp. That is not even a coherent
thing to say.
Furthermore, even the best of us screw up (as I have screwn up) when
implementing the basics. Donald R Knuth has said that he always gets
binary search wrong the first time he recodes it. It is a mark of the
smart person to have trouble with low-level math and code; Einstein
(cf Walter Kaufman's bio) had in fact a great deal of difficulty
working out the details of relativistic mathematics and required help
from other mathematicians and physicists.
Therefore we class acts prefer C Sharp.
spinoza1111
And don't waste my time. Yes, the C hash is oversimplified and creates
clusters, slowing it down dramatically as the table fills up. A
"delicate stratagem" would be of course to make each entry a linked
list base which would reduce the search time on average for each new
number to K times the average number of collisions C. In the C code
above the search time is larger than K*C because it's affected by
neighboring collisions. As the table fills up, the search time
increases very rapidly towards the maximum which is the total table
size. In the linked list solution (not implemented here but all over
Knuth and the Knet like a rash) search time is ALWAYS K*C!
But that's my point. Whereas it's a very good idea to reinvent the
wheel the place to do it is in an ACM approved Komputer Science Skool,
not on the job. Anyone who neglects academic training is a net cost to
a Korporation that pays him to write C so he can learn what he shuddha
learnt. 'Course, I wouldn't be talking about any auto-didact here.
There is nothing wrong with being an auto-didact as long as you don't
set out to destroy alter-didacts with MSCSen and BSen from the Univ of
Illinois.
My guess is that the studly Dudleys who developed Hashset went to
Komputer Skool and learnt their Knuth. That's because when I was at
Princeton, I helped people with their Microsoft interview having
crashed and burned at it myself in the spirit of people who flunked
their exams in ancient China and who started Konfucian Skewls in
preference, with one exception, to deciding they we're Christ's baby
brother and starting the Tai'ping revolution. Microsoft was, for
technical positions, exclusively recruiting comp sci majors.
spinoza1111
What the hell kind of thing is this to say about another person? It's
less wrong to be wrong on some technical matter than to lie, as
Richard Heathfield has lied, about another person's publications in
comp.risks, or to start what's little more than a rumor about Schildt.
These are evil acts. Being wrong on some technical matter is NOT evil.
If a person lies, you can't trust him on technical matters, whereas if
a person merely makes technical mistakes, you can at least trust him
like you trust a monkey with a typewriter or wikipedia. He might
occasionally have insights, as does Shakespeare's Fool in King Lear.
In fact, one of the lessons Gerald "The Psychology of Computer
Programming" Weinberg relays is that even junior people in structured
walkthroughs could spot bugs, in some cases faster than the "senior"
programmers.
What bothers you about Kenny is that he has a sense of humor and mocks
the utter pretense of the regs.
spinoza1111
>
> > In article <786af291-2bc3-4f43-af7f-efacfa6b9...@d20g2000yqh.googlegroups.com>,
The problem is that the C tools had to be built to make C even
minimally useful. I realize that this was in part intentional on
Kernighan and Ritchie's part. C was intended to be the essential
kernel of a system extended with libraries.
But the best laid plans...instead of being extended with best of breed
libraries, C programmers remained chained to the original libraries
such as the abominable string library. Note that in a sense, the
abomination of desolation that is the Nul terminated string is not a
part of the C language. Instead, true C is a RISC language that
completely omits strings. You don't have to use strings, or you can
use a correct implementation that embeds a length code, or joins
strings with links into unbounded ropes.
Samuel Johnson if he did not think Scotland had many noble and wild
prospects:
"Mr. Ogilvie then took new ground, where, I suppose, he thought
himself perfectly safe; for he observed, that Scotland had a great
many noble wild prospects. JOHNSON. 'I believe, Sir, you have a great
many. Norway, too, has noble wild prospects; and Lapland is remarkable
for prodigious noble wild prospects. But, Sir, let me tell you, the
noblest prospect which a Scotchman ever sees, is the high road that
leads him to England!'"
C likewise contains certain Noble and Wild prospects, but the Noblest
prospect which a C programmer ever sees is his first .Net C Sharp
program.
bartc
> On Dec 28, 5:10 am, Seebs <usenet-nos...@seebs.net> wrote:
>> I'd be a lot more interested in performance of, say,
>> large lists or hash tables.
> C code to hash several numbers, iterated to get somewhat better
> performance numbers.
> C Sharp code to do the same:
> The C Sharp code is not only smaller above, it runs dramatically
> faster: 24 secs on my machine as contrasted with 35 secs for the C
> code.
C was a bit faster on my machine.
But, you are now starting to get away from good benchmarking practices, by
comparing a implementation of something in one language, with a built-in
version in another.
This is a little dangerous: you might well find that feature is faster, or
just a little slower, in ruby, python or perl. Does that mean these
scripting languages should replace C or even C#?
> Therefore we class acts prefer C Sharp.
I quite respect C# as a language, but it would be nice if it could be
extracted from the clutches of MS and existed independently.
--
Bartc
bartc
>>> In other words, you changed your version of the code to calculate
>>> the wrong answer "twice as fast" as C Sharp. In other words, you
>>> made the code significantly less "powerful" to get the wrong
>>> result, and when we fix it, C runs slower. This is probably because
>>> cache usage, which is easily implemented safely in a hosted VM,
>>> becomes more and more important the more the same code is executed
>>> on similar data.
>>
>> In this tiny program everything should fit into the cache.
>
> Hmm..."the" cache. There is "a" stack at runtime, and Schildt was
> correct in using the definite article. But "the" cache? Anyway, it
> appears that if there was "a" cache, it worked better in .Net.
Whatever. It's probably the same one you mentioned first. And if C# runs on
it, then it's quite likely to have cache memory, hardware stack, the
complete works.
--
Bartc
spinoza1111
> spinoza1111wrote:
> > On Dec 28, 5:10 am, Seebs <usenet-nos...@seebs.net> wrote:
> >> I'd be a lot more interested in performance of, say,
> >> large lists or hash tables.
> > C code to hash several numbers, iterated to get somewhat better
> > performance numbers.
> > C Sharp code to do the same:
> > The C Sharp code is not only smaller above, it runs dramatically
> > faster: 24 secs on my machine as contrasted with 35 secs for the C
> > code.
>
> C was a bit faster on my machine.
>
> But, you are now starting to get away from good benchmarking practices, by
> comparing a implementation of something in one language, with a built-in
> version in another.
But that's my point. Not only do you not have to "reinvent the wheel",
the built-in wheel is better and safer to use.
>
> This is a little dangerous: you might well find that feature is faster, or
> just a little slower, in ruby, python or perl. Does that mean these
> scripting languages should replace C or even C#?
No. The real issue is software safety.
>
> > Therefore we class acts prefer C Sharp.
>
> I quite respect C# as a language, but it would be nice if it could be
> extracted from the clutches of MS and existed independently.
It does: Google the mono project. Microsoft has in fact worked hard to
make .Net open architecture (if closed source).
>
> --
> Bartc
Moi
> 000
In your C example, you are using linear probing combined
with a fill factor of 100%. That is a bad choice, IMO.
Also, beware of rand(). It is guaranteed to deliver only 15 bits of random.
Implementations _may_ produce a larger range of values.
HTH,
AvK
Ben Bacarisse
> spinoza1111 wrote:
>> On Dec 28, 5:10 am, Seebs <usenet-nos...@seebs.net> wrote:
>
>>> I'd be a lot more interested in performance of, say,
>>> large lists or hash tables.
>
>> C code to hash several numbers, iterated to get somewhat better
>> performance numbers.
>
>> C Sharp code to do the same:
>
>> The C Sharp code is not only smaller above, it runs dramatically
>> faster: 24 secs on my machine as contrasted with 35 secs for the C
>> code.
>
> C was a bit faster on my machine.
>
> But, you are now starting to get away from good benchmarking
> practices, by comparing a implementation of something in one language,
> with a built-in version in another.
I think it is much worse than that. The C# code can chose the table
size for good performance (and I can't imagine it would not). In the
C version, the table was chosen to be as bad as it could be without
failing (i.e. exactly the same size as the number of numbers being put
into the set).
There is no evidence that any attempt at a reasonable comparison is
being attempted, here.
To perform the same task, the obvious C solution would use a bit
array, since the number range in the C# code was quite small, but I
suspect that was an arbitrary choice.
--
Ben.
bartc
OK I'll have a closer look at Mono for Windows, although I was really
talking about the core language, ie. without it's complex environment.
--
Bartc
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
>> C was a bit faster on my machine.
>>
>> But, you are now starting to get away from good benchmarking practices, by
>> comparing a implementation of something in one language, with a built-in
>> version in another.
>
>But that's my point. Not only do you not have to "reinvent the wheel",
>the built-in wheel is better and safer to use.
Hot, sexy, broken. Full employment. C is good.
Seriously, does anyone not see just how bad the economy could get if
software actually worked?
Seebs
> spinoza1111 wrote:
>> It does: Google the mono project. Microsoft has in fact worked hard to
>> make .Net open architecture (if closed source).
> OK I'll have a closer look at Mono for Windows, although I was really
> talking about the core language, ie. without it's complex environment.
In any event, it's a red herring; Mono exists to make people think C# is
an open language, when it is in fact nothing of the sort. It's a pure
deception, so far as I can tell.
-s
--
Seebs
> In your C example, you are using linear probing combined
> with a fill factor of 100%. That is a bad choice, IMO.
The unanswerable question:
Did he do that because he's fundamentally dishonest, and wanted to rig the
test to look bad for C, or did he do that because he doesn't understand
the algorithm well enough to do better?
-s
--
Moi
> On 2009-12-29, Moi <ro...@invalid.address.org> wrote:
>> In your C example, you are using linear probing combined with a fill
>> factor of 100%. That is a bad choice, IMO.
>
> The unanswerable question:
>
> Did he do that because he's fundamentally dishonest, and wanted to rig
> the test to look bad for C, or did he do that because he doesn't
> understand the algorithm well enough to do better?
I don't know, I don't say, I don't care.
Any possible answer would be off-topic.
Let everybody decide for themselves how to deal with pedant trolls.
BTW: Spinoza's handling of zeros used as NULL-values inside the hash table
is wrong, too. Could have been be handled by some clever bit-cramming.
AvK
spinoza1111
> "bartc" <ba...@freeuk.com> writes:
> >spinoza1111wrote:
> >> On Dec 28, 5:10 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> >>> I'd be a lot more interested in performance of, say,
> >>> large lists or hash tables.
>
> >> C code to hash several numbers, iterated to get somewhat better
> >> performance numbers.
>
> >> C Sharp code to do the same:
>
> >> The C Sharp code is not only smaller above, it runs dramatically
> >> faster: 24 secs on my machine as contrasted with 35 secs for the C
> >> code.
>
> > C was a bit faster on my machine.
>
> > But, you are now starting to get away from good benchmarking
> > practices, by comparing a implementation of something in one language,
> > with a built-in version in another.
>
> I think it is much worse than that. The C# code can chose the table
> size for good performance (and I can't imagine it would not). In the
> C version, the table was chosen to be as bad as it could be without
> failing (i.e. exactly the same size as the number of numbers being put
> into the set).
That is not the case, and part of the problem is that you think so
normatively. In a toxic and pseudo-scientific corporate environment,
where (in Adorno's words) "all scientists are candidate for posts"
there's no real problem solving, just a continual (and futile) effort
to establish and destroy credibility.
You are correct in saying that the C version becomes very slow as the
number of table entries approaches the size of the table. I've already
noted that this is a problem, and how to solve it by using a linked
list originating at each entry.
However, the two programs demonstrate my point. C more or less forces
the C program to decide on the maximum table size, therefore the test,
which filled up the table, was realistic, since tables often fill up
in production.
Whereas in a completely encapsulated way the C Sharp program either
preallocated more than enough storage or automatically expanded the
table. We don't know what it did because we do not need to know. In
production, the only responsibility of the user of hashset is to but
additions in try..catch error handling.
Giving C this type of flexibility would involve a lot of extra coding,
or visiting some creepy site.
If it becomes necessary to delete from the C hash table, and the basic
"search forward to available entry" method actually implemented is in
use, a special value is needed to mark deleted entries, since entries
that match the hash code need to be retrieved past the deleted entry.
If linked lists are used, they need to be searched to find the entry
to be deleted. Whereas in the C Sharp code, deletion is one line of
additional code!
Therefore, the benchmark numbers are realistic. A simple C hash table,
implemented in the simplest fashion without a link list, will probably
run much slower than a C Sharp hash table user application with much
more coding effort. It will be much harder to maintain.
C sucks, and it's not "efficient" in practise.
spinoza1111
wrote:
> In article <cd32d98a-5f2d-4384-9af7-3be685bc8...@j14g2000yqm.googlegroups.com>,spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> ...
>
> >> C was a bit faster on my machine.
>
> >> But, you are now starting to get away from good benchmarking practices, by
> >> comparing a implementation of something in one language, with a built-in
> >> version in another.
>
> >But that's my point. Not only do you not have to "reinvent the wheel",
> >the built-in wheel is better and safer to use.
>
> Hot, sexy, broken. Full employment. C is good.
>
> Seriously, does anyone not see just how bad the economy could get if
> software actually worked?
I do see that it is getting really bad, precisely because more and
more shops are using much better software written for free by people
who don't even know they're virtual slaves. Employment in the USA is
at 10.2% and much higher for minorities.
Add to this the fact that businesses don't care about software safety,
and the employment picture is grim, indeed.
spinoza1111
>
> ...
>
> >> C was a bit faster on my machine.
>
> >> But, you are now starting to get away from good benchmarking practices, by
> >> comparing a implementation of something in one language, with a built-in
> >> version in another.
>
> >But that's my point. Not only do you not have to "reinvent the wheel",
> >the built-in wheel is better and safer to use.
>
> Hot, sexy, broken. Full employment. C is good.
>
> Seriously, does anyone not see just how bad the economy could get if
> software actually worked?
You (or you and I) should write a book about bad software and
programmer stupidity called "hot, sexy, and broken" with a bimbo in a
bikini on the cover. It'd sell like hotcakes, like "Hot Naked Chicks
and World News Report" in Idiocracy.
Walter Banks
spinoza1111 wrote:
> C sucks, and it's not "efficient" in practise.
Broad based statement backed by a very narrow example.
The conclusion is intellectually dishonest
w..
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
spinoza1111
> "bartc" <ba...@freeuk.com> writes:
> >spinoza1111wrote:
only by a person who thinks in C all the time. I submit that this
stunts the mind even as a programmer, not to mention humanity. The
sort of crap that's posted here indicates this.
I can concede that a Troglodyte who overspecializes in C could write
code that operates in a fraction of the C Sharp time for the same
reason that assembler can in the last analysis run at the fraction of
the time of even C; the distributed software that calculates large
primes on thousands of computers all over the world, using spare
cycles on volunteer computers, seems to be written in assembler.
This shows the ultimate vanity of C; it pretends to be as fast as
assembler but is not.
But in either assembler or C, a level of committment and intensity
consistently destroys the programmer's humanity save in rare cases of
true genius, of a sort which isn't found here, and which itself (like
Grigory Perelman, the Russian mathematician who left the field after
refusing the Fields medal) is smart enough to recognize an expense of
spirit in a waste of shame when it sees it.
> --
> Ben.
spinoza1111
> On Mon, 28 Dec 2009 19:11:03 -0800,spinoza1111wrote:
> > 000
>
> In your C example, you are using linear probing combined
> with a fill factor of 100%. That is a bad choice, IMO.
I explained that already as a problem. I said that the average search
time slows down as the table fills up. I've known this for nearly
forty years, since I read it in Knuth in 1971. I said (did you miss
it) that you need to use linked lists based at each entry to get K*C
time where C is the average number of collisions.
The problem is, as I've said, that the C program is more
psychologically complex and harder to maintain than C Sharp code which
does the same thing better.
>
> Also, beware of rand(). It is guaranteed to deliver only 15 bits of random.
> Implementations _may_ produce a larger range of values.
I am also aware of the limitations of rand(). Indeed, many defenses of
C snigger at its obvious facilities and recommend arcana, some of
which is available from creepy sites. But this is completely absurd,
because one of the major reasons for using a programming language is
clarity.
Of course, the hatred of clarity, combined with a basic
misunderstanding of the very word, is on display in the two documents
that started the Schildt canard: they call him "clear" (which means
he's correct by implication) and then tear into him...for being
insufficientl unclear, and for failing to tell C programmers what Thou
Shalt Not like a proper *ayatollah* or *imam* of Holy C.
>
> HTH,
> AvK
spinoza1111
> "bartc" <ba...@freeuk.com> writes:
> >spinoza1111wrote:
>
> >>> I'd be a lot more interested in performance of, say,
> >>> large lists or hash tables.
>
> >> C code to hash several numbers, iterated to get somewhat better
> >> performance numbers.
>
> >> C Sharp code to do the same:
>
> >> The C Sharp code is not only smaller above, it runs dramatically
> >> faster: 24 secs on my machine as contrasted with 35 secs for the C
> >> code.
>
> > C was a bit faster on my machine.
>
> > But, you are now starting to get away from good benchmarking
> > practices, by comparing a implementation of something in one language,
> > with a built-in version in another.
>
> I think it is much worse than that. The C# code can chose the table
> size for good performance (and I can't imagine it would not). In the
> C version, the table was chosen to be as bad as it could be without
> failing (i.e. exactly the same size as the number of numbers being put
> into the set).
>
> There is no evidence that any attempt at a reasonable comparison is
> being attempted, here.
>
> To perform the same task, the obvious C solution would use a bit
The problem is that like most "obvious C solutions", a bit array
doesn't scale. Sure, it's cheesily and in the small "elegant" to small
minds to allocate a huge bit array and index into this directly, for
the space taken would be 1/32 of an array of longs.
But if the key is changed to a more realistic range of values (such as
an alphanumeric symbol), the bit vector gets too large. You're back
where you started, and this often happens when the user initially says
"the key is a number" and later says "it's a symbol".
Whereas the hashkey scales nicely. It would even be better to roll
your own hashkey class, one that allows the user to give it an idea of
the key range on instance creation. Then, the hashkey class could use
a bit map as appropriate.
spinoza1111
> On 2009-12-29, Moi <r...@invalid.address.org> wrote:
>
> > In your C example, you are using linear probing combined
> > with a fill factor of 100%. That is a bad choice, IMO.
>
> The unanswerable question:
>
> Did he do that because he's fundamentally dishonest, and wanted to rig the
> test to look bad for C, or did he do that because he doesn't understand
> the algorithm well enough to do better?
Peter, when you make the issue into personalities, you enable the
destruction of this newsgroup. That's because people have the right to
defend themselves.
Like most code posted here, the code was written quickly for
discussion by educated professionals, who've studied computer science
in a non-corporate environment or somehow acquired collegial habits
and basic decency.
A more tuned C version (such as Ben's bit map) doesn't scale. It is of
course good to know that inserting hash table entries after the
collision creates slow performance, and it was I who said this first.
But we need to compare programs of roughly equal psychological
complexity.
Where's your code, Scripto Boy?
Shove it up your ass, fella.
>
> -s
> --
spinoza1111
> On 2009-12-29, bartc <ba...@freeuk.com> wrote:
>
> >spinoza1111wrote:
> >> It does: Google the mono project. Microsoft has in fact worked hard to
> >> make .Net open architecture (if closed source).
> > OK I'll have a closer look at Mono for Windows, although I was really
> > talking about the core language, ie. without it's complex environment.
>
> In any event, it's a red herring; Mono exists to make people think C# is
> an open language, when it is in fact nothing of the sort. It's a pure
> deception, so far as I can tell.
C# is an open language. It had to be to be ECMA certified. It is being
changed and improved rapidly but in a controlled fashion, so we won't
have to worry about "standardizing" crap.
>
> -s
> --
spinoza1111
> spinoza1111wrote:
> > C sucks, and it's not "efficient" in practise.
>
> Broad based statement backed by a very narrow example.
Intelligent students can see that the square of the hypotenuse is
equal to the sum of the squares of the opposing sides based on one
diagram. Likewise, I show that for approximately equal levels of
effort, you get a much more efficient, powerful and easier to maintain
piece of code.
>
> The conclusion is intellectually dishonest
>
> w..
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
Tom St Denis
> A more tuned C version (such as Ben's bit map) doesn't scale. It is of
> course good to know that inserting hash table entries after the
> collision creates slow performance, and it was I who said this first.
> But we need to compare programs of roughly equal psychological
> complexity.
One thing you repeatedly fail to grasp is the concept of APIs. You're
not comparing C# to C, you're comparing C# with a tuned hash library
to C with a poorly implemented hash algorithm. You also fail at
computer science in general.
For one thing, you're C# hash array is NOT bounded at 1000 entries.
You're trying to add 1000 entries to a hash array with 1000 spots
which means you're getting a lot of collisions and doing many
sequential searches [for empty spots]. That could easily explain the
time difference. Generally if you have an unbounded input size you'd
use a tree not a hash. Hashes are useful when you know you have at
most X symbols, then you can easily allocate some Y >> X space and
hash collisions should be low.
But don't let this stop you.
Tom
Tom St Denis
> You are correct in saying that the C version becomes very slow as the
> number of table entries approaches the size of the table. I've already
> noted that this is a problem, and how to solve it by using a linked
> list originating at each entry.
The solution is not to use linked lists [at least not that way].
Either use a larger table or a tree. Generally for unbounded inputs a
tree is a better idea as it has better properties on the whole (as the
symbol set size grows...).
> However, the two programs demonstrate my point. C more or less forces
> the C program to decide on the maximum table size, therefore the test,
> which filled up the table, was realistic, since tables often fill up
> in production.
No, you could grow the table at some threshold, reimport existing
symbols into the new hash. A naive approach would just add another X
symbol spots every time you get more than [say] 80% full.
Most of the time when a hash is preferable over a tree [or other
structure] is when the symbol set is of known dimensions. E.g. you're
writing a lexer for a parser for a language.
> Whereas in a completely encapsulated way the C Sharp program either
> preallocated more than enough storage or automatically expanded the
> table. We don't know what it did because we do not need to know. In
> production, the only responsibility of the user of hashset is to but
> additions in try..catch error handling.
And you couldn't have a hash_add(), hash_find() function in C that
does all of this hash table manipulations [like done in C#] in C
because....?
The same algorithm(s) that C# uses could be implemented in a C library
[I'll bet they exist all over the net].
> Giving C this type of flexibility would involve a lot of extra coding,
> or visiting some creepy site.
Or doing a 2 second google search
http://www.gnu.org/s/libc/manual/html_node/Hash-Search-Function.html
Wow. That was hard.
> If it becomes necessary to delete from the C hash table, and the basic
> "search forward to available entry" method actually implemented is in
> use, a special value is needed to mark deleted entries, since entries
> that match the hash code need to be retrieved past the deleted entry.
> If linked lists are used, they need to be searched to find the entry
> to be deleted. Whereas in the C Sharp code, deletion is one line of
> additional code!
hash_delete()
You really need to learn what functions are.
> Therefore, the benchmark numbers are realistic. A simple C hash table,
> implemented in the simplest fashion without a link list, will probably
> run much slower than a C Sharp hash table user application with much
> more coding effort. It will be much harder to maintain.
>
> C sucks, and it's not "efficient" in practise.
So because you suck at software development and computer science in
general, C sucks.
When you're comparing equivalent algorithms maybe you might have a
point. Until then this is just further demonstration that there are
people in the world stupider than I.
Tom
Tom St Denis
> On Dec 29, 11:56 pm, Walter Banks <wal...@bytecraft.com> wrote:
>
> > spinoza1111wrote:
> > > C sucks, and it's not "efficient" in practise.
>
> > Broad based statement backed by a very narrow example.
>
> Intelligent students can see that the square of the hypotenuse is
> equal to the sum of the squares of the opposing sides based on one
> diagram. Likewise, I show that for approximately equal levels of
> effort, you get a much more efficient, powerful and easier to maintain
> piece of code.
Which is of course dishonest since a quick google search turns up all
sorts of hashing code, some of which is PART OF GNU LIBC.
Tom
Tom St Denis
> I explained that already as a problem. I said that the average search
> time slows down as the table fills up. I've known this for nearly
> forty years, since I read it in Knuth in 1971. I said (did you miss
> it) that you need to use linked lists based at each entry to get K*C
> time where C is the average number of collisions.
You've been in software for 40 years (1971 was 38 years ago btw...)
and it didn't occur to you to use a binary tree?
> The problem is, as I've said, that the C program is more
> psychologically complex and harder to maintain than C Sharp code which
> does the same thing better.
man hsearch
man bsearch
man tsearch
Sure those are not part of C99, but they're part of GNU libc, which a
lot of people have access to. There are standalone data management
libraries out there.
You're being obtuse to think that people haven't worked on these
problems and that ALL developers must code their own solutions from
scratch.
> I am also aware of the limitations of rand(). Indeed, many defenses of
> C snigger at its obvious facilities and recommend arcana, some of
> which is available from creepy sites. But this is completely absurd,
> because one of the major reasons for using a programming language is
> clarity.
rand() is useful for simple non-sequential numbers. If you need a
statistically meaningful PRNG use one. I'd hazard a guess C# is no
different in it's use of a LCG anyways. So I wouldn't be so apt to
praise it.
You could easily write an API that had functions like
hash_add(table, key, value);
value = hash_search(table, key);
hash_remove(table, key);
Why would that be so much harder than your class based methods from
C#?
Tom
Seebs
> On Dec 29, 11:21�am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> Which is of course dishonest
I think Hanlon's Razor applies -- never ascribe to malice that which can
be adequately explained by stupidity.
-s
--
Tom St Denis
> On 2009-12-29, Tom St Denis <t...@iahu.ca> wrote:
>
> > On Dec 29, 11:21 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> >>[stuff]
> > Which is of course dishonest
>
> I think Hanlon's Razor applies -- never ascribe to malice that which can
> be adequately explained by stupidity.
In this case I don't think he can't perform a google search [e.g.,
being stupid], rather I think he's trying to troll to a point and is
shying away from doing any actual research in his quest to prove his
point because the truth of the matter is he's full of sh!#. He tried
to compare two completely different algorithms in an attempt to prove
that C# is better than C. Which, even if it were true wouldn't matter
in the slightest.
This is like comparing a 1L diesel Mini to a 5L hemi and saying the
Mini gets better mileage therefore diesel is better than gasoline.
If he actually researched the hash implementation in Mono, then coded
up a reasonable implementation in C, compared the speed [and/or the
complexity of the C code] he might actually have a point.
But as it stands all this thread has proved is he doesn't understand
Computer Science and that he's anti-social.
Tom
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
(seebs)
>> In any event, it's a red herring; Mono exists to make people think C# is
>> an open language, when it is in fact nothing of the sort. �It's a pure
>> deception, so far as I can tell.
>C# is an open language. It had to be to be ECMA certified. It is being
On this one, I think seebs is right. Something about a stopped clock.
As a practical matter, .NET is an MS technology. The slice of the
computing world that is going to go for the ideas and concepts that are
.NET and yet would use an off-brand implementation is vanishingly small.
Give them credit. MS does know how to play the standards game for show,
while at the same time keeping the ball in their home territory.
Keith Thompson
[...]
> man hsearch
> man bsearch
> man tsearch
>
> Sure those are not part of C99, but they're part of GNU libc, which a
> lot of people have access to. There are standalone data management
> libraries out there.
bsearch is standard in both C90 and C99.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jamm
How long did 1.0 last? Less than 2 years? MS has billions to spend on their
strategies of market control and dominance without even worrying about
profit. OS and app sales fund their developer technologies. Do you like
being on the never ending MS learning cycle? I use C# professionally and I
don't like it.
Ohh now we have covariance and contravariance!! Lets all get sexually
aroused and blog about it! C# 4!!!
Remember the Windows 2000 era? Win32 programs just POPPED onto the screen,
lightning fast redraws.
But to this day I can spot a .Net application by its sluggish drawing. Aero
glass now hides this somewhat. Sneaky.
I'm sure you can come up with some C# algo. that performs super fast. We
should not be surprised by this should we? C# doesn't magically run on a
different processor or something. Like C, its all machine language in the
end.
spinoza1111
> On Dec 29, 11:17 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > A more tuned C version (such as Ben's bit map) doesn't scale. It is of
> > course good to know that inserting hash table entries after the
> > collision creates slow performance, and it was I who said this first.
> > But we need to compare programs of roughly equal psychological
> > complexity.
>
> One thing you repeatedly fail to grasp is the concept of APIs. You're
> not comparing C# to C, you're comparing C# with a tuned hash library
> to C with a poorly implemented hash algorithm. You also fail at
> computer science in general.
C# comes WITH a tuned hash library whereas the libraries that "come
with" C in the sense of being visible are a joke: snprintf being an
example.
>
> For one thing, you're C# hash array is NOT bounded at 1000 entries.
> You're trying to add 1000 entries to a hash array with 1000 spots
Many arrays in fact fill up in production. And don't waste my time: I
raised this issue right after I posted the original code, pointing out
that the average probe time would go to shit and describing how to fix
it...the point being that none of this was necessary with C Sharp.
> which means you're getting a lot of collisions and doing many
> sequential searches [for empty spots]. That could easily explain the
> time difference. Generally if you have an unbounded input size you'd
> use a tree not a hash. Hashes are useful when you know you have at
> most X symbols, then you can easily allocate some Y >> X space and
> hash collisions should be low.
Talk about bloatware: on the one hand one guy complains that C Sharp
executables are too large, here a C fan suggests wasting memory to
make a crude algorithm perform. It might be a good idea in certain
circumstances, but it fails to demonstrate that C doesn't suck. The
linked list that I suggested (but haven't implemented thisthread) is
better.
spinoza1111
> On Dec 29, 10:50 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > You are correct in saying that the C version becomes very slow as the
> > number of table entries approaches the size of the table. I've already
> > noted that this is a problem, and how to solve it by using a linked
> > list originating at each entry.
>
> The solution is not to use linked lists [at least not that way].
> Either use a larger table or a tree. Generally for unbounded inputs a
> tree is a better idea as it has better properties on the whole (as the
> symbol set size grows...).
Fair enough. The linked list might have long searches whereas the tree
search can be bounded as long as you can keep it balanced. See (you
probably have) Knuth. I have to buy a new copy if this nonsense
continues, I gave away my old copy to DeVry in a Prospero moment:
Now my Charmes are all ore-throwne,
And what strength I haue's mine owne.
>
> > However, the two programs demonstrate my point. C more or less forces
> > the C program to decide on the maximum table size, therefore the test,
> > which filled up the table, was realistic, since tables often fill up
> > in production.
>
> No, you could grow the table at some threshold, reimport existing
> symbols into the new hash. A naive approach would just add another X
> symbol spots every time you get more than [say] 80% full.
Been there, did that...in PL.1 at Illinois Bell. It's a good practice.
>
> Most of the time when a hash is preferable over a tree [or other
> structure] is when the symbol set is of known dimensions. E.g. you're
> writing a lexer for a parser for a language.
This is discussed in my book (buy my book or die Earthlings...ooops
commercial promo), "Build Your Own .Net Language and Compiler", Apress
2004.
>
> > Whereas in a completely encapsulated way the C Sharp program either
> > preallocated more than enough storage or automatically expanded the
> > table. We don't know what it did because we do not need to know. In
> > production, the only responsibility of the user of hashset is to but
> > additions in try..catch error handling.
>
> And you couldn't have a hash_add(), hash_find() function in C that
> does all of this hash table manipulations [like done in C#] in C
> because....?
...because IT'S BEEN DONE, and is more easily accessible in C Sharp
and Java. C'mon, guy. I need to program more examples in Wolfram and
use my computer to search for intelligent life on other planets (sure
ain't found much here ha ha).
>
> The same algorithm(s) that C# uses could be implemented in a C library
> [I'll bet they exist all over the net].
Dammit, I addressed this. Yes, it's possible that the C Sharp
libraries are in C. It's also possible that they were written in MSIL
directly, or C Sharp itself. And before there was C Sharp, C was used
to produce better things than C, just like the old gods built the
world only to be overthrown by cooler gods.
>
> > Giving C this type of flexibility would involve a lot of extra coding,
> > or visiting some creepy site.
>
> Or doing a 2 second google search
>
> http://www.gnu.org/s/libc/manual/html_node/Hash-Search-Function.html
>
> Wow. That was hard.
You're neglecting the forensic problem. Not only "should" I not use
this code in commercial products, I have gnow way of gnowing that gnu
will ingneroperate.
>
> > If it becomes necessary to delete from the C hash table, and the basic
> > "search forward to available entry" method actually implemented is in
> > use, a special value is needed to mark deleted entries, since entries
> > that match the hash code need to be retrieved past the deleted entry.
> > If linked lists are used, they need to be searched to find the entry
> > to be deleted. Whereas in the C Sharp code, deletion is one line of
> > additional code!
>
> hash_delete()
>
> You really need to learn what functions are.
I think I do. Do u? And I have said before that this constant, lower
middle class, questioning of credentials by people who have every
reason to worry about their own is boring and disgusting.
>
> > Therefore, the benchmark numbers are realistic. A simple C hash table,
> > implemented in the simplest fashion without a link list, will probably
> > run much slower than a C Sharp hash table user application with much
> > more coding effort. It will be much harder to maintain.
>
> > C sucks, and it's not "efficient" in practise.
>
> So because you suck at software development and computer science in
> general, C sucks.
No, C sucks because I started programming before it existed and saw
University of Chicago programmers do a better job, only to see C
become widely use merely because of the prestige of a campus with no
particular distinction in comp sci at the time but an upper class
reputation. I was hired by Princeton in the 1980s in part because it
was behind the curve technically.
You see, public relations machinery worked on behalf of Princeton on
the right coast and later Apple on the left coast to re-present men
who were at best tokens of a type as real inventors. Because
industrial relations had imposed the same overall contours on
technology world-wide, men were simultaneously discovering the same
things all over the world but world-wide, American military power
(established by slaughtering the people of Hiroshima and Nagasaki)
made it seem as if prestige Americans invented the computer whereas it
was being simultaneously invented in places as diverse as Nazi
Germany, Pennsylvania, and Iowa.
The result is a perpetual childishness and anxiety in which certain
inventors are celebrated as gods by public relations machinery and the
"rest of us" are encouraged to fight for scraps of status.
>
> When you're comparing equivalent algorithms maybe you might have a
> point. Until then this is just further demonstration that there are
> people in the world stupider than I.
Well, if that were true, that would make you happy. But if your goal
is to discover a vanishingly small value for a number, I suggest you
scram.
>
> Tom
spinoza1111
Because I didn't have to write them. I just used hashkey.
And even if I use the gnu products (which should not be ethically used
in commercial products) the forensic problems of C remain. Because it
provides zero protection against memory leaks, aliasing, and the
simultaneous usage of certain non-reentrant library functions, I would
have to test the code doing the hashing thoroughly IN ADDITION to the
code written to solve the actual problem. Whereas forensically I am
within my rights to assume hashkey works.
>
> Tom
Oliver Jackson
> On Dec 30, 12:43 am, Tom St Denis <t...@iahu.ca> wrote:
>
> > On Dec 29, 10:50 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > You are correct in saying that the C version becomes very slow as the
> > > number of table entries approaches the size of the table. I've already
> > > noted that this is a problem, and how to solve it by using a linked
> > > list originating at each entry.
>
> > The solution is not to use linked lists [at least not that way].
> > Either use a larger table or a tree. Generally for unbounded inputs a
> > tree is a better idea as it has better properties on the whole (as the
> > symbol set size grows...).
>
> Fair enough. The linked list might have long searches whereas the tree
> search can be bounded as long as you can keep it balanced. See (you
> probably have) Knuth. I have to buy a new copy if this nonsense
> continues, I gave away my old copy to DeVry in a Prospero moment:
>
> Now my Charmes are all ore-throwne,
> And what strength I haue's mine owne.
Michael Foukarakis
> A C and a C Sharp program was written to calculate the 64-bit value of
> 19 factorial one million times, using both the iterative and recursive
> methods to solve (and compare) the results
>
> Here is the C code.
>
> #include <stdio.h>
> #include <time.h>
>
> long long factorial(long long N)
> {
> long long nFactorialRecursive;
> long long nFactorialIterative;
> long long Nwork;
> if (N <= 2) return N;
> for ( nFactorialIterative = 1, Nwork = N;
> Nwork > 1;
> Nwork-- )
> nFactorialIterative *= Nwork;
> nFactorialRecursive = N * factorial(N-1);
> if (nFactorialRecursive != nFactorialIterative)
> printf("%I64d! is %I64d recursively but %I64d iteratively wtf!
> \n",
> N,
> nFactorialIterative,
> nFactorialRecursive);
> return nFactorialRecursive;
>
> }
>
> int main(void)
> {
> long long N;
> long long Nfactorial;
> double dif;
> long long i;
> long long K;
> time_t start;
> time_t end;
> N = 19;
> K = 1000000;
> time (&start);
> for (i = 0; i < K; i++)
> Nfactorial = factorial(N);
> time (&end);
> dif = difftime (end,start);
> printf("%I64d! is %I64d: %.2f seconds to calculate %I64d times
> \n",
> N, Nfactorial, dif, K);
> return 0; // Gee is that right?
>
> }
>
> Here is the C Sharp code.
>
> using System;
> using System.Collections.Generic;
> using System.Linq;
> using System.Text;
>
> namespace N_factorial
> {
> class Program
> {
> static void Main(string[] args)
> {
> long N;
> long Nfactorial = 0;
> TimeSpan dif;
> long i;
> long K;
> DateTime start;
> DateTime end;
> N = 19;
> K = 1000000;
> start = DateTime.Now;
> for (i = 0; i < K; i++)
> Nfactorial = factorial(N);
> end = DateTime.Now;
> dif = end - start;
> Console.WriteLine
> ("The factorial of " +
> N.ToString() + " is " +
> Nfactorial.ToString() + ": " +
> dif.ToString() + " " +
> "seconds to calculate " +
> K.ToString() + " times");
> return;
> }
>
> static long factorial(long N)
> {
> long nFactorialRecursive;
> long nFactorialIterative;
> long Nwork;
> if (N <= 2) return N;
> for ( nFactorialIterative = 1, Nwork = N;
> Nwork > 1;
> Nwork-- )
> nFactorialIterative *= Nwork;
> nFactorialRecursive = N * factorial(N-1);
> if (nFactorialRecursive != nFactorialIterative)
> Console.WriteLine
> ("The iterative factorial of " +
> N.ToString() + " " +
> "is " +
> nFactorialIterative.ToString() + " " +
> "but its recursive factorial is " +
> nFactorialRecursive.ToString());
> return nFactorialRecursive;
> }
> }
>
> }
>
> The C Sharp code runs at 110% of the speed of the C code, which may
> seem to "prove" the half-literate Urban Legend that "C is more
> efficient than C Sharp or VM/bytecode languages in general, d'oh".
You don't know how to benchmark programs. D'oh (sic).
> But far more significantly: the ten percent "overhead" would be
> several orders of magnitude were C Sharp to be an "inefficient,
> interpreted language" which many C programmers claim it is.
Show them "many C programmers".
> I'm for one tired of the Urban Legends of the lower middle class,
> whether in programming or politics.
I long for the day when you'll grow tired of (your own) incompetence
as well.
Boris S.
> On Dec 28, 5:10 am, Seebs <usenet-nos...@seebs.net> wrote:
>
>
>
>
>
> > On 2009-12-27, bartc <ba...@freeuk.com> wrote:
>
> > > It doesn't matter too much that the code was idiotic, provided both
> > > languages were executing the same idiotic algorithm.
>
> > True.
>
> > > The original code wasn't a bad test of long long multiplication in each
> > > language.
>
> > Fair enough. It's not exactly what I'd call an interesting test case for
> > real-world code. I'd be a lot more interested in performance of, say,
> > large lists or hash tables.
>
> > --
> > Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
>
> performance numbers.
>
> #include <time.h>
> #include <stdlib.h>
> #define ARRAY_SIZE 1000
> #define SESSIONS 100000
>
> int main(void)
> {
> int hash[ARRAY_SIZE];
> int i;
> int r;
> int j;
> int k;
> int collisions;
> time_t start;
> time_t end;
> double dif;
> int tests;
> int sessions;
> time (&start);
> for (sessions = 0; sessions < SESSIONS; sessions++)
> {
> for (i = 0; i < ARRAY_SIZE; i++) hash[i] = 0;
> collisions = 0;
> tests = ARRAY_SIZE;
> for (i = 0; i < tests; i++)
> {
> r = rand();
> j = r % ARRAY_SIZE;
> k = j;
> if (hash[j] != 0) collisions++;
> while(hash[j] != r && hash[j] != 0)
> {
> if (j >= ARRAY_SIZE) j = 0; else j++;
> if (j==k)
> {
> printf("Table is full\n");
> break;
> }
> }
> if (hash[j] == 0) hash[j] = r;
> }
> }
> time (&end);
> dif = difftime (end,start);
> collisions, %d times\n",
> dif, tests, collisions, sessions);
> return 0; // Gee is that right?
>
> }
>
>
> using System.Collections.Generic;
> using System.Linq;
> using System.Text;
>
> {
> class Program
> {
> static void Main(string[] args)
> {
> hash = new HashSet<int>();
> Random R = new Random(1);
> int i;
> int j;
> TimeSpan dif;
> DateTime start;
> DateTime end;
> start = DateTime.Now;
> int sessions = 100000;
> int tests = 1000;
> for (i = 0; i < sessions; i++)
> {
> hash.Clear();
> for (j = 0; j < tests; j++)
> hash.Add(R.Next(32767));
> }
> end = DateTime.Now;
> dif = end - start;
> Console.WriteLine
> dif.ToString() + " " +
> "seconds to hash " +
> tests.ToString() + " numbers " +
> sessions.ToString() + " times");
> return; // Ha ha I don't have to worry about the
> shibboleth
> }
> }
>
> }
>
> The C Sharp code is not only smaller above, it runs dramatically
> faster: 24 secs on my machine as contrasted with 35 secs for the C
> code.
>
> fast as you like in that it's a part of the extended "os". It may
> itself be written in C, and please note that this does NOT mean that
> YOU should write in C after all, because the HashSet was written state
> of the art by studly guys and gals at Microsoft, and painstakingly
> reviewed by other studly guys and gals.
>
> And no, I don't want to visit some creepy site to get best C practise
> for hashing. The fact is that the research it takes at creepy come-to-
> Jesus and ammo sites to find "good" C, quite apart from its being a
> waste of spirit in an expense of shame, provides no "forensic"
> assurance that the creepy guy who gave you the code didn't screw up or
> insert a time bomb. HashSet is available, shrink-wrapped and out of
> the box, and IT RUNS TWICE AS FAST.
>
> HashSet can even safely run as managed code but be developed as Java
> bytecode or .Net MSIL as a form of safe assembler language. When it is
> maintained by the vendor, you get the benefit. Whereas el Creepo's
> code is all you get, period, unless you call him a year later, only to
> find that his ex-wife has thrown him out the house.
>
> C is NOT more "efficient" than C Sharp. That is not even a coherent
> thing to say.
>
> Furthermore, even the best of us screw up (as I have screwn up) when
> implementing the basics. Donald R Knuth has said that he always gets
> binary search wrong the first time he recodes it. It is a mark of the
> smart person to have trouble with low-level math and code; Einstein
> (cf Walter Kaufman's bio) had in fact a great deal of difficulty
> working out the details of relativistic mathematics and required help
> from other mathematicians and physicists.
>
> Therefore we class acts prefer C Sharp.
With a little modification here is the my result;
root@varyag-laptop:~# time ./x
It took C 6.00 seconds to hash 1000 numbers with 82 collisions, 100000
times
real 0m5.468s
user 0m5.456s
sys 0m0.000s
root@varyag-laptop:~# time mono xc.exe
It took C Sharp 00:00:10.1764660 seconds to hash 1000 numbers 100000
times
real 0m10.260s
user 0m10.241s
sys 0m0.004s
This is, where this trash talking ends.. ;)
spinoza1111
The trash talking in my case is in all instances a response to the
annoying lower middle class habit of always transforming technical
issues into issues of personal standing, a habit that is based on
rather well-deserved feelings of inadequacy.
You forgot to disclose the modification you made, and the performance
improvement of C simply doesn't warrant using it, because C as such
presents the forensic problem that any C program can do nasty things
that a managed C Sharp program cannot.
Besides, we know that the C program performs poorly because the table
fills up, resulting in longer and longer searches for holes. I was the
first, in fact, to point this out, because I'm not here to destroy
others by concealing information unfavorable to my case.
Here are the comparative numbers when the C program, only, is
restricted to using 75% of the table (which trades bloat for speed).
It took C 13.00 seconds to hash 750 numbers in a table with available
size 1000 with 101913509 collisions, 100000 times
Total probes: 176913509: Average number of collisions: 0.576064
It took C Sharp 00:00:24.4531250 seconds to hash 1000 numbers 100000
times
Yes, folks, C sharp took twice as long.
Shame on it. Bad, Commie, Terrorist, Evil C Sharp, from the Dark Side
of the Force.
However, only an order of magnitude would be significant, because an
order of magnitude would indicate that the C Sharp code was
interpreted, which it is not despite urban legends. With the slower
speed (and the "larger" executable and putative "code bloat", the C
Sharp executable being 5120 bytes and the C executable being...hey
wait a minute...7680 bytes (because MSIL is not prolix) one gets
freedom from The Complete Nonsense of C which stunts the mind and rots
the spirit down to the level of the Troglodyte.
Moi
> On Dec 30, 12:53 am, Tom St Denis <t...@iahu.ca> wrote:
>
> And even if I use the gnu products (which should not be ethically used
> in commercial products) the forensic problems of C remain. Because it
They are probably licenced under the LGPL.
> provides zero protection against memory leaks, aliasing, and the
> simultaneous usage of certain non-reentrant library functions, I would
> have to test the code doing the hashing thoroughly IN ADDITION to the
> code written to solve the actual problem. Whereas forensically I am
> within my rights to assume hashkey works.
You are wrong. C offers 100% protection against all evil scenarios.
Remember: it is your code, if it is wrong you can fix it. Its behavior is
dictated in the standard.
OTOH the dotnet runtime offers no such guarantee. It does what it does.
It may or may not leak, it may or may not be reentrant, it may suddenly start
the garbage collector, without you knowing it. It may even call home to invoke
real programmers. And its internals may change at any time, without you
knowing it.
Most clc regulars will code a trivial hashtable like this in about half an hour
(and probably another to get it right); and most of us have some existing code
base (or knowlefge) to lend from.
Your time savings were in the second part: getting it right. Instead you relied
on Bill G. and Steve B. to get it right for you.
AvK
Tom St Denis
> Fair enough. The linked list might have long searches whereas the tree
No fair enough, you don't get to post an inefficient algorithm compare
it to optimized C# and make conclusions, then when told basically say
"fair enough." Admit you were wrong.
> ...because IT'S BEEN DONE, and is more easily accessible in C Sharp
> and Java. C'mon, guy. I need to program more examples in Wolfram and
> use my computer to search for intelligent life on other planets (sure
> ain't found much here ha ha).
It's been done in C too though. Did you miss the part where I pointed
out that there are libraries for C out there that do trees, heaps,
queues, etc?
You seem to assume that all C developers start with no external APIs
and write everything from scratch themselves. That's both naive and
ignorant.
> Dammit, I addressed this. Yes, it's possible that the C Sharp
> libraries are in C. It's also possible that they were written in MSIL
> directly, or C Sharp itself. And before there was C Sharp, C was used
> to produce better things than C, just like the old gods built the
> world only to be overthrown by cooler gods.
Ok, but what I'm trying to say is your argument that C sucks because
it doesn't /come with/ a hash library is dishonest. Finding a hash
library for C is not hard, and they're not hard to use. You were
being dishonest when you claimed that only C# provides such
functionality.
> You're neglecting the forensic problem. Not only "should" I not use
> this code in commercial products, I have gnow way of gnowing that gnu
> will ingneroperate.
Ok, but there are other libraries out there. Point is I found that
with a 2 second google search. So for you to claim that there are no
suitably licensed data management libraries out there is lazy and
dishonest.
> I think I do. Do u? And I have said before that this constant, lower
> middle class, questioning of credentials by people who have every
> reason to worry about their own is boring and disgusting.
You keep claiming that people have to embed 100s of messy C lines in
all of their code to get anything done in C. First it was messy
string functions, now it's hashes, what next malloc and free? My
point was you're missing the part where you put those algorithms in
functions that users can then call without embedding 100s of lines of
messy C all over their programs.
> No, C sucks because I started programming before it existed and saw
> University of Chicago programmers do a better job, only to see C
> become widely use merely because of the prestige of a campus with no
> particular distinction in comp sci at the time but an upper class
> reputation. I was hired by Princeton in the 1980s in part because it
> was behind the curve technically.
You keep claiming that you're this "old timer" programmer from back in
the day, like that matters. Even if it were true, that doesn't
preclude the possibility that even with all that time to get
experience you STILL have no idea what you're talking about.
If you want to impress me with your credentials you'd stop spouting
obvious lies, better yet, you'd stop trolling usenet. Better yet,
you'd post with your real name...
Tom
Tom St Denis
All functions in libc which aren't thread safe are marked as so.
turns out the *_r() variants ARE thread safe. And as "Moi" pointed
out, GNU LIBC is licensed under LGPL which doesn't attach a license to
your linked image.
And where you get this idea that C# or Java even don't have memory
management issues... Have you never seen a tomcat server taking 5GB of
ram to handle a few 100 connections? Just because there IS a GC in
Java doesn't mean it's used effectively. Point is, if you really did
have "40 years of experience" (impressive since you stated this began
38 years ago, how did you make up the two years?) you'd be comfortable
with pointers, heaps, array indecies, etc... If not from C, from any
of the dozens of languages that came out around/before it.
With all your experience though you don't seem to get testing and
verification. In an ideal model you assume libc is working and reduce
things to that. Then you prove your libraries are working, and reduce
things to them, and so on. Under your line of thinking you'd have to
go to the customers site and prove that electrons are moving on mains,
that the computer fans spin clock wise, etc and so on. NO
ASSUMPTIONS!
Tom
Tom St Denis
> C# comes WITH a tuned hash library whereas the libraries that "come
> with" C in the sense of being visible are a joke: snprintf being an
> example.
I don't get what your point is. There is a ton of 3rd party Java/C#/
PHP/etc code out there. If developers only stayed with what the core
C# provided it'd be no better [in that regard].
> Many arrays in fact fill up in production. And don't waste my time: I
> raised this issue right after I posted the original code, pointing out
> that the average probe time would go to shit and describing how to fix
> it...the point being that none of this was necessary with C Sharp.
No, all this proves is after analyzing a problem that YOU invented,
YOU came up with an inappropriately inferior solution. It proves that
you don't really know what you're talking about, or at least are not
honest enough to make a point properly.
> Talk about bloatware: on the one hand one guy complains that C Sharp
> executables are too large, here a C fan suggests wasting memory to
> make a crude algorithm perform. It might be a good idea in certain
> circumstances, but it fails to demonstrate that C doesn't suck. The
> linked list that I suggested (but haven't implemented thisthread) is
> better.
That's how you improve hashing though. More memory. If you have
unbounded inputs use a tree and learn how to splay. OH MY GOD,
COMPUTER SCIENCE!!!
Tom
Tom St Denis
> The trash talking in my case is in all instances a response to the
> annoying lower middle class habit of always transforming technical
> issues into issues of personal standing, a habit that is based on
> rather well-deserved feelings of inadequacy.
It'd help if you stopped trying to explain away your ignorance in
terms of other peoples failures.
> You forgot to disclose the modification you made, and the performance
> improvement of C simply doesn't warrant using it, because C as such
> presents the forensic problem that any C program can do nasty things
> that a managed C Sharp program cannot.
Dude, learn how to design testable and verifyable software.
> Besides, we know that the C program performs poorly because the table
> fills up, resulting in longer and longer searches for holes. I was the
> first, in fact, to point this out, because I'm not here to destroy
> others by concealing information unfavorable to my case.
No, *YOUR* program performed poorly because you designed an
inappropriate solution. If you wrote the same algorithm in C# it'd be
just as inefficient.
> However, only an order of magnitude would be significant, because an
> order of magnitude would indicate that the C Sharp code was
> interpreted, which it is not despite urban legends. With the slower
> speed (and the "larger" executable and putative "code bloat", the C
> Sharp executable being 5120 bytes and the C executable being...hey
> wait a minute...7680 bytes (because MSIL is not prolix) one gets
> freedom from The Complete Nonsense of C which stunts the mind and rots
> the spirit down to the level of the Troglodyte.
Nobody here is saying that C# is not executed as bytecode. And if
they are they're wrong. I also wouldn't compare executable sizes
unless you also consider the C# DLL baggage [on top of the C runtime
ironically..]
Here's a helpful hint: If you're trying to make a point, consider it
from all angles first. If three seconds of thinking can shoot down
every point you're trying to make you're in the wrong business. Maybe
trolling is not for you, have you considered travel instead?
Tom
spinoza1111
> On Dec 30, 5:42 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > The trash talking in my case is in all instances a response to the
> > annoying lower middle class habit of always transforming technical
> > issues into issues of personal standing, a habit that is based on
> > rather well-deserved feelings of inadequacy.
>
> It'd help if you stopped trying to explain away your ignorance in
> terms of other peoples failures.
The process has consistently started with "regs" here questioning my
bonafides, since I write markedly better (more consistently excellent
grammar and spelling, wider vocabulary, more knowledge) than the regs.
Their defensive response has been to start attacks, and newbies and
fools read the attacks only. This causes them to join what constitutes
a cybernetic mob.
In fact, people here are mostly failures whose programme is to show
that other people are liars and failures. For example, recently,
Richard Heathfield, the editor of an unsuccessful book on C from a
publisher with a bad reputation, claimed I'd never posted to the well-
regarded and tightly moderated group comp.risks. The charge was a
malicious lie and libel under UK law and refutable with laughable
ease, and it proved that Heathfield is both stupid and malicious.
Whether you like it or not, and whether or not you've been
oversocialized to not defend yourself, I defend myself, and this
creates the illusion that I'm making trouble.
Do your homework.
>
> > You forgot to disclose the modification you made, and the performance
> > improvement of C simply doesn't warrant using it, because C as such
> > presents the forensic problem that any C program can do nasty things
> > that a managed C Sharp program cannot.
>
> Dude, learn how to design testable and verifyable software.
Dude, learn how to spell. The first step is to select a quality tool.
C is not a quality tool since it exists in incompatible forms and was
never properly designed.
>
> > Besides, we know that the C program performs poorly because the table
> > fills up, resulting in longer and longer searches for holes. I was the
> > first, in fact, to point this out, because I'm not here to destroy
> > others by concealing information unfavorable to my case.
>
> No, *YOUR* program performed poorly because you designed an
> inappropriate solution. If you wrote the same algorithm in C# it'd be
> just as inefficient.
The Lower Middle Class Parent inhabits too many posters here, and he
transforms all speech into the minatory register, and nothing gets
learnt.
But that's a good idea. I shall indeed do so ASAP. We need to see how
C sharp performs for the ignorant programmer who doesn't know hashset.
My prediction is poorly, for as I was the first to say in this thread,
the algorithm used in the C program slows down as the table fills.
>
> > However, only an order of magnitude would be significant, because an
> > order of magnitude would indicate that the C Sharp code was
> > interpreted, which it is not despite urban legends. With the slower
> > speed (and the "larger" executable and putative "code bloat", the C
> > Sharp executable being 5120 bytes and the C executable being...hey
> > wait a minute...7680 bytes (because MSIL is not prolix) one gets
> > freedom from The Complete Nonsense of C which stunts the mind and rots
> > the spirit down to the level of the Troglodyte.
>
> Nobody here is saying that C# is not executed as bytecode. And if
> they are they're wrong. I also wouldn't compare executable sizes
> unless you also consider the C# DLL baggage [on top of the C runtime
> ironically..]
We don't know whether the .Net runtime is in C, since the particular
implementation I use is closed source. But there is no necessary
connection between C and the .Net runtime, or Windows and .Net.
The .Net runtime can be written in anything you like, such as
unmanaged C Sharp.
>
> Here's a helpful hint: If you're trying to make a point, consider it
> from all angles first. If three seconds of thinking can shoot down
> every point you're trying to make you're in the wrong business. Maybe
> trolling is not for you, have you considered travel instead?
The next step, from the minatory register, for the Lower Middle Class
Parent, is the abstract recommendation that one shape up. I have in
this thread considered things from different points of view, for I was
the first to note that the C algorithm slows down as the table fills
up (and to find a solution).
Here's a helpful hint: shove your lectures up your ass, and confine
yourself to on-topic technical remarks. Use Ben Bacarisse's posts as
an example. He's no friend of mine, but he focuses on technical points
almost exclusively and is very intelligent as a techie.
>
> Tom
spinoza1111
> On Tue, 29 Dec 2009 18:51:06 -0800,spinoza1111wrote:
> > On Dec 30, 12:53 am, Tom St Denis <t...@iahu.ca> wrote:
>
> > And even if I use the gnu products (which should not be ethically used
> > in commercial products) the forensic problems of C remain. Because it
>
> They are probably licenced under the LGPL.
>
> > provides zero protection against memory leaks, aliasing, and the
> > simultaneous usage of certain non-reentrant library functions, I would
> > have to test the code doing the hashing thoroughly IN ADDITION to the
> > code written to solve the actual problem. Whereas forensically I am
> > within my rights to assume hashkey works.
>
> You are wrong. C offers 100% protection against all evil scenarios.
Poppycock.
> Remember: it is your code, if it is wrong you can fix it. Its behavior is
No, it belongs to the organization paying your salary.
"Those Bolshevists are trying to take our factories?"
"Your factories? You don't even own the smoke!"
- International Workers of the World cartoon ca. 1915
The fact is that in many environments, the suits don't give
programmers enough time to do quality assurance. This means that using
such an unconstrained language as C is professional malpractice.
The suits encourage a form of self-defeating programmer machismo such
that no programmer ever admits to not having enough time. Instead,
based on the macho culture, he'll destroy his health working extra,
unpaid hours to "prove" he's a "man", and the suits laugh all the way
to the bank...since he's lowered his salary.
> dictated in the standard.
>
> OTOH the dotnet runtime offers no such guarantee. It does what it does.
> It may or may not leak, it may or may not be reentrant, it may suddenly start
> the garbage collector, without you knowing it. It may even call home to invoke
> real programmers. And its internals may change at any time, without you
> knowing it.
This is all true, but highly unlikely.
>
> Most clc regulars will code a trivial hashtable like this in about half an hour
> (and probably another to get it right); and most of us have some existing code
> base (or knowlefge) to lend from.
In fact, the regs you so admire almost never post new code, for
they're afraid of making errors. Keith Thompson, Seebs and Heathfield
specialize in enabling campaigns of personal destruction against
people who actually accomplish anything, and this started with Seebs'
adolescent mockery of Schildt.
Whereas I've posted C code despite the fact that I think C sucks, and
last used it at the time I was asked at Princeton to assist a Nobel
prize winner with C.
[Damn straight I'll repeat myself about Nash. I find the same lies
about Schildt and myself year in and year out, and this will continue
until it ends and/or Heathfield loses his house in a libel suit.]
>
> Your time savings were in the second part: getting it right. Instead you relied
> on Bill G. and Steve B. to get it right for you.
You're lying. I was the first in this thread to show how the C code
slows down as the table fills up, since I first read of the algorithm
in 1972 and implemented it first in 1976 in PL.1. I wrote the code at
the start of the week before boarding the ferry to work. On the ferry
I realized that I would have to explain a fact about performance that
isn't obvious, so I plugged in my Vodaphone thingie and got back on
air. Nobody else had commented on the issue at the time. You're lying,
punk.
>
> AvK
spinoza1111
> On Dec 29, 9:45 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Fair enough. The linked list might have long searches whereas the tree
>
> No fair enough, you don't get to post an inefficient algorithm compare
> it to optimized C# and make conclusions, then when told basically say
> "fair enough." Admit you were wrong.
>
> > ...because IT'S BEEN DONE, and is more easily accessible in C Sharp
> > and Java. C'mon, guy. I need to program more examples in Wolfram and
> > use my computer to search for intelligent life on other planets (sure
> > ain't found much here ha ha).
>
> It's been done in C too though. Did you miss the part where I pointed
> out that there are libraries for C out there that do trees, heaps,
> queues, etc?
>
I addressed this point before you mentioned it. I said that I don't
want to use virtual slave labor (which is what open source is) at GNU
nor do I want to go to some creepy site.
> You seem to assume that all C developers start with no external APIs
> and write everything from scratch themselves. That's both naive and
> ignorant.
False. I posted the example to show how a real problem is typically
solved. In C, the default is to hack new code. In C Sharp the default
is to use a tool. The fact is most C programmers are deficient at
reuse.
>
> > Dammit, I addressed this. Yes, it's possible that the C Sharp
> > libraries are in C. It's also possible that they were written in MSIL
> > directly, or C Sharp itself. And before there was C Sharp, C was used
> > to produce better things than C, just like the old gods built the
> > world only to be overthrown by cooler gods.
>
> Ok, but what I'm trying to say is your argument that C sucks because
> it doesn't /come with/ a hash library is dishonest. Finding a hash
> library for C is not hard, and they're not hard to use. You were
> being dishonest when you claimed that only C# provides such
> functionality.
The problem isn't that C doesn't come with a hash library. The problem
is that it comes with too many.
There's no way (except perhaps consulting some Fat Bastard at your
little shop, or one of the regs here, such as the pathological liar
Heathfield) of telling which library actually works, and this is a
serious matter, because statistically, C programs are less likely to
work than C Sharp independent of programmer skill: this is a
mathematical result of the ability to alias and the fact that other
people change "your" code.
>
> > You're neglecting the forensic problem. Not only "should" I not use
> > this code in commercial products, I have gnow way of gnowing that gnu
> > will ingneroperate.
>
> Ok, but there are other libraries out there. Point is I found that
> with a 2 second google search. So for you to claim that there are no
> suitably licensed data management libraries out there is lazy and
> dishonest.
You're searching toxic waste.
>
> > I think I do. Do u? And I have said before that this constant, lower
> > middle class, questioning of credentials by people who have every
> > reason to worry about their own is boring and disgusting.
>
> You keep claiming that people have to embed 100s of messy C lines in
> all of their code to get anything done in C. First it was messy
> string functions, now it's hashes, what next malloc and free? My
> point was you're missing the part where you put those algorithms in
> functions that users can then call without embedding 100s of lines of
> messy C all over their programs.
...only to find for example that simultaneous calls fail because
global data cannot be hidden properly in C. There's no static nesting
whatsoever, have you noticed? Even PL.1 had this!
The result? If the library function has a state it cannot be called by
a handler handling its failure. This is well known for malloc() but
unknown and unpredictable for any arbitrary "solution" recommended by
some Fat Bastard, recommended by some pathological liar, or found in a
Google search.
>
> > No, C sucks because I started programming before it existed and saw
> > University of Chicago programmers do a better job, only to see C
> > become widely use merely because of the prestige of a campus with no
> > particular distinction in comp sci at the time but an upper class
> > reputation. I was hired by Princeton in the 1980s in part because it
> > was behind the curve technically.
>
> You keep claiming that you're this "old timer" programmer from back in
> the day, like that matters. Even if it were true, that doesn't
> preclude the possibility that even with all that time to get
> experience you STILL have no idea what you're talking about.
It is true that corporate life is an eternal childhood. However, I
also worked independent of the corporation, for example as the author
of Build Your Own .Net Compiler (buy it now or I will kill this dog)
and the programmer of its (26000 line) exemplary compiler.
>
> If you want to impress me with your credentials you'd stop spouting
> obvious lies, better yet, you'd stop trolling usenet. Better yet,
> you'd post with your real name...
It is well known that I nyah ha ha am Bnarg, the Ruler of the Galaxy,
posting from my Lair on the Planet Gazumbo.
Seriously, it is well known to the regs here that I am Edward G.
Nilges.
>
> Tom
Tom St Denis
> The process has consistently started with "regs" here questioning my
> bonafides, since I write markedly better (more consistently excellent
> grammar and spelling, wider vocabulary, more knowledge) than the regs.
> Their defensive response has been to start attacks, and newbies and
> fools read the attacks only. This causes them to join what constitutes
> a cybernetic mob.
I don't care about the "regs," in this thread I only care about what
YOU are trying to pass off as knowledge.
> Whether you like it or not, and whether or not you've been
> oversocialized to not defend yourself, I defend myself, and this
> creates the illusion that I'm making trouble.
Defend yourself by being right then. If you're trying to make
arguments actually make sure they're sound and well reasoned instead
of just shotgunning stupidity and seeing what sticks.
> Dude, learn how to spell. The first step is to select a quality tool.
> C is not a quality tool since it exists in incompatible forms and was
> never properly designed.
Which is ironic given how much of your day to day life is probably the
result of C programs...
So far it seems to be you saying C sucks, and nobody caring. I don't
care if you program in C or not. I'm only replying here because you
posted some nonsense comparison and are trying to pass it off as
science. You're a fraud.
> But that's a good idea. I shall indeed do so ASAP. We need to see how
> C sharp performs for the ignorant programmer who doesn't know hashset.
> My prediction is poorly, for as I was the first to say in this thread,
> the algorithm used in the C program slows down as the table fills.
So why bother the comparison? If you knew your algorithm in your C
program was not comparable why bother?
That'd be like comparing bubble sort in C# to qsort in C ...
> We don't know whether the .Net runtime is in C, since the particular
> implementation I use is closed source. But there is no necessary
> connection between C and the .Net runtime, or Windows and .Net.
> The .Net runtime can be written in anything you like, such as
> unmanaged C Sharp.
Well the Windows kernel has a C interface for the syscalls. So at
some point something has to call that. So chances are good that the
C# runtime is based on top of the C runtime.
Tom
Tom St Denis
> I addressed this point before you mentioned it. I said that I don't
> want to use virtual slave labor (which is what open source is) at GNU
> nor do I want to go to some creepy site.
OSS is hardly slave labour. Many people in that scene get paid for
their work. It's just a community effort. Of course if this is how
you play ostrich then so be it.
> False. I posted the example to show how a real problem is typically
> solved. In C, the default is to hack new code. In C Sharp the default
> is to use a tool. The fact is most C programmers are deficient at
> reuse.
Citation needed.
> The problem isn't that C doesn't come with a hash library. The problem
> is that it comes with too many.
So first it's that there are no solutions in C to the problem. Now
there are too many?
> There's no way (except perhaps consulting some Fat Bastard at your
> little shop, or one of the regs here, such as the pathological liar
> Heathfield) of telling which library actually works, and this is a
> serious matter, because statistically, C programs are less likely to
> work than C Sharp independent of programmer skill: this is a
> mathematical result of the ability to alias and the fact that other
> people change "your" code.
I don't get what your rant is. By your logic we shouldn't trust the
code you produced since we didn't write it.
Also, if I import version X of an OSS library then NOBODY is changing
it on me...
> ...only to find for example that simultaneous calls fail because
> global data cannot be hidden properly in C. There's no static nesting
> whatsoever, have you noticed? Even PL.1 had this!
Um, the stack of the threads is where you typically put cheap per-
thread data. Otherwise you allocate it off the heap. In the case of
the *_r() GNU libc functions they store any transient data in the
structure you pass it. That's how they achieve thread safety.
It's like in OOP where you have a fresh instance of a class per
thread. The class has public/private data members that are unique to
the instance. OMG C++ HAS NO THREAD SAFETY!!!
> The result? If the library function has a state it cannot be called by
> a handler handling its failure. This is well known for malloc() but
> unknown and unpredictable for any arbitrary "solution" recommended by
> some Fat Bastard, recommended by some pathological liar, or found in a
> Google search.
malloc() is thread safe in GNU libc. It can fail/succeed in multiple
threads simultaneously. What's your point?
> Seriously, it is well known to the regs here that I am Edward G.
> Nilges.
I didn't know that (nor do I assume to know that, being the victim of
a joe-job myself I don't trust anything most people say w.r.t.
identities unless they prove it through other means). That being
said, why not reserve your posts for more positive or constructive
contributions instead?
Tom
Tom St Denis
> In fact, the regs you so admire almost never post new code, for
> they're afraid of making errors.
You say that like it's a bad thing. Real developers SHOULD be afraid
of "winging" it. Software [no matter the language] is hard to get
right all the time. A smart developer would re-use as much as
possible, such that if you had asked me to write, say a routine to
store GZIP'ed data, I'd call libz, I wouldn't re-invent a deflate/gzip
codec on the fly just to boast of what a wicked C coder I am...
In this case, I would have googled for a hash API, and wrote a program
based on it. The fact that GNU libc provides one as part of the
standard library means I would have used it.
The fact that these concepts are foreign to you just serves to prove
you know nothing of software development.
Tom
spinoza1111
> On Dec 30, 7:54 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > In fact, the regs you so admire almost never post new code, for
> > they're afraid of making errors.
>
> You say that like it's a bad thing. Real developers SHOULD be afraid
> of "winging" it. Software [no matter the language] is hard to get
> right all the time. A smart developer would re-use as much as
> possible, such that if you had asked me to write, say a routine to
> store GZIP'ed data, I'd call libz, I wouldn't re-invent a deflate/gzip
> codec on the fly just to boast of what a wicked C coder I am...
That's true. The exception: teachers, who have to "reinvent the wheel"
to explain how hash functions work or in Schildt's case, how C works.
And of course they're going to get it wrong. The best use the getting-
it-wrong to help students learn, as in the case where the teacher
allows the student to correct him, or find something he missed. The
most famous example being Knuth's checks to people who find bugs in
his books...hmm, maybe Seebach is mad at Herb for not cutting him a
check.
In my case I needed to illustrate an important fact about C Sharp:
that it's not interpreted. If it were, its execution time would be an
order of magnitude (ten times) higher. It wasn't.
I also intended to show that C Sharp avoids reinventing the wheel by
providing a canonical set of libraries that function in a truly
encapsulated way. In C Sharp, you just don't have to worry about re-
entrance UNLESS (and this is the only exception that comes to mind)
the routine you call uses disk memory for some silly reason, say
writing and reading to the infamous "Windows Registry". Whereas in C,
malloc() and other routines aren't re-entrant.
I've called these "forensic" concerns (my term of art) because they
have to do with things that you have to worry about, for which there
is no definable deliverable: you can deliver C code but you cannot
provide a forensic assurance that it's completely exposure free.
This is true even if you're as competent as the regs here fantasize
themselves to be, because truly great programmers in many cases make
more mistakes as part of being more productive, and more creative.
Knuth famously claimed that every time he does binary search he makes
the same mistake, and John von Neumann bragged about his errors (after
fixing them). Whereas here, technicians wait in Adorno's "fear and
shame" for their errors to be detected.
In this toxic environment, anyone who tries to teach or learn is
exposed to thuggish conduct from people who cannot teach and learn by
rote.
>
> In this case, I would have googled for a hash API, and wrote a program
> based on it. The fact that GNU libc provides one as part of the
> standard library means I would have used it.
>
> The fact that these concepts are foreign to you just serves to prove
> you know nothing of software development.
Guess not, Tommy boy. In fact, I've seen software development "mature"
to the point where nothing gets done because everybody equates
rationality with the ability to dominate conversations, if necessary
by trashing other people. I want very little to do with this type of
software development, which is why I left the field for English
teaching after a successful career that at thirty years was about
three times longer than the average.
>
> Tom
Tom St Denis
> That's true. The exception: teachers, who have to "reinvent the wheel"
> to explain how hash functions work or in Schildt's case, how C works.
> And of course they're going to get it wrong. The best use the getting-
> it-wrong to help students learn, as in the case where the teacher
> allows the student to correct him, or find something he missed. The
> most famous example being Knuth's checks to people who find bugs in
> his books...hmm, maybe Seebach is mad at Herb for not cutting him a
> check.
USENET postings != published book. I'm not going to write from memory
the AES encryption algorithm every time a student asks about it in
sci.crypt. I'll answer questions about parts of it, and point them to
source if they need a reference.
Why would anyone here repeatedly post complicated and time consuming
code for every single newcomer who comes by to ask? If you want to
learn about hashing and data management, buy a book on the subject and/
or google.
> In my case I needed to illustrate an important fact about C Sharp:
> that it's not interpreted. If it were, its execution time would be an
> order of magnitude (ten times) higher. It wasn't.
Depends on what you're doing. If your application is highly syscall
dependent [e.g. reading large files from disk] an interpreted program
might not be much slower than compiled. In this case though, all you
showed is that if you use the wrong algorithm in C you get slower
results than the right algorithm in C#.
> I also intended to show that C Sharp avoids reinventing the wheel by
> providing a canonical set of libraries that function in a truly
> encapsulated way. In C Sharp, you just don't have to worry about re-
> entrance UNLESS (and this is the only exception that comes to mind)
> the routine you call uses disk memory for some silly reason, say
> writing and reading to the infamous "Windows Registry". Whereas in C,
> malloc() and other routines aren't re-entrant.
C# does ***NOT*** include every possible routine a developer would
ever need. If it did there wouldn't be third party C# libraries out
there. So your point is not only wrong and based on false pretenses,
but ignorant and naive.
Also as I posted elsewhere malloc() *is* thread safe in GNU libc.
It's even thread safe in the windows C runtime libraries.
> I've called these "forensic" concerns (my term of art) because they
> have to do with things that you have to worry about, for which there
> is no definable deliverable: you can deliver C code but you cannot
> provide a forensic assurance that it's completely exposure free.
You need to learn how to write testable and verifiable software.
> This is true even if you're as competent as the regs here fantasize
> themselves to be, because truly great programmers in many cases make
> more mistakes as part of being more productive, and more creative.
Which is why they don't wing it in USENET posts, instead they reduce
things to proven quantities. If I spend the time and energy to test
and verify a hash library, I can then reduce my correctness to the
fact that I've already checked the library. I don't need to re-verify
everything.
> In this toxic environment, anyone who tries to teach or learn is
> exposed to thuggish conduct from people who cannot teach and learn by
> rote.
You can't teach because you lack the humility to admit when you're
wrong.
> Guess not, Tommy boy. In fact, I've seen software development "mature"
> to the point where nothing gets done because everybody equates
> rationality with the ability to dominate conversations, if necessary
> by trashing other people. I want very little to do with this type of
> software development, which is why I left the field for English
> teaching after a successful career that at thirty years was about
> three times longer than the average.
Resorting to insults won't win you any points. All you've "proven" in
this thread is you fundamentally don't understand computer science,
that you don't know C that well, that you can't teach, that you're not
that familiar with software engineering, and that you're genuinely not
a nice person.
Tom
Kenny McCormack
Tom St Denis <t...@iahu.ca> described himself to a tee thusly:
...
>Resorting to insults won't win you any points. All you've "proven" in
>this thread is you fundamentally don't understand computer science,
>that you don't know C that well, that you can't teach, that you're not
>that familiar with software engineering, and that you're genuinely not
>a nice person.
Its so funny - all of those things are true to a tee about you.
Projecting much?
spinoza1111
> On Dec 30, 8:04 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > I addressed this point before you mentioned it. I said that I don't
> > want to use virtual slave labor (which is what open source is) at GNU
> > nor do I want to go to some creepy site.
>
> OSS is hardly slave labour. Many people in that scene get paid for
> their work. It's just a community effort. Of course if this is how
> you play ostrich then so be it.
>
> > False. I posted the example to show how a real problem is typically
> > solved. In C, the default is to hack new code. In C Sharp the default
> > is to use a tool. The fact is most C programmers are deficient at
> > reuse.
>
> Citation needed.
OO was developed because of insufficient code reuse. In my own book, I
show how I developed each distinct piece of the puzzle was developed
as something that could be independently tested, and reused. An Amazon
reviewer (A Customer at
http://www.amazon.com/Build-Your-NET-Language-Compiler/product-reviews/1590591348/ref=cm_cr_pr_link_2?ie=UTF8&showViewpoints=0&pageNumber=2&sortBy=bySubmissionDateDescending)
writes:
"This book contains a huge amount of code that has obviously been
under development and evolving for a long time. The code has a level
of documentation, error checking and self-consistency testing that is
rare to see even in commercial code, much less sample code for a
book."
You see, OO (which C does NOT have) allowed me to craft the compiler
in a few months in 2003, since I used basic software (such as software
to parse words and do arithmetic in nondecimal bases) which I'd
written in the Nineties. I didn't have to worry about this code
breaking something remote since it existed in static libraries.
On this foundation I was able to build encapsulated stateful objects
such as the scanner, the representation of a data type, and the
representation of a variable at run time. Each one of these is
deliverable as testable, stand alone.
The kicker is that I worked in Visual Basic (.Net). Apart from its
lack of modern syntactic sugar, its clunky syntax is in fact block-
structured, with the blocks being expressed in a very different way
from C. The key was the structure imposed by the .Net object oriented
environment.
>
> > The problem isn't that C doesn't come with a hash library. The problem
> > is that it comes with too many.
>
> So first it's that there are no solutions in C to the problem. Now
> there are too many?
It is rather paradoxical but true, but if one's truly worried about
software reliability (which few programmers are in fact) then a large
set of solutions, any one of which can with a great deal of
probability be buggy owing to the aliasing and "powerful" nature of C,
constitutes a null set UNTIL you have done your homework and
determined the subset of "solutions" that work. We see this all the
time here, with constant wars over which C solution is "best" or even
works.
For example, we're not supposed to expect a basic malloc() to work
recursively, and we're not supposed to use sprintf(). The large number
of tools is actually the problem.
Every time I read the following words of the midcentury sociologist
and musician Theodore Adorno, I am astonished by his prescience as
regards computing:
"Their intellectual energy is thereby amplified in many dimensions to
the utmost by the mechanism of control. The collective stupidity of
research technicians is not simply the absence or regression of
intellectual capacities, but an overgrowth of the capacity of thought
itself, which eats away at the latter with its own energy. The
masochistic malice [Bosheit] of young intellectuals derives from the
malevolence [Bösartigkeit] of their illness."
>
> > There's no way (except perhaps consulting some Fat Bastard at your
> > little shop, or one of the regs here, such as the pathological liar
> > Heathfield) of telling which library actually works, and this is a
> > serious matter, because statistically, C programs are less likely to
> > work than C Sharp independent of programmer skill: this is a
> > mathematical result of the ability to alias and the fact that other
> > people change "your" code.
>
> I don't get what your rant is. By your logic we shouldn't trust the
> code you produced since we didn't write it.
Please don't, since it was produced to illustrate things off the cuff.
>
> Also, if I import version X of an OSS library then NOBODY is changing
> it on me...
>
> > ...only to find for example that simultaneous calls fail because
> > global data cannot be hidden properly in C. There's no static nesting
> > whatsoever, have you noticed? Even PL.1 had this!
>
> Um, the stack of the threads is where you typically put cheap per-
> thread data. Otherwise you allocate it off the heap. In the case of
> the *_r() GNU libc functions they store any transient data in the
> structure you pass it. That's how they achieve thread safety.
It's a clumsy and old-fashioned method, not universally used. It also
has bugola potential.
You see, the called routine is telling the caller to supply him with
"scratch paper". This technique is an old dodge. It was a requirement
in IBM 360 BAL (Basic Assembler Language) that the caller provide the
callee with a place to save the 16 "general purpose registers" of the
machine.
The problem then and now is what happens if the caller is called
recursively by the callee as it might be in exception handling, and
the callee uses the same structure. It's not supposed to but it can
happen.
In OO, the called "procedure" is just a separate object instance with
completely separate work areas. The caller need do nothing special,
and this means that things are less likely to break under maintenance.
Whereas your "solution" violates a central tenet of good software: the
caller should NOT have to do anything special based on the internal
needs of the callee.
Your solution partitions library functions that need scratch memory
from pure functions. Such apartheid always creates problems, for
example where the library developers discover that a library routine
needs (or does not need) state.
>
> It's like in OOP where you have a fresh instance of a class per
> thread. The class has public/private data members that are unique to
> the instance. OMG C++ HAS NO THREAD SAFETY!!!
>
> > The result? If the library function has a state it cannot be called by
> > a handler handling its failure. This is well known for malloc() but
> > unknown and unpredictable for any arbitrary "solution" recommended by
> > some Fat Bastard, recommended by some pathological liar, or found in a
> > Google search.
>
> malloc() is thread safe in GNU libc. It can fail/succeed in multiple
> threads simultaneously. What's your point?
That's nice to know. But not all mallocs are create equal, are they.
>
> > Seriously, it is well known to the regs here that I am Edward G.
> > Nilges.
>
> I didn't know that (nor do I assume to know that, being the victim of
> a joe-job myself I don't trust anything most people say w.r.t.
> identities unless they prove it through other means). That being
> said, why not reserve your posts for more positive or constructive
> contributions instead?
Each thread I start begins with a positive contribution. Then the regs
fuck with me and I don't take it lying down.
>
> Tom
spinoza1111
> On Dec 30, 7:42 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > The process has consistently started with "regs" here questioning my
> > bonafides, since I write markedly better (more consistently excellent
> > grammar and spelling, wider vocabulary, more knowledge) than the regs.
> > Their defensive response has been to start attacks, and newbies and
> > fools read the attacks only. This causes them to join what constitutes
> > a cybernetic mob.
>
> I don't care about the "regs," in this thread I only care about what
> YOU are trying to pass off as knowledge.
>
> > Whether you like it or not, and whether or not you've been
> > oversocialized to not defend yourself, I defend myself, and this
> > creates the illusion that I'm making trouble.
>
> Defend yourself by being right then. If you're trying to make
> arguments actually make sure they're sound and well reasoned instead
> of just shotgunning stupidity and seeing what sticks.
>
> > Dude, learn how to spell. The first step is to select a quality tool.
> > C is not a quality tool since it exists in incompatible forms and was
> > never properly designed.
>
> Which is ironic given how much of your day to day life is probably the
> result of C programs...
ROTFLMAO
Oh great C how have I offended thee?
You power the ATM which won't give me money!
I abase me before thee oh C thou God
You help make the Body Butter I put on my bod.
Give. Me. A. Break. The daily life of ordinary people is on balance
MESSED UP by computer systems, especially computer systems programmed
by thugs who refuse to learn modern languages designed for
reliability. Starting with the financial models that assembled the
"securitized mortgages" so carelessly as to cause a massive financial
crash.
I really, really hope that the next time I fly an Airbus its avionics
are in Ada...not C, and it's likely they are, since Europeans feel no
special loyalty towards C.
>
> So far it seems to be you saying C sucks, and nobody caring. I don't
> care if you program in C or not. I'm only replying here because you
> posted some nonsense comparison and are trying to pass it off as
> science. You're a fraud.
>
> > But that's a good idea. I shall indeed do so ASAP. We need to see how
> > C sharp performs for the ignorant programmer who doesn't know hashset.
> > My prediction is poorly, for as I was the first to say in this thread,
> > the algorithm used in the C program slows down as the table fills.
>
> So why bother the comparison? If you knew your algorithm in your C
> program was not comparable why bother?
>
> That'd be like comparing bubble sort in C# to qsort in C ...
My point was that the two programs took roughly the same TIME to do
the same THING, but the C program had a performance issue. It did so
because like the C Sharp program, it used the most direct method.
In C, if you don't have the time to reuse code, you do it yourself,
hopefully based on a model in Knuth (or Schildt). The simplest and
most obvious way to hash is to use the adjacent cells, not the linked
list.
In C Sharp the simplest way to hash is to select the ONE library that
is shipped with .Net.
That silly "1984" Apple ad, with the Father talking about the "one
right way" and the cute runner smashing the glass, has overinfluenced
minds here. It's silly (and Theodore Roszak made this point at the
same time as the Apple ad in a small essay called "From Satori to
Silicon Valley") to believe that high technology can be a matter of
"freedom"; it seemed to Roszak that it's about control, and
exacerbating social inequality. C programmers bought into the illusion
that they could be "free" and "code the way they wanted" and the
result was a forensic mess: one is constantly learning that this or
that function (such as sprintf()) can't be used by grave "libertarian"
lawn trolls whose abstract committment to freedom is in fact belied by
the necessarily thuggish way in which they have to ensure that what
they THINK is right, is followed.
That is: if you kill the Father you still have Big Brother.
>
> > We don't know whether the .Net runtime is in C, since the particular
> > implementation I use is closed source. But there is no necessary
> > connection between C and the .Net runtime, or Windows and .Net.
> > The .Net runtime can be written in anything you like, such as
> > unmanaged C Sharp.
>
> Well the Windows kernel has a C interface for the syscalls. So at
> some point something has to call that. So chances are good that the
> C# runtime is based on top of the C runtime.
Your point being. My experience inside IBM and what I know of
Microsoft is that development groups who do this sort of work use
proprietary code generators which might generate C but which force
programmers to code a certain way.
>
> Tom
Richard Harter
<spino...@yahoo.com> wrote:
>On Dec 30, 9:32=A0pm, Tom St Denis <t...@iahu.ca> wrote:
>> On Dec 30, 8:04=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
[snip]
>> Um, the stack of the threads is where you typically put cheap per-
>> thread data. =A0Otherwise you allocate it off the heap. =A0In the case of
>> the *_r() GNU libc functions they store any transient data in the
>> structure you pass it. =A0That's how they achieve thread safety.
>
>It's a clumsy and old-fashioned method, not universally used. It also
>has bugola potential.
>
>You see, the called routine is telling the caller to supply him with
>"scratch paper". This technique is an old dodge. It was a requirement
>in IBM 360 BAL (Basic Assembler Language) that the caller provide the
>callee with a place to save the 16 "general purpose registers" of the
>machine.
>
>The problem then and now is what happens if the caller is called
>recursively by the callee as it might be in exception handling, and
>the callee uses the same structure. It's not supposed to but it can
>happen.
He's not talking about the technique used in BAL etc. The
transient data is contained within a structure that is passed by
the caller to the callee. The space for the structure is on the
stack. Recursion is permitted.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.
Tom St Denis
wrote:
> In article <cca8960d-b90d-4714-a100-3cc3682e3...@1g2000vbe.googlegroups.com>,
Citation needed.
Tom
Tom St Denis
> OO was developed because of insufficient code reuse. In my own book, I
> show how I developed each distinct piece of the puzzle was developed
> as something that could be independently tested, and reused. An Amazon
> writes:
Amazon reviews are bullshit most of the time. I have published two
books of my own [which I won't cite]. And for one of them I had
people carrying over from usenet [when I was being joejobed]
protesting the book. So what? Review comments are meaningless.
Code reuse is NOT a sole feature of OO programming languages.
> You see, OO (which C does NOT have) allowed me to craft the compiler
> in a few months in 2003, since I used basic software (such as software
> to parse words and do arithmetic in nondecimal bases) which I'd
> written in the Nineties. I didn't have to worry about this code
> breaking something remote since it existed in static libraries.
If I were to write a quick parser [beyond trivial complexity] today
I'd use flex and yacc... tools written years ago to do such a job... I
don't have to re-invent the wheel.
> On this foundation I was able to build encapsulated stateful objects
> such as the scanner, the representation of a data type, and the
> representation of a variable at run time. Each one of these is
> deliverable as testable, stand alone.
Ya, and?
> The kicker is that I worked in Visual Basic (.Net). Apart from its
> lack of modern syntactic sugar, its clunky syntax is in fact block-
> structured, with the blocks being expressed in a very different way
> from C. The key was the structure imposed by the .Net object oriented
> environment.
I'm happy for you. How does any of this have any bearing whatsoever
on you misrepresenting computer science throughout this thread?
> It is rather paradoxical but true, but if one's truly worried about
> software reliability (which few programmers are in fact) then a large
> set of solutions, any one of which can with a great deal of
> probability be buggy owing to the aliasing and "powerful" nature of C,
> constitutes a null set UNTIL you have done your homework and
> determined the subset of "solutions" that work. We see this all the
> time here, with constant wars over which C solution is "best" or even
> works.
And there aren't competing libraries/classes in Java and C#? This is
more naive nonsense.
> For example, we're not supposed to expect a basic malloc() to work
> recursively, and we're not supposed to use sprintf(). The large number
> of tools is actually the problem.
How does malloc() work recursively? Like what does that even mean?
Can you show some C code that recursively calls malloc()?
> It's a clumsy and old-fashioned method, not universally used. It also
> has bugola potential.
The alternative is you pass things globally. And I don't get how
myclass::member(...) { this.integer = 5; }
Is any diff from say
myclass_member(struct self *this, ...) { this->integer = 5; }
In terms of data storage. If you write
myclass mc;
mc.member();
Or
struct self mc;
myclass_member(&mc);
They're both essentially on the stack, and you're passing data as
such.
> In OO, the called "procedure" is just a separate object instance with
> completely separate work areas. The caller need do nothing special,
> and this means that things are less likely to break under maintenance.
> Whereas your "solution" violates a central tenet of good software: the
> caller should NOT have to do anything special based on the internal
> needs of the callee.
Um, if your function needs transient data, the callee has to maintain
that or you can NEVER be thread safe. Suppose I have a class with a
function doWork(void); How do I tell doWork() what data to work on?
It'll be a member of the class right? And who maintains the class?
The caller.
You're writing nonsense again...
Generally speaking if a function needs scratch memory that is not used
between calls the function itself will maintain it, not the caller.
The structure you pass to the GNU libc *_r() functions is not scratch
memory though. It's your damn data management structures...
> > malloc() is thread safe in GNU libc. It can fail/succeed in multiple
> > threads simultaneously. What's your point?
>
> That's nice to know. But not all mallocs are create equal, are they.
malloc() has a very prescribed behaviour. For platforms which support
threading [which is not part of C99] they MUST support thread-safe C99
libc functions.
> Each thread I start begins with a positive contribution. Then the regs
> fuck with me and I don't take it lying down.
This thread [and all posts therein] contain nothing but your asinine
lies, fabrications, and other manufactured "facts." I'm not fucking
with you, I'm just pointing out that you've been repeatedly dead
wrong. Try posting things that are true and people will stop
correcting you.
Tom
Tom St Denis
> My point was that the two programs took roughly the same TIME to do
> the same THING, but the C program had a performance issue. It did so
> because like the C Sharp program, it used the most direct method.
But not even. You could have used a hash library, one which even
comes with GNU libc to do the same work. You chose not to. That's
nobody's fault but yours. And even then you used the least efficient
configuration possible. You even admitted as much to. So your "test"
proved nothing except you don't know how to run a test.
> In C, if you don't have the time to reuse code, you do it yourself,
> hopefully based on a model in Knuth (or Schildt). The simplest and
> most obvious way to hash is to use the adjacent cells, not the linked
> list.
Yes, but if I knew I had 1000 entries to hash I wouldn't have used a
hash with only 1000 buckets. I would have used one with say 2000 or
more (so you're not 100% full). And I sincerely, with every fibre of
my being doubt that Knuth endorses a "wing it" approach to software
development. And even if he did, he is NOT the authority on software
engineering. He's a computer scientist for sure, far beyond my own
standards, but he isn't [as far as I know] much of a software
developer in terms of writing maintainable code, documentation, etc,
etc.
And regardless, this has nothing to do with C itself. You could
ascribe that development model to ANY language. So keep your
criticism specific to C itself.
> In C Sharp the simplest way to hash is to select the ONE library that
> is shipped with .Net.
What if the supplied hash library isn't suitable for what you need to
hash? What if a tree is more suitable? What if it's a specific form
of RB-tree or ... I sincerely doubt C# comes standards with every form
of data management technique known to man.
Can I conclude from that then that C# sucks because it doesn't have
splay tree functionality as part of the standard library?
Tom
Rui Maciel
> So, "we" are not impressed with your stunt. You optimized code not
> meant to be optimized
Amazing.
Rui Maciel
Seebs
> And I sincerely, with every fibre of
> my being doubt that Knuth endorses a "wing it" approach to software
> development. And even if he did, he is NOT the authority on software
> engineering. He's a computer scientist for sure, far beyond my own
> standards, but he isn't [as far as I know] much of a software
> developer in terms of writing maintainable code, documentation, etc,
> etc.
Actually, he sort of is -- in the sense that he developed an entire new
model of programming in order to write software that he could maintain
with very, very, few bugs. If you get a chance, pick up and read his
book on literate programming; I'm not 100% sold on it, but you can
hardly argue with the maintainability and reliability of TeX.
> Can I conclude from that then that C# sucks because it doesn't have
> splay tree functionality as part of the standard library?
No, you can only conclude that Spinny is not really arguing from
anything but emotion.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
Keith Thompson
> On Dec 30, 11:39 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
[...]
> This thread [and all posts therein] contain nothing but your asinine
> lies, fabrications, and other manufactured "facts."
Tom, "spinoza1111" has been told this N times, for some very large
value of N. What makes you think that his response to the N+1th
attempt will be any different?
You are wasting your time (and ours) by attempting to reason with him.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Seebs
> OSS is hardly slave labour. Many people in that scene get paid for
> their work. It's just a community effort. Of course if this is how
> you play ostrich then so be it.
In the interests of full disclosure: $DAYJOB is the Linux side of Wind
River Systems. I get paid for writing open source software, and we do
indeed distrubute most of what I write under open source licenses. Not
because of linking with other open source software, but because management
believes that it's good citizenship to contribute back to the community
as well as using free code.
We contribute back to projects, from bug reports to patches. One of
my cowokers has put a ton of work into implementing debugger
support in the Linux kernel, and more importantly (to the community)
into making that support clean enough for upstream inclusion.
>> Seriously, it is well known to the regs here that I am Edward G.
>> Nilges.
> I didn't know that (nor do I assume to know that, being the victim of
> a joe-job myself I don't trust anything most people say w.r.t.
> identities unless they prove it through other means). That being
> said, why not reserve your posts for more positive or constructive
> contributions instead?
Because he can't make any, I think?
Richard
Amazing isn't it. Tom comes rolling in here pronouncing his ill thought
out views, gets his arse handed to him on a plate pretty much, starts
huffing and puffing about the bleeding obvious (he has to be a Dilbert
character - something like "Obvious Tom" - you know with meeting
highlights such as "Let's not lose our focus on quality" or "This
solutions needs to be Engineered". He's another one of those MS hating
blowhards whose been allowed to blow his own self importance up a little
high.
I'm still laughing at him when he was on his soap box about good
programmers and designing SW as opposed to hacking shit together. Duh! I
never thought of that ...
As for his comments about C, well, It sure gave me a chuckle.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Richard Harter
<ks...@mib.org> wrote:
>Tom St Denis <t...@iahu.ca> writes:
>> On Dec 30, 11:39 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>[more of the same]
>[...]
>> This thread [and all posts therein] contain nothing but your asinine
>> lies, fabrications, and other manufactured "facts."
>
>Tom, "spinoza1111" has been told this N times, for some very large
>value of N. What makes you think that his response to the N+1th
>attempt will be any different?
>
>You are wasting your time (and ours) by attempting to reason with him.
So why are you reading this thread?
Keith Thompson
> On Wed, 30 Dec 2009 11:48:51 -0800, Keith Thompson
> <ks...@mib.org> wrote:
>>Tom St Denis <t...@iahu.ca> writes:
>>[more of the same]
>>[...]
>>> This thread [and all posts therein] contain nothing but your asinine
>>> lies, fabrications, and other manufactured "facts."
>>
>>Tom, "spinoza1111" has been told this N times, for some very large
>>value of N. What makes you think that his response to the N+1th
>>attempt will be any different?
>>
>>You are wasting your time (and ours) by attempting to reason with him.
>
> So why are you reading this thread?
Hmm. I don't have a good answer to that.
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
>c...@tiac.net (Richard Harter) writes:
>> On Wed, 30 Dec 2009 11:48:51 -0800, Keith Thompson
>> <ks...@mib.org> wrote:
>>>Tom St Denis <t...@iahu.ca> writes:
>>>> On Dec 30, 11:39Â am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>>>[more of the same]
>>>[...]
>>>> This thread [and all posts therein] contain nothing but your asinine
>>>> lies, fabrications, and other manufactured "facts."
>>>
>>>Tom, "spinoza1111" has been told this N times, for some very large
>>>value of N. What makes you think that his response to the N+1th
>>>attempt will be any different?
>>>
>>>You are wasting your time (and ours) by attempting to reason with him.
>>
>> So why are you reading this thread?
>
>Hmm. I don't have a good answer to that.
Looks like another leaky killfile.
Seebs
> Hmm. I don't have a good answer to that.
I have something of one:
The fact is, you can learn a lot more sometimes from understanding why
something is wrong than you would from understanding why it is right.
I've seen dozens of implementations, recursive and iterative alike, of
the factorial function. Spinny's was the first O(N^2) I've ever seen,
and it actually highlights something that may be non-obvious to the
reader about interactions between algorithms.
Watching people who do understand something explain why someone who
doesn't is wrong can be very enlightening. We recently had someone in
comp.lang.ruby who was advocating that the language be changed to round
outputs "near zero" to zero exactly so that sin(180) would produce the
correct exact value of zero rather than some other value. In fact, this
turns out to be an extremely bad idea -- but the discussion of *why* it's
bad taught me more about floating point.
spinoza1111
> On Wed, 30 Dec 2009 08:39:34 -0800 (PST),spinoza1111
>
>
>
>
>
>
>
> <spinoza1...@yahoo.com> wrote:
> >On Dec 30, 9:32=A0pm, Tom St Denis <t...@iahu.ca> wrote:
> [snip]
> >> Um, the stack of the threads is where you typically put cheap per-
> >> thread data. =A0Otherwise you allocate it off the heap. =A0In the case of
> >> the *_r() GNU libc functions they store any transient data in the
> >> structure you pass it. =A0That's how they achieve thread safety.
>
> >It's a clumsy and old-fashioned method, not universally used. It also
> >has bugola potential.
>
> >You see, the called routine is telling the caller to supply him with
> >"scratch paper". This technique is an old dodge. It was a requirement
> >in IBM 360 BAL (Basic Assembler Language) that the caller provide the
> >callee with a place to save the 16 "general purpose registers" of the
> >machine.
>
> >The problem then and now is what happens if the caller is called
> >recursively by the callee as it might be in exception handling, and
> >the callee uses the same structure. It's not supposed to but it can
> >happen.
>
> He's not talking about the technique used in BAL etc. The
> transient data is contained within a structure that is passed by
> the caller to the callee. The space for the structure is on the
> stack. Recursion is permitted.
If control "comes back" to the caller who has stacked the struct and
the caller recalls the routine in question with the same struct, this
will break.
But the main point is that the callee isn't a black box if I have to
supply it with storage.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
spinoza1111
> On 2009-12-30, Tom St Denis <t...@iahu.ca> wrote:
>
> > And I sincerely, with every fibre of
> > my being doubt that Knuth endorses a "wing it" approach to software
> > development. And even if he did, he is NOT the authority on software
> > engineering. He's a computer scientist for sure, far beyond my own
> > standards, but he isn't [as far as I know] much of a software
> > developer in terms of writing maintainable code, documentation, etc,
> > etc.
>
> Actually, he sort of is -- in the sense that he developed an entire new
> model of programming in order to write software that he could maintain
> with very, very, few bugs. If you get a chance, pick up and read his
> book on literate programming; I'm not 100% sold on it, but you can
> hardly argue with the maintainability and reliability of TeX.
Here, Tom engages in a strange offset or shift I've seen in the real
world. This is to defend bad practice by denying that scientific
leaders have any credibility in a slightly offset, slightly redefined
"real world" in which the "best" practitioners are not "scientists":
yet strangely deserve the respect ordinarily given scientists.
The unacknowledged fact: Knuth is seen by the ordinary techie as being
the "champ", or "contendah" he could have been, with long-term
economic security guaranteed not by the impoverishing "free market"
but by tenure. This causes the ordinary techie to slightly redefine
software quality to make himself feel better about a world in which
it's just true that he's been made a perpetual candidate for his own
post and a perpetual infant.
The literate code of TeX is then re-read as somewhat pretentious and a
waste of resources.
It is true that Knuth's literate programming reduces bugs. He observed
that they still occur but diminish exponentially when the programmer
is free to develop as needed his own approaches, including in Knuth's
case the writing of essays about code while the code is being written,
something that Dijkstra did as well.
This is not done in industry. First of all, we need only to look at
the extraordinarily low level of literacy at postings here to realize
that most "senior" people have lost the ability to be coherent, so
much so that provably accurate grammar is to them a marker of mental
disorder. Secondly, essays are a "waste of time" in the infantile
corporate playbook.
>
> > Can I conclude from that then that C# sucks because it doesn't have
> > splay tree functionality as part of the standard library?
>
> No, you can only conclude that Spinny is not really arguing from
> anything but emotion.
I am almost as disgusted with .Net as I am with C, since computer
systems in general are designed to make the rich, richer. I don't
love .Net, and emotion has nothing to do with my preferences. The only
time my emotions are engaged is when you maliciously attack people.
>
> -s
> --
> Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> On Wed, 30 Dec 2009 11:48:51 -0800, Keith Thompson
>
> <ks...@mib.org> wrote:
> >Tom St Denis <t...@iahu.ca> writes:
> >[more of the same]
> >[...]
> >> This thread [and all posts therein] contain nothing but your asinine
> >> lies, fabrications, and other manufactured "facts."
>
> >Tom, "spinoza1111" has been told this N times, for some very large
> >value of N. What makes you think that his response to the N+1th
> >attempt will be any different?
>
> >You are wasting your time (and ours) by attempting to reason with him.
>
> So why are you reading this thread?
Because like "respectable" white Americans, photographed staring at
the strangled and burned black body at a Lynching, they are attracted
to the firelit circle, the screams, the blood and glass.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
spinoza1111
> On 2009-12-30, Keith Thompson <ks...@mib.org> wrote:
>
> > c...@tiac.net (Richard Harter) writes:
> >> So why are you reading this thread?
> > Hmm. I don't have a good answer to that.
>
> I have something of one:
>
> The fact is, you can learn a lot more sometimes from understanding why
> something is wrong than you would from understanding why it is right.
>
> I've seen dozens of implementations, recursive and iterative alike, of
> the factorial function. Spinny's was the first O(N^2) I've ever seen,
Again, if you'd studied computer science in the university
environment, in which practitioners are not being infantilized by
being made perpetual candidates, you'd realize that order(n^2) is not
a evaluative or condemnatory term. It was pointed out to you that the
purpose of the code was to execute instructions repeatedly, and
discover whether C Sharp had an interpretive overhead. It was pointed
out to you that had it such an overhead, the time taken by the C Sharp
would have itself order(n^2) with respect to the C time.
It was pointed out to you that the reason for starting order n^2 was
to factor out random effects from a too-fast program, to let things
run.
In university classes in computer science that you did not attend, a
qualified professor would have shown you that not only is the language
of computational complexity not evaluative, but also that we have to
write such algorithms to learn more.
You are making the same sort of ignorance-based attack you made years
ago on Schildt when you said "the 'heap' is a DOS term".
> and it actually highlights something that may be non-obvious to the
> reader about interactions between algorithms.
>
> Watching people who do understand something explain why someone who
> doesn't is wrong can be very enlightening. We recently had someone in
> comp.lang.ruby who was advocating that the language be changed to round
> outputs "near zero" to zero exactly so that sin(180) would produce the
> correct exact value of zero rather than some other value. In fact, this
> turns out to be an extremely bad idea -- but the discussion of *why* it's
> bad taught me more about floating point.
>
> -s
> --