Common Lisp, Scheme (OO as a library), O'Caml, Haskell, C (structs+macros), assembly (careful use of structures and macros).
If they can compile to native code depends on the implementation, but all the languages listed have compilers that target some platform's native code (directly or indirectly(through some IR or C)).
>>22
For OO abstractions i meant that you can do some part of what you can express in UML, at least. You can do this fairly good in Java, excluding multiple inheritance (yeah, you can do this with interfaces blah blah blah no you) but Java is teh cancer, and you can't use Java for developing low level shit.
>>41 >>42
Now that we are talking about the performance of Common Lisp implementations, how fast are the commercial Lisps such as Allegro and LispWorks?
>>45-46
If something accelerates uniformly instead of maintaining a constant speed, it makes sense to answer your question with the acceleration, assuming your not dumb enough to figure it out by yourself, ``fucking lithp faggot''.
Name:
Anonymous2011-07-12 15:00
What modern languages there are nowdays that do not have garbage collector and is not C or C++?
You think it's not possible to code withouut GC. Just fucking release your memory in destructor and all is fine. WTF is wrong with you. Fucking Java faggots.
I mean Java does not suck that much, and GC is almost OK but it kills the performance and I just like to RAII more. If you can't code without GC, then there are something wrong with your programming skills.
And I think manual memory management is about as silly as manual CPU register management. (Seriously, demonstrate that there is an essential difference, please.)
Shared references, as a general technique, is also insanely useful. It's not just that having to keep track of "owners" is tedious, it also limits your design considerably.
I tend to write ad-hoc reference counting and GC pretty regularly while writing C++.
Name:
Anonymous2011-07-12 17:43
>>58
Manual register allocation is silly, because the compiler will do it better.
Manual memory managment is not silly, because it is very easy, more predictable and more effiecient.
>>59 more effiecient.
Allocation on copying GCs is done in constant time, malloc is not.
A minor garbage collection (assuming a generational GC) is proportional to the amount of live data. Most object die shortly after being allocated. Free is not smart. The GC can do major garbage collections in a separate thread.
>>60
１．Time complexity != execution time
２．Use system calls instead of glibbloat.
３．What do you plan to do on single-processor systems?
４．You are a ``faggot'' for reliying on another things than your cock and your fingers.
Name:
Anonymous2011-07-12 18:35
Manual memory management is stupid unless you're working on embedded systems in C. If you're working in anything higher level than C you have no right to complain about GC and doing so makes you an idiot.
>>61 １．Time complexity != execution time
You just bump a pointer. Like with stack allocation. ２．Use system calls instead of glibbloat.
You still have to search for a free block of memory. ３．What do you plan to do on single-processor systems?
Use an incremental GC. ４．You are a ``faggot'' for reliying on another things than your cock and your fingers.
Make your own processor, with your own instruction set, then write your own assembler for it, then your own programming language and compiler for it, then the library, then the OS.
Name:
Anonymous2011-07-12 20:47
>>59 very easy
defect rates disagree. Garbage collection is easily correlated with fewer and easier to correct bugs. Enjoy ur heap corruptions.
more predictable
What are you trying to predict? If you know your machine has 4gb available, predictability isn't important. Regardless, there are garbage collected languages with EXTREMELY predictable memory usage, such as PicoLisp.
more efficient
not unless you write your own manager. malloc's performance is not that predictable and C doesn't really give you the tools to reason well about cache coherency anyway. If you're going to abstract SOME aspects of memory, you might as well abstract all of it. Why aren't you arguing for assembly? The C stack is a very rudimentary form of automatic memory management. It just sucks. Why does it get a free pass?
If you care about efficiency you ARE going to write your own memory manager. It may or may not be faster and less buggy than one used by a language implementation. Probably not. It may or may not include reference counting or garbage collection, and therefore make everyone's life easier. Probably not.
Name:
Anonymous2011-07-12 20:51
>>59 Manual register allocation is silly, because the compiler will do it better.
Nope. It's silly because it can easily be made automatic. Programmers shouldn't do things that can be made automatic. Optimization is almost never a good reason. For anything. And at almost never conflicts with the principle of automation. Especially with time. Soon garbage collectors will be faster than all but the most skilled* C programmers, just like compilers are now faster than all but the most skilled* assembly programmers.
Manual memory managment is not silly, because the compiler can't do it at all.
FTFY. Seriously guys, static analysis.
Static analysis: it doesn't always make it faster but it never makes it slower at run time.
I don't mind GC usually. I do however avoid java and python for anything with a UI bec ause of it. If you're going to use GC ffs choose a responsive one.
The US Government is due to establish a Federal Programming Administration (FPA) over the next few weeks. During this time, government officials will be screening individuals for administrative positions and will be laying the groundwork for guidelines which all software companies will soon be required to follow.
Under these guidelines, all computer code will be required to meet a level of quality. "Obviously, there is a lot of code in the market already," explains government technical expert Ryan Jennings. "Thus, the FPA will only screen software by a complaint-by-complaint basis." Jennings goes on to describe a couple of the guidelines. "In the future, programs will have to start up in less than a couple of seconds. The programs themselves have to be programmed in one of the many enterprise languages which are widespread in use, such as Java, VB.NET, and PHP. Remember, a positive user experience is everything here and the FPA will ensure that it happens."
US Congress is due to pass a set of laws in the future which will halt the distribution of computer software deemed "low-quality" by the FPA. According to Jennings, "The goal here is to lower and eventually eliminate the already high amount of poor quality software. Top issues in the agenda include the elimination of functional programming, a sub-par programming practice, and particularly open-source software. Open-source software is seen as destructive to the economy so we already have plans to ban its production." The screening process is estimated to be completed in a few days. "It's only a matter of time, but I'm certain this is going to work out. I really see a bright future in the computer industry."
Name:
Anonymous2011-07-14 0:53
>>55 I've never written a concurrent, multithreaded program or anything over 100 LOC and have no idea what the fuck I'm talking about.
A good language should allow you to trivially express common OO abstractions with higher level, simpler constructs, without needing OO explicitly wired into the language syntax and semantics. Then you will realize while using these higher level constructs that you don't fucking want to do OO in the first place.
In all seriousness, are you one of these idiots who think it's impossible to write correct, scalable code that manually manages memory? Do you think the Linux kernel or the Unreal engine fell out of the sky?
>>83
It's possible, just like it's possible to write correct, scalable code in pure assembly.
In all seriousness, are you one of those idiots who think they have control over machine just by manually managing memory?
Name:
Anonymous2011-07-14 4:28
>>58 And I think manual memory management is about as silly as manual CPU register management. (Seriously, demonstrate that there is an essential difference, please.)
That's downright silly. Using automatic register allocation does not cause periodic stalling of your program while a 'register collector' is run. A garbage collection pause, on the other hand, can severely impact the user experience, and tweaking it to make it less noticeable has significant impact on the resource consumption of the application. There's a reason why no modern game engine is written in a garbage collected language.
Shared references, as a general technique, is also insanely useful. It's not just that having to keep track of "owners" is tedious, it also limits your design considerably.
Failure. You *should* be tracking the ownership of each object as part of the design of your program. Many objects actually need to have explicit ownership because they need to be cleaned up: file handles, network sockets, sql statements and cursors, etc. It's much better to have a good idea of the ownership of all objects.
I tend to write ad-hoc reference counting and GC pretty regularly while writing C++.
You're doing it wrong. So very, very wrong. The resulting code is likely slower than using a GC; if you're too incompetent to manually manage your memory, then use a GC language for fuck's sake, but don't pretend like this is a good thing. I hope I never have to maintain your code. (For the record, I think shared_ptr<> is cancer and you are cancer for using it. scoped_ptr<> and unique_ptr<>, on the other hand, are wonderful.)
>>65 What are you trying to predict? If you know your machine has 4gb available, predictability isn't important.
Dude, it's not about the total memory usage. A big part of it is being able to control the layout of your memory so you get consistent and predictable cache performance. An equally important part is predicting that you won't get a goddamn GC pause in some innocuous piece of code (and before you say malloc is unpredictable, yeah we know it is, which is why manual memory management allows me to write performance-critical sections without fucking allocating memory.)
Name:
Anonymous2011-07-14 4:33
>>84 In all seriousness, are you one of those idiots who think they have control over machine just by manually managing memory?
No; I think I have control over when a GC stall is going to occur. Never. :) I also have a much better idea of the *actual* resources that will be consumed by my application, and that it won't consume an order of magnitude more resources than it actually needs in order to run at a pace that the user will enjoy.
>>94 ONE WORD THE FORCED CAPITALIZATION OF EXPORTED SYMBOLS THREAD OVER
Name:
Anonymous2011-07-14 13:44
>>88
Any language with real first-class closures. JavaScript is a good example of this: the way it does OO is basically glorified closures. The best example is of course Lisp, but I wasn't about to bust that one out first, since you've probably already stopped reading this post by now.
>>55 I mean Java does not suck that much
HAHAHAHA OH BOY
Name:
Anonymous2011-07-14 14:24
Working without GC is easy, at least in C++.
Most of the time you can just use stack. When you actually need heap allocation, most of the time you can wrap it in class and release the memory in destructor. That way you won't get memory leaks.
Sometimes you don't have to wrap the memory in class yourself, but you can use auto_ptr (deprecated) or unique_ptr. That is just as effective as manually using new and delete, but is exception safe and is easier to manage (also you can't forget to free memory). shared_ptr is also ok in some cases, but has some overhead and you can avoid using that by just designing your code better.
However, you have to keep the releasing of the memory in mind when you design your program. If you cannot do that, you are a bad programmer, and should just use GC language.
It really isn't that hard. Only thing you have to remember, is that whenever you use new, you have to also have some mechanism to free the memory.
I agree GC is ok for some cases, for example in scripting languages, where you don't need a good performance. However, many applications that have be coded with GC'd language (like C# or Java) are slow. I'm not sure if it's because they are not native code or because of GC? Some people claim that JIT should make the byte code as fast as native code, so that leaves the GC to be blamed. Or maybe it's because the "premature optimization is the root of all evil" claim that makes these software slow? I don't think so, because software written is C is almost always fast, and software written in C# and Java is almost always slow.
Or maybe it's because coders that need GC are bad programmers and produce slow code?
>>99
You do really think that for most applications, storage that lasts just for the dynamic extent of a procedure will be enough? Suddently, applications have to maintain no state? However, many applications that have be coded with GC'd language (like C# or Java) are slow. I'm not sure if it's because they are not native code or because of GC?
I don't know for .NET, but the JVM is slow because it has to load all the bloat first, and the JIT has to warm up and find the hotspots in your program. Some people claim that JIT should make the byte code as fast as native code, so that leaves the GC to be blamed.
A JIT emits ``native code'', you damned moron. And the GC doesn't run perpetually, and surely not at the startup. Or maybe it's because the "premature optimization is the root of all evil" claim that makes these software slow?
Explain why not assembly, if premature optimization is not evil.
Also, you keep saying ``GCed language'', but I don't see the word ``GC'' in Java's spec, or Lisp's, Scheme's, ....
>>100 Also, you keep saying ``GCed language'', but I don't see the word ``GC'' in Java's spec, or Lisp's, Scheme's, ....
Your estimated IQ dropped at least 50 points after I read your last phrase.
>>97
Don't be a faggot. He's talking about Lisp's indisputably sane semantics. He's not even advocating it or acting elitist towards users of other languages. I say, you are doing a great injustice to >>96-san.
Name:
Anonymous2011-07-14 18:31
>>100
Classic sheltered GC defender, falling back on insults and personal attacks instead of coming up with good arguments.
I don't know for .NET, but the JVM is slow because it has to load all the bloat first
wat
I don't get all this JIT discussion. It has nothing to do with GC. And yes, Java is slow largely because of GC. 98% of the software engineering investment in the JVM has been for the GC.
Name:
Anonymous2011-07-14 19:16
>>103
Classic sheltered manual memory management defender, falling back on idiocy and irrelevant details instead of coming up with good arguments.
Name:
Anonymous2011-07-14 19:28
THIS IS A MESSAGE FROM THE SUSSIX DEV TEAM
If ``premature optimization is the root of all evil'' will intentionally writing slow code make our programs inherently good?
>>103 I don't get all this JIT discussion.
You mentioned the JIT. >>101 Your estimated IQ dropped at least 50 points after I read your last phrase.
You can do automatic memory management without a GC. And the specs still don't mention a GC anywhere.
Name:
Anonymous2011-07-14 20:24
>>85 Using automatic register allocation does not cause periodic stalling of your program while a 'register collector' is run.
automatic register management being efficient is a relatively new invention.
A garbage collection pause, on the other hand, can severely impact the user experience, and tweaking it to make it less noticeable has significant impact on the resource consumption of the application.
this depends on the garbage collection algorithm. I agree that Java's is unsuitable. I've never seen such bad "hiccups" in other implementations, except occasionally with C#.
There's a reason why no modern game engine is written in a garbage collected language.
XNA. Love2d. Moai. Also, EVERY modern game engine has at least 1 scripting language for doing non-intensive things. I seriously give it 5-10 years until you start seeing ground up game engines written in something like LuaJIT.
>you *should* be tracking the ownership of each object as part of the design of your program. Many objects actually need to have explicit ownership because they need to be cleaned up: file handles, network sockets, sql statements and cursors, etc. It's much better to have a good idea of the ownership of all objects.
dynamic-wind (or whatever, it's trivial to implement.) Closures win again. In CL you can even do it with a macro like C# essentially does with its "using" statement. Sorry, but dealing with that kind of stuff is easy with lambdas, and far more explicit than overloading the semantics of "}" the way C++ does. Tying this stuff to the lifetime of an object is a hack to get syntactic sugar, just like everything else in C++.
Name:
Anonymous2011-07-14 20:36
I remember the day that I realized that the C stack was a really limited automatic memory manager. It's probably in the top 20 enlightening moments.
Name:
Anonymous2011-07-14 21:08
>>105
No. The idea is that you write code that is correct. You will then profile that code to get some data about where you need to optimise.
Name:
Anonymous2011-07-14 23:39
>>107 You mentioned the JIT.
Newsflash: there are more than two of us in this thread. *gasp*
>>108 automatic register management being efficient is a relatively new invention.
And automatic memory management is a relatively fictional invention.
I'm not sure what your point is either. People still wrote a lot of stuff in assembly until compilers became efficient. It's 2011 and garbage collectors are still grossly inefficient, so doesn't it make sense to skip them for non-trivial applications? We've seen how slow and unresponsive Java apps like Eclipse can be. They're awful. Besides, manually managing memory is not nearly as difficult or time-consuming as handcoding assembly; in fact memory management comes naturally in a well-designed application.
>>111
there are lots of non-trivial applications that aren't CPU bound or don't need to be performant anyway. For instance, anything that runs on a server and/or deals with a database.
Also Java's performance is due to the fact that it is its own virtual machine. Nobody embeds Java, so there's no way to optimize it by going native.
I think this needs to be said over and over: something is optimized if and only if you can optimize it later after profiling. This is why I consider embedded languages to be faster than giant VM languages. (Please don't use Java as a golden standard of anything because it's not. Nobody here is arguing for Java.)
in fact memory management comes naturally in a well-designed application.
I disagree. Your standards are not correct. Trust me -- I used to think the same thing. But shared references are the way. Good designs use them constantly. But good C++ designs don't. Get it? It's very simple. C++ encourages BAD design, not good.
Name:
Anonymous2011-07-15 0:46
>>111 And automatic memory management is a relatively fictional invention.
He still thinks managing memory is an essential and unsolved problem worthy of premature attention and man-hours before profiling!
laughinggirls.jpg
>>113 there are lots of non-trivial applications that aren't CPU bound or don't need to be performant anyway. For instance, anything that runs on a server and/or deals with a database.
Most software that deals with database are boring and trivial enterprise software.
Also Java's performance is due to the fact that it is its own virtual machine.
No, it's because the GC is slow and the GC encourages programmers to code badly without understanding what affects to the performance. So there are at least two reasons why GC makes Java slow.
But shared references are the way. Good designs use them constantly.
Wtf? Why sould I believe you. Do you have any proof? Have you tried designing your code better?
It's very simple. C++ encourages BAD design, not good.
Not very simple at all. Who says C++ encourages bad design? You? Citation needed!
I don't understand why is reference counting evil.
I'm currently developing a Seihou ripoff in C (not sepples) and I have two basic projectiles types:
- The entity, which contains the state of a bullet and a reference to a function used by a very simplistic virtual machine in order to compute the state from the time the entity has lived;
- The polyline, which is a linked list of pointers to entities.
A polyline is rendered as a polyline connecting the entities, and an entity is simply a sprite.
I'm using reference counting and an ENTITY_INVALID flag in order to permit the removal of an entity while polylines or VM threads still refer to it. When there's a hole in the polyline, I split it in two, and I kill threads referring to invalid entities. Is it bad design?
Also, but that is completely unrelated to the subject, the VM is currently executing an extremely shitty bytecode produced by NASM macros abuse and I'm thinking of replacing it with a Lisp-like interpreter.
>>118
Reference counting has some things people need to be aware of. If you don't use it correctly, you will pay the price.
To correctly do reference counting in C or C++, you need to make the release operation thread-safe, so that if two threads hold a reference to the same object, if the threads release the object at around the same time, it's possible you'll get a double-free unless you protect the reference count.
Generally, this is done using native CPU specific atomic compare-and-swap instructions. These instructions lock cache-lines or even the memory bus. On x86/x86-64, for example, a compare-and-swap takes around 150-200 cycles (where as say a simple dec and jnz might would just be a couple of cycles granted that the reference count is in the CPU cache and the branch predictor doesn't fault.
There's overhead. Therefore you should avoid lots of fine-grained reference counted objects. You don't need to use reference counting for everything. Use reference counting only where you need to, and on heavier-grained objects which explicitly manage smaller-grained objects. That way you can setup strong ownership rules: when the heavier-grained object goes out of scope or is released, it will cleanup and free all of the fine-grained objects it owns, no expensive reference count release operations.
There are also different ways of implementing reference counting: intrusive and external. Intrusive is less expensive in practice, less memory fragmentation, single malloc and free per object, but you can't have weak references which are useful for implementing cycles. External reference counting is more usable, but often allocates the reference count in it's own block of memory, although there are ways to make it intrusive (see C++'s std::make_shared function).
>>118
And yes, it does sound like a bad design. Your entities should probably not use reference counting... reference counting is more for like a group of entities or larger subsystems.
If I were implementing your game, I'd be using the structure of arrays approach, using homogeneous arrays for each entity field/component. Removing an entity would just involve setting a flag, and at a synchronization point during the update pipeline, I would remove the entity by copying the remainder of each array over the entity offset and decrement the entity count.
No reference counting. The entity system/scene graph has strong ownership of the entity arrays, which are generally allocated at load time and have a fixed upper bound.
If you need an object-oriented class to coalesce all of the fields from each array for a particular entity offset/id, just create a simple object-oriented view abstraction, similar to how you can create views in RDBMSes.
This is the data-oriented approach which is popular among professional game developers for modern games. It's fast as fuck, it's easier to parallelize, and doesn't thrash the cache or fragment your allocators. It also usually ends up being less code too than an more OO approach.
Fine-grained object-oriented factory systems for entities/game objects is the amateur design.
Name:
Anonymous2011-07-15 13:37
>>116 Most software that deals with database are boring and trivial enterprise software.
hint: almost all software is essentially pretty trivial. SQL is a functional domain-specific programming language that lets you deal with databases in a trivial fashion. A C++ solution that used no other (superior) technology would turn it into a non-trivial application, just like it does everything else. Triviality is more often dependent on accidental complexity and implementation than it is on essential complexity and the real problem. If you think in C++, you probably have no idea what I'm actually talking about.
Wtf? Why sould I believe you. Do you have any proof? Have you tried designing your code better?
I used to be a C++ fanatic. I saw the light. Here's the thing: when you use a C++ style to design code in a language with proper closures, you get an unmanageable mess (actually, this is what most Java programs are,) and vice versa. So those two positions of the grid are obviously bad. The comparison is C++ style in a C++ program vs closure style in a closure language, and it's not even close. I have literally written code before and thought "the C++ way to solve this (ie not to translate what I'm doing but to do it the legit C++ way) would be 10 times as much code." This is NOT bad design. Less code is always fewer bugs, _easier_ to optimize (provided you can go native,) and easier to manage. For instance, it's actually worth using dynamic typing because your code will be that much smaller that you wan't need static analysis to understand what's going on. I know it's hard to believe, but it's true.
GC encourages programmers to code badly without understanding what affects to the performance.
Am I being trolled? It's true that GC lets you forget about a lot of bullshit that you need to do to write good C++. This is what abstractions are for. Ignoring detail that is meaningless to the problem domain. Again, it's not really essentially different from the details that C lets you ignore about assembly (which actually includes things like cache coherency. The "1-d plain of memory" abstraction leaks like crazy, performance-wise.)
Wtf? Why sould I believe you. Do you have any proof? Have you tried designing your code better?
Not using shared references when it's easy and guaranteed bug-free is a mindlessly tedious and masochistic restriction. How is this not obvious?
Who says C++ encourages bad design? You?
Lots and lots and lots of people. Try googling it. C++ is probably the most legitimately hated language in existence. Complaints are not by lazy undergraduates, but by people who have used it extensively. A pretty famous example: http://yosefk.com/c++fqa/ Also, Linus Torvalds disallows it on his projects "just to keep the C++ guys out."
Seriously just use C. Keep as much as possible in static arrays with small structs. Yeah it's a lot of statements and a lot of typing, but this is how optimization goes. Nobody said optimization was fun or interesting. Very very occasionally it is.
Name:
Anonymous2011-07-15 13:45
>>123
errors are fewer and easier to debug, provided you know what you're doing. You don't even need an IDE. Generally it's just pretty obvious as long as you have like a week or two of experience.
Name:
Anonymous2011-07-15 13:51
>>122
I'm not >>116, but just because you can't design things in C++ that are clean doesn't mean everyone has the same problem. I think you have a misconceived definition of "C++ style".
And yes, while GC isn't the cause of bad programming, it does enable a lot more bad programmers to scrape by. I've seen way more bad Java code than C++, where the Java developers were allocating lots of managed objects with huge memory footprints and creating complex object-graphs that would cause painful cache faults during traversal, leaving file handles open, etc. GC makes it easier for you to get by without thinking about how your data is laid out in memory, thus resulting in potentially less performance.
There are plenty of decent C++ programmers who enjoy the language. The problem is that it's always the haters who are the most vocal. This goes for any subject. In the end, your point is nothing more than argumentum ad populum and various other fallacies.
Name:
Anonymous2011-07-15 13:55
>>124
I'm >>121, I never said to just use C. I actually prefer using C++ to implement the design I mentioned, templates make your life easier, plus you get lambdas/closures which make using the STL algorithms or a algorithmic parallel patterns library like TBB, MPL or Fastflow much easier. The benefit of C++ is that you don't pay for what you don't use in C++, and templates have no overhead over manually hand-expanding the code, and lambdas/closures in C++11/C++0x are just fancy syntactic sugar for functor classes with a member operator() function, which is often less overhead than using a function pointer in C due to the compiler being able to inline the call.
Name:
Anonymous2011-07-15 13:58
And yes, while GC isn't the cause of bad programming, it does enable a lot more bad programmers to scrape by.
The biggest enabler of bad programmers scraping buy isn't GC but OOP, as popularized by C++ and especially Java. A guy can spend all day writing gettors and settors and design patterns that he doesn't understand and fool himself or others into thinking he's been doing work. It's got nothing to do with GC.
>>113 Also Java's performance is due to the fact that it is its own virtual machine.
No, Java is slow because of its language semantics and horrible type system. For example, there are no user-defined value types, so even to return something simple like a Point2D requires an allocation. Type erasure means every time you pull any object out of a collection, you incur a costly type cast. All methods are virtual by default, so you must dynamically dispatch all calls. These things are slow.
I disagree. Your standards are not correct. Trust me -- I used to think the same thing. But shared references are the way. Good designs use them constantly.
This is fucking GOOGLE. They probably have a billion lines of C++, and they are saying that shared counted references is bad design. (They recommend shared_ptr<> only go in containers, something that unique_ptr<> will finally make obsolete.)
Please, please don't use shared_ptr<>. Don't do it. Think about the ownership of your objects, for the good of the people who will maintain your code.
>>140
shared references are bad C++ design. no argument about that.
C++ is bad design though. That is what I'm saying. It's really really simple. Let's take another feature that Lisp invented: real macros.
Technically in C++ it would be possible to build up a string and then compile it and then link your program to it. This would be a terrible idea in C++. But in Lisp you do the equivalent all the time and it's awesome.
Name:
Anonymous2011-07-16 11:28
>>140 No, Java is slow because of its language semantics and horrible type system.
performance is not about language semantics. It's about the ability to profile and take things native. Optimization is NOT something that should be taken on faith and put in the background and done prematurely. We have known this for decades.
The inability to see that starting most projects in C is *premature optimization* is something only someone who has never written anything other than C/C++ has. It's similar to the inability to see that C++ is flawed, brittle, and idiotic in its design.
Name:
Anonymous2011-07-16 19:50
>>147 performance is not about language semantics.
Uh actually, in this case it definitely is. Almost any non-trivial program converted from C++ to Java would run much slower, specifically because of Java's semantics.
No amount of optimization can get around the fact that pulling a float out of a Map is horribly, godawful slow in Java. The language semantics mean that the float had to be boxed into a Float and individually allocated from the heap, and it comes out of the Map as an Object (yes, even if you declared it Map<Float>), so the JVM has to verify that its class hierarchy extends/implements Float before you can finally pull the real fucking float out of it. There is no way to optimize it without hand-rolling your own primitive float map, and no way for the JVM to optimize it either.
The syntax of generics and autoboxing hides the semantics of what is actually going on.
Name:
Anonymous2011-07-16 20:44
>>148
but if Java could be easily embedded in C it would inherit C's performance. This is because bottlenecks are all that matter, and with easy embedding you can find and kill them.
>>149 embedded in C it would inherit the C compiler that happens to compile that C code's performance.
Name:
Anonymous2011-07-17 5:17
>>149
HIBT? this post is nonsensical. It's already effectively embedded in C because the JVM is written in C/C++. (actually HotSpot is half written in assembly, because fast GC is ridiculously hard to implement.)
Name:
Anonymous2011-07-17 6:18
If I write all my Python programs in C, is it still the forced indentation of code?
Name:
Anonymous2011-07-17 13:04
>>151
you are claiming that it is easy to use the JVM as an embedded library in a host C program.