Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Safe languages don't permit race conditions in the first place.
> 
>   And then you wonder why safe languages are so slow.

I wonder why everybody _assumes_ they're going to be slow, yes.

Still, I guess it depends on where your priorities are - how fast the 
program runs vs how many years you have to spend in debug activities.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? 
> Does that sound like good abstraction you to?)

  That kind of code is crap.

  I have been programming for well over a decade on an "unsafe" language,
and I have never wrote a program which would break if you add something
to a class or struct.

  I have to admit, though, that not all programs I have ever written would
fully support 64-bit architectures. By this I don't mean they would not
compile as a 64-bit executable or that they would crash when compiled as
such and run. I mean that they would not necessarily fully utilize the
increased address space.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Safe languages don't permit race conditions in the first place.
> > 
> >   And then you wonder why safe languages are so slow.

> I wonder why everybody _assumes_ they're going to be slow, yes.

  Well, if every access to a shared variable is thread-safe, it is going
to be slower than non-locked access.

-- 
                                                          - Warp

Post a reply to this message

>> (Notice that guy who said he couldn't just add a new integer field to a 
>> data structure because it would break a few thousand other functions? 
>> Does that sound like good abstraction you to?)
> 
>   That kind of code is crap.
> 
>   I have been programming for well over a decade on an "unsafe" language,
> and I have never wrote a program which would break if you add something
> to a class or struct.

That one did kind of strike me as "this can't be good".

Still, C is a language where, if you so desire, you can make your code 
depend on the exact size of a struct, the endianness of machine words, 
and all kinds of other things to make your code extra fragile. I suppose 
some people would consider this a "feature"...

>   I have to admit, though, that not all programs I have ever written would
> fully support 64-bit architectures. By this I don't mean they would not
> compile as a 64-bit executable or that they would crash when compiled as
> such and run. I mean that they would not necessarily fully utilize the
> increased address space.

Not taking advantage of new features is to be expected; breaking because 
of them even if you aren't using them seems to be like poor design. 
Still, heaps and heaps of C programs seemed to not like being recompiled 
that way...

Post a reply to this message

>>>> Safe languages don't permit race conditions in the first place.
>>>   And then you wonder why safe languages are so slow.
> 
>> I wonder why everybody _assumes_ they're going to be slow, yes.
> 
>   Well, if every access to a shared variable is thread-safe, it is going
> to be slower than non-locked access.

Locks aren't the only way to implement safe shared variables.

Something like STM with optimistic locking can impose a very small 
overhead. Smaller than locking.

Personally, I'd accept a 1% speed hit if it means I don't have to spend 
decades hunting down weird bugs than vanish when you try to debug them. 
But that's just me...

Post a reply to this message

scott wrote:
> I like the second one too.

That didn't really seem hacky to me, actually. It was the obvious solution. 
Certainly the people who coded the hash in the first place knew there was a 
chance a collision would come up.  The failure there was having the program 
generating the hashes not checking that there was a collision.

> I think in any industry where you have complex projects that need to be 
> finished by a deadline there will always be less-than-optimal hacks to 
> get it "finished".  Usually if you had more time there would be a number 
> of things you could do better.

I had a friend who worked in theater production before programming. It 
always ticked him off when the boss gave a "deadline" and he'd bust butt, 
only to hear that it was more a "this is when we'd like it" than a deadline.

For him, if you didn't stop working and ship whatever you had at the 
deadline, it wasn't a deadline. When the curtain goes up in front of a bunch 
of ticketholders? That's a deadline.

Of course, games trying to hit the christmas season, or cars going into 
production, all count as actual deadlines, as do trade show demos in the 
computer business.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Safe languages don't permit race conditions in the first place.

Nonsense.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Something like STM with optimistic locking can impose a very small 
> overhead. Smaller than locking.

What makes you think you don't get race conditions with STM?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Warp wrote:
>   That was a relatively common problem in C and C++ years ago, but nowadays
> especially C++ compilers have got much better at debugging such things. 

How does it handle uninitialized variables? Data flow analysis? That's often 
where I find heisenbugs come from, more than random walks off the ends of 
arrays.  That, or accessing memory that has already been freed.

Me, right now, I'd be happy not spending 3 days trying to figure out what to 
change such that the program that gets downloaded during 'make' that 
generates the makefile it later invokes whose every compilation line is 100% 
macros most nested at least 5 deep in definitions no longer tries to strip 
the symbols off a library that's actually a text file, with the comment 
"just in case" printed out above it.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? 
> Does that sound like good abstraction you to?)

I think that was a few thousand callback functions. I.e., when an event 
happened, it called you with "process_your_event(int1, int2, voidp)" and 
you'd have to recode all those headers.

(Honestly, I think that would be rather easy, myself.)

> I was also puzzled when I looked at Gentoo and discovered just how many 
> C programs break horribly just because they were written for IA-32 and 
> got recompiled for AMD64.

Yep. The problem with C is that it offers you the machine's capabilities and 
you pick which of them you want. In Ada, for example, you tell it the range 
of values you want to handle, and it picks the appropriate machine 
structure.  C is only portable to the extent you write multiple versions of 
the source code in the same file.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message