![](/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) |
>>>> 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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> From what I've seen, only games programmers go to the extremes of using
> obscure and elaborate low-level hackery to squeeze every last
> femtosecond of performance out of the
... desktop ...
> machine.
FTFY.
I take it you've never seen a program written for a cell phone, a set-top
box, or an MP3 player?
--
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) |
Darren New <dne### [at] san rr com> wrote:
> I take it you've never seen a program written for a cell phone, a set-top
> box, or an MP3 player?
Does the iPhone count as one of those?-)
--
- 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:
> 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"...
Well, sometimes it is useful to be able to poke at memory directly.
For example, changing the sign of a floating point value is much faster
by flipping that one bit at the end of it than doing it with the FPU.
(Of course after this little trick your program will assume IEEE floating
point numbers. But for many purposes that suffices.)
--
- 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) |
Darren New <dne### [at] san rr com> wrote:
> How does it handle uninitialized variables? Data flow analysis?
At least gcc gives "warning: 'x' is used uninitialized in this function"
when it sees for sure that this is so, and "warning: 'x' might be used
uninitialized in this function" when it can't be sure but it looks like that.
> That, or accessing memory that has already been freed.
Hasn't happened to me in, like, a decade.
--
- 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) |