![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Warp wrote:
> > Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> (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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |