Show newer

@namark If your reaching the point in a project where memory issues wind up costing significant investment of time late in a project then the project either picked the wrong language or simply doesnt have good programmers.

My job is more often than not to get called in to write or fix software that the current less expiernced team is not capable of making performant on their own. Sometimes that means I need to rewrite it in C, but this is very rare. More often than not the problems arise from bad design choices from the start of the problem and are easily fixed with the right expiernce without the investment of time you suggest.

That said my own projects are ones that rely on being extremely efficient as a purpose of their design (for example Aparapi's whole point is GPU accelerating java code , so efficiency is paramount). In all these cases performance was done right from the get go and the problems you describe never arose. Yes I would profile and sometimes need to optimize. But this process was always a relatively easy and short process.

So my assumption is that either your own expiernce was simply lacking in the languages you had this problem in, and you made poor design choices, or your team was making poor choices. Not the language itself.

As an example a national trucking company with tens of thousands of trucks on the road across the USA called me in to optimize their system. It was mostly graph optimization problems (think traveling salesman sort of stuff), so extremely sensitive to memory management and other efficiency issue. Their current software written in C was massive and ran across an entire server room about about 50 computers on racks. I was able to improve the rate at which it computed solutions by 10 fold and reduce the number of computers from 50 down to 1 (though there was 1 or 2 extra for redundancy, but these were idle for the most part). Best part yet it was written in a combination of Ruby and Java in the end, both memory management languages.

I can easily count the amount of times that teams of programers overs years were incapable of making a system efficient in C that I was effortless able to replace with memory managed languages that did the same task many of orders of magnitude faster. All while doing it in a fraction of the development time that the C programmers invested.

That said I can also count the number of times the reverse is true, that I used C to replace a memory managed language and was able to achieve an improvement in performance as well.

@lucifargundam

I'm not sure I'd use the word clever, unless your british as it would fit the way they use the word clever. But I would call them good things that you do.

@twotwenty

@matrix I can honestly say he managed to eliminate every single enemy he came across.

@lucifargundam

The one thing that will never surprise me is when people do stupid things... I am more surprised when they do something intelligent.

@twotwenty

@lucifargundam

Well remains to be seen if they did anything stupid.. Like if they actually stole the diary, then yea, they could face some real trouble I suppose. But they also could be innocent. Who know, the evidence isnt exactly public.

@twotwenty

@twotwenty Its not the truth im sorry for, im just sorry the pfizer CEO didnt get arrested, that sounds like it would be a fun turn of events to debate :)

@trinsec

Sure, but we arent talking about the wage, we are talking about the notion that you need to love your job.. im arguing most people dont, supermarkets or otherwise.

Also to be fair I've never seen lower wages than I did when I tried to work int he netherlands. They would offer me about 1/6th the wage I would get in america for my job.

@louisrcouture

@namark How many years did you spend coding Java exactly? It may be your experience being opposite comes down to the fact that you never gained sufficient experience with the language. While it takes less effort than C to get right, it does take an equal amount of understanding and experience.

For example your talking about spending too much time optimizing in a garbage collection language... if you have the need to optimize your memory management beyond the direct and expected ways of the language then you shouldnt be using that language, thats the point... **most** of the time you shouldnt need to optimize for memory in a convoluted way, the expected ways are more than sufficient and dont create bottlenecks. When that stops being true is when you should probably be at a lower level.

The notion that you only need to optimize memory in C in exceptional situations is far from reality. AS stated if you use it out of the box memory waste is **Extreme** in C.. for example apps like perl and ghostscript written in C that dont optimize the memory system beyond the out of the box use of malloc expiernce about 40% of their run time dealing with allocating and deallocating memory. The same app written in Java would have no where near that load even if no optimization on memory was done beyond the usual normal good practices.

Marginal slowdowns also dont just "add up", the problem is not that simple. If your memory system is 0.1% slower, for example, but your bottleneck is in the processor (and that bottleneck is not due to inefficiency but the difficult of the task itself) then that 0.1% or even a 10% slowdown in memory will have noe ffect on runtime at all since despite the memory access being slower it can complete before the processing queue is complete and thus never effects runtime.

The line of thinking your using usually leads people do to what is called "premature optimization" which has the counterintuitive effect of often **slowing down** your code rather than speeding it up by optimizing code that is not contributing to a bottleneck, and thus introducing more chances for human error in your code.

@trinsec Cartoons are way more educational than people give them credit for :)

@trinsec

I'm not sure calling it a temp job when it lasts for years is doing the conversation much justice. Most people will switch jobs every so many years through their life. Its rare a person sticks with one company for a life time. Do we call them all temp jobs just because they dont last until you die?

@louisrcouture

@namark A good example of this at play is actually the Aparapi app I wrote. It started as relatively pure Java, then the parts that made more sense as C were replace with JNI (basically C code integrated into Java). In the end the app uses C when memory management or low level control has an advantage, and Java where it serves no advantage.

Since it was written well there was no issue of "untangling", the boundaries were always clearly defined. Doing the whole thing in C from the get go would have been the wrong move just as doing it all in Java was the wrong move...

right tool for the job.

@namark Largely it depends. In practice you will find often, though not always, a memory managed system , when done properly, will outperform something like C out of the box (as discussed) and only be marginally slower when compared to C done "right" (as best as possible for the problem. It often is the case that the additional time it takes to code C correctly, combined with the fact that mistakes can lead to bugs not possible in a memory managed system, can often make the extra effort of C an argument that simply isnt compelling.

Its also important to note that memory management in languages like C and some others is not a simple matter of completely ignoring the issue and you still have a great deal of control through use of various types of controls over memory, namely: hard, soft, phantom, and weak memory. All of which can be ignored or used to whatever extent you need to.

So long story short, unless you need a very marginal improvement in memory, or are doing something special with memory at a low level, you probably wont get anywhere near the level of improvement with C that justifies the added effort you'd need.

As I said already, its all about the right tool for the job. Any mentality that things one language or approach to memory management is always superior is ultimately going to put you in a bad spot and waste many hours that need not be wasted by trying to use the wrong tool for the job. C is often the right tool, it is also often the wrong tool. Situational awareness is important to be a good programmer IMO.

@namark Yea I understand your (incorrect) opinion. It is perfectly possible to write good clean code that isnt spaghetti code in Java as it is possible in most languages. Simply saying a thing doesnt make it so. That said its also possible to write spaghetti code in any language, including C.

Like I said anyone who thinks their language is the only one possible to write good code in no matter the scenario is already behind the 8 ball.

@namark I never claimed it was relevant directly to what you original meant. Its relevance is that both are "things people complain about in C's memory management", that is all.

I am also not presenting Java's memory system as good anymore than I am saying C's memory management system is good. Both are different tools for different purposes and if you think either is the "end all and be all" of what represents a good language, then you are wrong in either case.

Java's memory management means really good performance out of the box. C's memory management is much slower out of the box but with significantly more upfront effort its performance can match or even exceed that of Java's. Therefore both server a purpose depending on your needs.

@namark thats exactly what i said, java slates its memory, thus faster than calling malloc on a per-oobject basis in C (which is often how its done, despite not being the proper approach).

As I already stated early to get the performance of java's new operation one would have to pre-slate memory in C. Certainly doable but often not done due to the extra effort when you get that out of the box for free.

My point is, memory handling in C is more tedious to make performant for many often leading to the effort not being made at all.

@namark no we arent talking spagehti code, nothing to do with that. We are literally talking about a single operation, memory allocation.. Java's new vs C's malloc, and java's new is substantially faster out of the box compared to C's malloc.

Show older
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.