NerdsCentral

He did not actually say that - but it is the implication of his comment.

Agile focuses very hard on the short term. Hopes and dreams are not short term. Agile is a way to implement innovation but it will not create it. My experience is that the shorter the stories are then the less innovative the code becomes. The really cool stuff gets done at nights and weekends.

But was it not ever so?

Good arguments. I based 1kw on the 800 watt rating of the machine mentioned plus a/c etc. It is all ball park and I am a bit shocked you are the only person to call me out. But it does not matter because if you 1 tonne per year - it is still plenty. The car thing is a good point to make but I think you are stretching it with the telecommuting. This is especially so as the key to telecommuting if fast software (ever tried implementing video streaming in an interpreted language?) The amortized over many people point correct but not valid to the argument as it is a multiplicative not additive effect it has as no impact on the over all calculation.

Not sure of the connection here. BTW - check out the nerds-central post on why Thorium matters if you are pro-nuclear - it might have some good amo for you to use.

OK, I'll explain this as you clearly have no idea what you are talking about. When one commissions a server or server farm it is done against a service non functional requirement. For example 1 second page serve time at peak load. This means that a lot of the time the servers might be waiting but not a peak load. Never the less, modern servers will clock down if waiting. Now, what sets the peak load is the efficiency of the software and the number of people using the server and/or the run length of the batch jobs. The more efficient the software the less servers are required to meet the peak load and so the less power is used all the time. Further, the more efficient the software the less often servers will have to clock up during off peak times. Do you finally get it? If not - I suspect you have zero idea about large scale computing and are here only to defend your lack of ability to program anything other than scripts.

The post is talking about servers. Most scripting is for code running on servers. Servers do not wait for the user. Your comment has zero merit.

Yes - I said that some time ago.. http://nerds-central.blogspot.co.uk/2007/06/why-flash-is-per... and http://nerds-central.blogspot.co.uk/2010/05/steve-jobs-agree...

Most real scientific computing (quantum mechanics - in which I did my doctorate, meteorology, astrophysics etc.) is done in C or more normally FORTRAN. The code will use highly optimised routines like BLAS. It is normal to perform careful inner loop optimizations for each target platform.

Don't talk about things you don't understand.

Unfortunately - right now - we do not have unlimited energy. If we did - then the argument simply shifts to the limited mineral resources we have to make the computers...

I was not expecting this to produce so much interest. I guess a lot of people have asked about how to implement try/catch/finally in C++.

Wow - how did it get that badly screwed up? Thanks for pointing that out.

Thanks for upvoting!

Hi Scott,

I think I am reacting to the arrogance in the language. "This is how research works." is what you said. That is quite presumptuousness of you to say that because your language naturally suggests you are telling me something I don't already know. This is the case with this comment thread in general.

It could be cultural. In the UK, the way you and the other people on this particular comment thread frame words is really quite rude. I don't know where you are from so I cannot comment as it if you would know that or not.

If one were to say "Surely, this is how research works." then on offence would be taken. Or "As I am sure you know, this is how research works." But no, the words immediately speak to an assumption of ignorance on my part. That is offensive and I take offence.

I suspect also that news groups are easy places for people to make such mistakes. I have no idea how you think of me when typing. Do you imagine a 40 something doctor of computational quantum-mechanics trying to squeeze out a quick post before starting a day's work on the parser for a compiler for his client? Maybe you see a spotty teenager trying to wade beyond his depth?

I don't know you and you don't know me and so I suspect a little more automatic respect on both parts would not hurt.

Best wishes - AJ

Actually, it is relevant that I was researching something else. I have published papers on research; in that process one crosses all the ts etc. In this case I am saying - here it is - if you are interested you can run with it. That is very different and so I think it is quite reasonable to expect constructive rather than negative criticism.

As for the G1, I have chosen to continue and look at the issue in more detail. So far, it would appear that I cannot find a situation where it offers a benefit over other collectors. However, I am happy to accept that there might be one out there. I will switch over to the Popper approach and attempt to disprove that the G1 performs badly. If I get conclusive result either way - I will report on it.

I know - I think the post makes that clear. I explained the purpose of the whole thing an earlier reply. But Oracle and IBM have realtime implementations of the JVM I believe, though I am more familiar with the Oracle one.

Totally agree. My original aim was to use an idea I had about the way the garbage collector synchronises in the Oracle JVM to give 'windows' of determinism. So I set about making a program to push the gc really hard so I could see if my idea worked. But I have not gotten as far as the original aim yet because I found this interesting stuff about the G1 collector.

As for your points about realtime - I am completely with you. I had in my mind that one might have a realtime system on the rtjvm or in c++ which needed to periodically communicate with a standard JVM. There are three approaches I could see for this. One, would be to send messages and decouple that way. Another is to make the communication abort if it looked like it might cause a deadline miss. The third was to briefly (milliseconds) disable the gc in the standard JVM so the communication could occur and then turn it back on again immediately afterwards.

Now - that sounds like a really bad idea and it probably is - but it is an interesting idea to play with.

So - please don't thing I am proposing realtime programming on the standard JVM, just some ideas for larger systems integration.

My point is that I never said the GC was bad. I said I showed up issue with it. As I explained in detail in my post - I was actually researching something else. BTW I did experiment with 2 other garbage collectors - the default and the incremental and gave results for all three, which I think is quite thorough given that I was actually researching something else.

I would be just great if someone who is coming at what I am saying with description of the weakness would give a suggestion rather than just shoot down the finding which I never said was anything other than just a finding.

OK - I'll see if I can get time.

Oh - also - whilst I get that the G1 is not designed for maximum throughput - note that it has longer maximum pause as well. I did mention this in the post. So, for this situation, it fails in both regards. Now, whilst this is a benchmark and not a real world system, it is cause for some concern that the G1 collector is slowing down code execution so very much.

I hope that the article does not imply that it is conclusive but rather that it is cause for concern. The flags were only those required to set the garbage collector - everything else is default. If you want to try other settings, the code is there to use :)

I go with reading the manual. That is how I learned Fortran back in the day. I learned PHP by reading the php website. PHP for me was just Perl will all the logic ripped out and replaced with words.

I am not sure reading the manual is a good way if you don't already know a language.