Someone in university should do a doctorate thesis of that.
Someone in university should do a doctorate thesis of that.
In fact, Phoronix is very lenient with that, on many other forums you would have been banned for calling him a fat ass, mental insane, parasitic, for disrespecting anyone you answer to with calling them son or junior (you can save yourself to the time to type son or junior if you answer me, I am most likely older than you), even if they ask you not to do that because it is in fact disrespectful, and clearly shows that you have to boost your ego to feel superior to anyone else here, which is quite funny, since you know no one here personally.
You have to heighten yourself above people you don't even know, which is really sad and says much more about you than you think.
That is what you said, right there. So STFU about 'censorship' already when you have zero problems with 'censorship'.Nobody but you is talking about the GPL here.
Besides that, after your pathetic and criminal outburst (accusing the OpenBSD people to be the Boston bombers) I am surprised that you are still allowed to post on this forum.
Ie. you people on Phoronix are sellout pieces of shit trying to 'hide' behind legalese to justify toxic, fraudulent behavior. Thanks for confirming that. I will now try to steer clear of Larabel's site as much as I can since the behavior and ideology of the people on this site is toxic shit.That behavior is allowed by the licenses, it is just you not liking that behavior.
Pathetic little MBA conmen living in Europe/America that 'think' they will become the next 'big startup' by making games with pathetic graphics and even more pathetic gameplay AND (here is the key) GETTING RICH OFF RIPPING OFF GPL'ED GAME ENGINES WHOLESALE. Dude - hate to break it to you - but the entire lot of you will be facing foreclosure within two years after the bubble has burst on your 'indie' asses.
You are either a sellout or you are not - you are either a disgusting maggot piece of shit or you are not. And you lot that think 'the license allows the behavior' are just that - maggot pieces of shit. Kindly fuck off and get your ass out of the 'software engineering' industry already so the world can be a better place for all of us - you have no morals, no integrity, no backbone, no nothing - and you should get out and get lost .
Read the above you hypocritical dipshit where you are CALLING FOR SOMEBODY TO BE BANNED because he says things you don't appreciate. Egg in your face there.I doubt that we should censor anyone just because he does things you don't appreciate.
Selective reading much?He does not tell lies about you, no slander, so a ban would simply be not legitimate.
Dude, other people said far worse stuff here on this thread, so stop with the 'selective interpretation' already. So far I didn't tell anybody to 'die' - which a couple of the buttbuddies you support did. So much for others being 'respectful' - you reap what you sow.In fact, Phoronix is very lenient with that, on many other forums you would have been banned for calling him a fat ass, mental insane, parasitic, for disrespecting anyone you answer to with calling them son or junior (you can save yourself to the time to type son or junior if you answer me, I am most likely older than you),
Last edited by Squarepusher; 04-23-2013 at 12:23 PM.
Your comment is civil but I completely disagree.
I used to do a ton of work on production apps doing high performance concurrent programming in C++: first threads are typically *way* slower than asynchronous programming. On C++/Windows, I used what Microsoft called IOCP (completion ports). On *nix/C++ the TCP select api has async logic. I saw dramatic performance increases going from threads to async. We ultimately did use threads, but just one thread per CPU core. The primary concurrency mechanism was async logic.
Java has the netty library for async development. Scala has much more elegant syntax for async development.
See multi-language high performance server benchmarks here:
I don't think GC is a problem for server or high performance concurrent programming. Google writes much of their services in Java, and they are known for super responsive server apps.
I'm skeptical that GC is a problem in games. Even if it were a problem, you can remove or minimize any memory allocations that happen in your inner render loop. Java games like Wakfu seem to be completely responsive and performant.
I was comfortable with manual memory allocation in C++. GC isn't one of the important features to me in Java/Scala.
It's also because in your deluded mind, you think that the second core will just 'mask away' those millisecond pummelings and that therefore nothing is inherently bad about it. This will never, ever, ever be the case on Android - stop deluding yourself and face 'reality' - the current-day reality is that ,NO, the second core DOES NOT PICK UP THE SLACK - your framerate STILL gets pummeled.
if you still deny that, go inform those Ouya 'devs' on that forum about how the 'millisecond upon millisecond upon milliseconds' delays they are experiencing are not 'really real' and that 'they are just using Java wrong'. You are totally deluded if you think this is not an 'issue'. Go back to your enterprise job where you might actually have a chance in hell to know what you are talking about.
Wakfu is an insignificant overhead 2D bitmap strategy game that could have been done on a PS2 technically (or even lower). You might as well hold up Quake 2 while you're at it again as a great posterboy for 'Java'.Even if it were a problem, you can remove or minimize any memory allocations that happen in your inner render loop. Java games like Wakfu seem to be completely responsive and performant.
Minecraft, Wakfu, a run-off-the-mill Quake 2 port - some great 'posterchilds' you have for your 'toy language'.
GC is a total non-issue with C++11. While technically it is possible to do GC-style 'cleanup' in C++11, nobody needs or wants GC at all nor is it a 'feature' anybody should be proud of having in a language. It is mostly there in Java for inferior programmers who don't want to do it 'the right way'. It is not something anybody should be trumpeting.I was comfortable with manual memory allocation in C++. GC isn't one of the important features to me in Java/Scala.
Last edited by Squarepusher; 04-23-2013 at 12:59 PM.
Why do you only care about the code? If by using a few open source libraries in my program I end up curing cancer you would still call me a parasite if I do not open source my code. You choose to ignore everything except the code. As long as the code is open it doesn't matter.
And by the way you said that first person shooters are murder simulators and that the people will pay the price for playing these games. Well does RetroArch enable people to play shooters like Doom? Yes it does. So you enable people to do bad stuff for society with your software. You sure seem a good person by your own standards. And don't start with the freedom bullshit. You're not the kind of guy to think live and let live. Not by a long shot. You're just a hypocrite.
But what if in the next version things improve all the while I don't have to do anything and the framerate improves? What if they do move the GC to other core without me doing anything. I was just looking at Blackberry in order to port my game to their platform. Guess what? If it's written in Java I just need to repackage my application in their .bar format all the while people that use the NDK thus C++ are in a world of pain if they want to move their application from Android to Blackberry because there is no easy way to do so. So apparently there are advantages to use Java. Plus moving my application from Android to PC also is pretty easy (just need to add controls for mouse and keyboard).It's also because in your deluded mind, you think that the second core will just 'mask away' those millisecond pummelings and that therefore nothing is inherently bad about it. This will never, ever, ever be the case on Android - stop deluding yourself and face 'reality' - the current-day reality is that ,NO, the second core DOES NOT PICK UP THE SLACK - your framerate STILL gets pummeled.
And yes just as I said I will continue to infect others systems on metastasize everywhere. Coming to Blackberry soon Mwhahahahaha!
This most probably is a bug in Ouya that will be ironed out before final release or as a patch. You attribute a bug to a programming language. Those issues aren't because of Java.if you still deny that, go inform those Ouya 'devs' on that forum about how the 'millisecond upon millisecond upon milliseconds' delays they are experiencing are not 'really real' and that 'they are just using Java wrong'. You are totally deluded if you think this is not an 'issue'. Go back to your enterprise job where you might actually have a chance in hell to know what you are talking about.
The server I was working on was initially written back ending microsoft's terraserver for extracting, mosaicking and reprojecting ortho mosaics on the fly. Not your typical high transaction database type website. At this level async, thread overhead is totally irrelevant, the code path, memory allocation and management, socket cross talk becomes significant. That was back in the days of java7 so that's why I'm not going to argue much about the merits of those languages. Current high performance work is for multisensor digital payloads including digital cameras, lidar, etc. Sensor internal and external calibration, geometric trajectory correction etc, least squares systems, radiometric correction, on and on. Some of my work involves aggressive paging and in memory compression so I don't blow out 128GB ram.
My partner a year or so ago did some work transferring technology to another party and worked some with c#. His experience was that simple semi low level operations using matrices, etc were close with c++. But when he started chaining things together to do something useful with these low level operations the difference in performance started to heavily favor the c++ side. And the equation formulation, readabilty, etc was worse with c#, not to mention VM overhead and memory use. I'm not sure about java today but I know c# treats "stack" classes different form "heap" classes and that caused untold amounts of grief for him as well.
It took me one day to port RetroArch to Blackberry - note - as a 'native app' - look ma - no Java - no 'Android NDK app' running on Blackberry.
So if your codebase is non-shit it is as easy as 1 day or even a few hours.
This is why you stick your codebase to C99/C++98 whenever possible (note - you make it compilable as C++98 as well so that MS' compilers get a piece of the action as well - and fall back on C99 for everything else) - so your codebase is easy as hell to port to anything under the sun. You don't have to rely on 'Blackberry' to 'implement' some Dalvik VM in a jailcell - you can just 'port as-is' with optimum performance instead of having to run your app in a non-optimal VM.
You are simply 'doing it wrong' and 'doing it inoptimally' if you think you need Java to write 'portable code'.
Last edited by Squarepusher; 04-23-2013 at 01:25 PM.