next »

[Dacke]

The speed.
http://benchmarksgame.alioth.debian.org/u64q/java.html

We're talking approximately a factor of x2 slower than C, I think depending a lot on the problem at hand and JIT and stuff like that. A factor of x2 compared to the ~fastest language is still fast, with interpreted languages often getting something like x20.

[JWki]

That's fair enough I was just irritated because speed really isn't the first thing I'd associate with Java.

[oahda]

To be fair, "the speed of Java" really only means "at the same level as Java", not "Java is fast". c;

[Dacke]

Java UI implementations are usually very sluggish since they reimplement native widgets for cross-platform reasons, the garbage collection can cause minor unpredictable slowdowns (which can matter in situations where things need to run at top speed all the time) and it takes quite a bit of time to start the runtime. So end-user interactions with Java aren't always the best. But it's actually pretty solid when used behind the scenes.

[Dacke]

To be fair, "the speed of Java" really only means "at the same level as Java", not "Java is fast". c;

well, to be fair, when listed as a positive it implies that it's (comparatively) fast ;כ

[oahda]

I honestly don't understand how GC's got so popular when RAII works really well and just as automagically but without leaving stuff hanging in memory.

It restricts program design a bit, but not in a bad way IMO.

I guess this way pointers and heap data in the traditional sense are kind of eradicated, however, since if everything is RAII then heap memory is just as tied to the stack and the scope as stack data. So pointers would really just function as nullable values and references. But I can get far with that. Maybe my opinion is somewhat singular and not realistic in practice on a greater scale? Would love to hear ideas.

[Garthy]

I honestly don't understand how GC's got so popular when RAII works

Garbage collection handles circular references well.

For understanding, I'd suggest digging into garbage collection algorithms (start with mark and sweep), and things such as C++ weak_ptrs (vs. shared_ptr) and considering the problem addressed by weak_ptr. It's a fascinating area.

Enjoy.

[oahda]

I was thinking of a system designed around ownership where everything, if talking C++ terms, would basically either be a unique_ptr (an owner) or a regular pointer/reference (a non-owner). No shared_ptr. Never more than one owner (but ownership can be transferred). Is a weak_ptr really necessary then?

(will check out the stuff you suggested, and maybe that answers my question, but I don't have time right now :e)

[bateleur]

Maybe my opinion is somewhat singular and not realistic in practice on a greater scale? Would love to hear ideas.

From my point of view it's more about what happens when someone messes up.

The history of computing basically looks something like this:

0) No computers.
1) Yay! Computers! Wait... why is everything broken?
2) OK, looks like it's easy to make mistakes, we need to be more careful.
3) OK, maybe we need debuggers too, for when people aren't sufficiently careful.
4) Wow, we're spending 90%+ of our time debugging. Stop making bugs, people!
5) Maybe we need some easier-to-use languages for the idiots who can't get reference counts and pointer arithmetic right?
6) Oh, turns out "those idiots" is basically all of us.

So yes, RAII should be just as robust as garbage collection... it only isn't in practice.

[Dacke]

Rust is designed to prevent common bugs and uses RAII as a part of that. Maybe worth taking a look at?

[oahda]

From my point of view it's more about what happens when someone messes up.

The history of computing basically looks something like this:

0) No computers.
1) Yay! Computers! Wait... why is everything broken?
2) OK, looks like it's easy to make mistakes, we need to be more careful.
3) OK, maybe we need debuggers too, for when people aren't sufficiently careful.
4) Wow, we're spending 90%+ of our time debugging. Stop making bugs, people!
5) Maybe we need some easier-to-use languages for the idiots who can't get reference counts and pointer arithmetic right?
6) Oh, turns out "those idiots" is basically all of us.

So yes, RAII should be just as robust as garbage collection... it only isn't in practice.

Sure. I'm not really thinking about this from the perspective of imagining something failsafe and foolproof, tho, but what I as a versed programmer would enjoy working with. What sort of things would be nice to delegate to the language design itself rather than left at the mercy of the error-prone hands of the programmer. Nulling, deleting and making sure there is never more than one owner (I don't need shared ownership in my designs AFAIK) are things that I would be happy to leave to the language without feeling like I've lost anything.

Rust is designed to prevent common bugs and uses RAII as a part of that. Maybe worth taking a look at?

Yeah, I've looked at Rust. c:

[InfiniteStateMachine]

I cant imagine trying to use a functional language without a GC. Every operation on a list returns a new list where only the affected nodes are new but the unaffected nodes are from the old list. Trying to manually manage the memory for that would be excruciating and very error prone.

One issue with RAII which GC's also suffer from is if you have a heavy resource that goes out of scope you might not want to release that resource at that exact moment because it might cause a hitch etc. Perhaps some sort of connection-oriented resource for instance. Of course that's really just an issue with any type of implicit resource releasing functionality though.

[BorisTheBrave]

Sorry guys, Java is considered pretty fast nowadays. More due to JIT than GC though.

In the game dev world, GC is usually a nonstarter due to the unpredictable latency requirements. But you should know, GC can actually be substantially faster than smart pointers for some workloads.

1) malloc is costly. GC memory allocation is usually little more than incrementing a pointer.
2) free is costly. GCs doesn't pay for garbage, you pay for traced objects at the time of GC (more or less). That means it becomes more efficient the longer you wait between GCs. Nice if you happen to be on a high memory server.
2) GCs compact memory - all the objects end up close to each other regardless of how much is allocated/deallocated. This is friendlier to various forms of caching.

And that's ignoring how limited stack allocation and unique_ptrs are. You should know by know that shared_ptr comes with its own performance penalties.


----

Fun fact. I wrote a toy functional language that used shared_ptr to handle all memory. It worked great... until I blew the stack deallocating a long singly linked list.

[InfiniteStateMachine]

Java and other bytecode languages also have the ability to optimize generated code while the program is still running (hotspot I think it's called in the Java world).

Finally this is an anecdote from a co-worker who works mainly in C. There is apparently enterprise level hardware out there which specifically is targeted at JVM bytecode which can get some massive performance increases for the money you spend. I didn't know exactly what to google but this turned up and is kind of interesting : https://en.wikipedia.org/wiki/Jazelle

Fun fact. I wrote a toy functional language that used shared_ptr to handle all memory. It worked great... until I blew the stack deallocating a long singly linked list.

 

[InfiniteStateMachine]

Figured out how to use git on top of perforce completely transparently so I can use it on existing large perforce repos with a no-git policy.

Really all you have to do is find the section of code you are working on then make a CL with all those files checked out. From there you init a git repo in the root and leave the master branch with no changes. Then whenever you work you work in a branch. When you are done you switch back to master and shelve your CL. When you are ready to submit to P4 you run revert unchanged and reconcile and you're done

[Cheezmeister]

Yep, little known fact that git has a built-in p4 facade. It's still not as nice as working in git natively, but helps keep your sanity if you're forced to work in Perforce.

https://git-scm.com/docs/git-p4

[Garthy]

(will check out the stuff you suggested, and maybe that answers my question, but I don't have time right now :e)

Not a problem. There's way too much stuff to be able to go through it all and offer a timely reply anyway. :} The topics I've mentioned should help to gain an understanding as to the motivations behind a garbage-collected approach. You'll then be able to weigh it up against your preferred approach and come to some pretty good conclusions about each.

There are a class of problems that are best expressed using references to other objects that naturally form cycles that are hard to detect. Manually managing these cycles can be impractical. The simplicity of leaving memory management to the GC also makes the approach appealing too from a usability point-of-view.

[InfiniteStateMachine]

Yep, little known fact that git has a built-in p4 facade. It's still not as nice as working in git natively, but helps keep your sanity if you're forced to work in Perforce.

https://git-scm.com/docs/git-p4

Cool! I never knew that existed. Thanks!

[oahda]

Extremely rarely do I find a use for bitwise operators on my own in day-to-day coding (traditional bit flags don't count!), but today I did! It's nothing special, but the rarity of it still makes it a bit exciting for me. d;

How often do y'all find yourself coming up with bitwise solutions (when not on a microprocessor or something, of course; I mean modern game/application programming in particular)?

[InfiniteStateMachine]

Outside of cheap math and bit flags, almost never.