this is what people say, it's not true ime. i have now rewritten simulation and hand evaluator programs two times, both in java and C++. in both cases, the speed was very similar, with java actually being a little bit faster. obv it depends on lots of factors, but this was enough to convince me never to care again and to bid farewell to C++ forever

this is the most adorable nerd origin story ever, and somehow the specific name "Neko" really sells it... i imagine a wide-eyed tiny child with a blond bowl cut

so i had these seagate HDs that failed and took them to local computer store where the guy recovered a bunch of data off them for me, mostly media files (TV shows and poker videos and such) with an .avi or .flv format.

anyway all the files and folder structure were recovered fine, and all the file sizes look like what they should be, but only like 20-30% of the files will actually play. when i open the other in VLC, the program just sits there for a few seconds and then does nothing. sometimes even within the same folder, some of the files play and others don't

my question is: are these just hopelessly lost, or is there some way i can make them play again? it's also weird because there are some xls files mixed into these directories, and they all work fine.

Do you have any kind of video editing software? They may be more robust in reading a corrupt file.

I'm working in this field and while I'm not going to say anything specific about what we use (I guess you could read our job listings...), development speed and turnaround time for new features is often even more important than speed of code execution.

no i've never done video editing. what do you recommend?

I'm pretty sure it has some validity. I doubt Google writes dalvik if Java performed that well.

i'm sure it does in some contexts, but since it doesn't in the contexts i care about i decided to say **** it

It depends on how much data is missing. If it is sequences of blocks missing from the file representing the unreadable parts of your old disk there may be some hope using VLC's repair (http://wiki.videolan.org/WindowsFAQ-...n_AVI_files.3F)

Link also lists some other tools.

Fair enough

A discussion similar to this one came up in another thread where the same performance arguments were made in c++ v. c# context. sngjason made the point that the ability to optimize code (for example using intrinsic functions or inline methods or even macros) in C++ is much greater than for C# (or java) and using them and along with for example intels compiler could give huge performance boosts.

Sorry, I'm in Macland, all I've used is iMovie.

Yeah, a C# or Java program can never be made to be as fast as one in C++... and for most non-trivial apps, its not even close.

Its not enough to just convert the syntax and compile the same code in both languages to have a valid comparison. Thats comparing compilers/RTEs, not languages.

The performance edge of C++ is many-fold... for starters, you get to rid yourself of performance sucking cruft like exception handling ... But the real advantage is that you can actually address the #1 performance bottleneck that any non-trivial program has on modern hardware: memory access.

On modern hardware, maximum performance happens when you exchange object-oriented design for data-oriented design. But you cant do that in a language that doesnt allow aligned memory allocation or access to SIMD instructions. Java and C# allow neither... and so from a performance point of view, are dead in the water.

Sadly my real name is much more mundane

My parents were pretty amazing about supporting my interest in programming. Completely unprompted, my mom bought me this:



for my 16th birthday . I only switched away from a yellow on blue color scheme in my editors a coouple of years ago

I spent a huge amount of time teaching myself to program using the three TP manuals that came with it (no internet!!!). Programming has never been as fun as it was then.

I got into programming late, but my bro started when he was like 8. I will never forget how much his face lit up when he made the computer count from 1-100 on DOS.

Does the JVM or CLR allow for memory allocation and can you somehow shut off garbage collection?

Do you think that concurrency is nothing more than a band-aid solution to this problem, or is it a legitimate idea that will help programs become faster?

What is your opinion of Naughty Dog? Was their decision to create GOAL a total waste of time or really cool hacking? I guess that's a two-fold question since they had to move over the C++ for PS3 because they couldn't communicate in Lisp with other dev houses.

Why isn't Lisp, which does have memory allocation (we don't use Lisp machines now), as fast as C? Is it because of automatic garbage collection, or is there something else?

Finally, as far as concurrency, wouldn't it be a good idea to create a concurrent programming language that goes directly to assembly language? I know that this probably isn't viable in today's world, but it seems like concurrent languages compiling to JVM or non-machine code isn't really tackling the whole problem, but of course, this is beyond my scope of understanding, so I'm probably completely wrong. I imagine it'd be very difficult to have programmers deal with memory management in a x-core platform. Imagine trying to distribute a program that runs equally well on one-core, 4-core, 6-core, and 8-core machines. What a train-wreck.

I used earlier versions of TP, including 1.0 when I was 16. Borland 3.1 was an amazing tool. 4 was a step backwards and sent me to MS VC++ 1.5.

** Bug Story **

Background
At too young an age and with too little experience, I was the sole author of a program that worked with a frame grabber for analog scanning electron microscopes. There were SEMs that pre-dated PCs, and their owners wanted to get the data onto computers. So you hook the analog output onto the frame grabber card (ISA, based on 8254s, no microprocessor). Then it was my job to get the data from the card into memory, onto the screen, the disk, and to a printer.

The target OS was standard mode windows (incredibly low latency btw). A typical machine of that day was a 386sx-16 with 4MB RAM.

The Bug

Quite simply, when capturing images from the SEM, OTHER PROGRAMS would crash occasionally and randomly. I tried blaming the other programs (standard programs), but the customer was convinced it was my fault. His "evidence" was the crashes happened if and only if my program was running.

The data flow: The ISA card would trigger an interrupt when it had data. An ISR written in C would read the data using inline assembly: "rep insb". There were 3 target buffers it would switch between. The upstairs code would take a buffer and display it, then find the next buffer. Repeat.

I did not have a kernel debugger and Borland couldn't debug an ISR. I got very stuck. The customer was not impressed (I was on site, 3000 miles from home). He asked what it would take to get unstuck: money? alcohol? drugs? girls? boys? He was willing to do anything.

This is pre-Internet, so being stuck was a problem. I had seen ads for Soft-ICE in my C Users Journal, so I tried ordering it ($386 I think). Soft-ICE was a kernel debugger that didn't require a monochrome monitor or a serial port to a second computer. Revolutionary.

In standard mode windows there were no page faults because there were no page tables. But when you allocated from the far heap you got a selector sized exactly to your needs. So going one byte beyond the end = auto-exception. I started running Soft-ICE to see if it could help.

Each crash was different. I had no source or symbols so I was looking at random assembly (and not knowing much assembly). I got a feel for what the crashes looked like, although I still had no clue.

Then I set a breakpoint in my ISR and went to assembly mode. I see something like this:

and the light bulb goes off. ESI was often involved in the crashes.

* I am using something like __declspec(interrupt) to tell Borland this is an ISR. That causes it to preserve / restore all registers.
* I am using a compiler option to target 386. This tells Borland it can use 32 bit registers. It does use 32 bit registers.
* The __declspec(interrupt) is only preserving 16 bit registers because 32 bits is new.
* So the hi word of ESI is corrupted by my ISR. Most programs only use 16 bit registers, so the crashes are intermittent.

I did my own 32 bit register push/pop and everything was fine. Bug solved.

It's crazy how much I learned on that project. Sink or swim is cool if you end up swimming.

I'm pretty sure you're out of luck in Java. In C# you can still write unmanaged code and allows you some access to actual pointers and such... but its really inconvenient.

Concurrent programming is where its at. As CPU clock speeds are quickly tapering off, the answer is more and more parallelism. More cores and wider registers.

I dont have any 1st hand experience with GOAL, but I have a friend who worked at Naughty Dog during the last of the "lisp years" and he always spoke very highly of it. From how it was described to me, it was particularly well suited to dealing with the challenges of developing on PS1/2 (which is something I do have 1st hand experience with): streaming and packing stuff in/out of a very small amount of RAM.

I think the main reason they didnt carry it on to PS3 development is that the guys who had created it in the first place had left the company. With them gone, I dont think anyone else really understood it well enough to want to gamble on moving it to the PS3.

Plus, there was a huge difference in the quality of the Sony development tools between the PS3 and PS2 and especially the PS1. So I dont think it felt like there was going to be as big a payoff by "going cowboy" with the dev tools. The state of PS1 tools was so weak, deciding to write your own compiler in a "non-standard" language was a little bit less of a stretch than it might seem today. (Dont get me wrong, I still think its jaw-dropping 31337 )

Even though the PS3's "cell" processor was pretty non-standard in a lot of ways... it was still based on PowerPC and had all the weight and experience of Motorola/IBM behind it... so there was going to be tons of good documentation (in English even!) and good compilers for sure. Working on the PS2 in the early days was like trying to develop for something you pulled out of a crashed UFO.

But I digress...


I dont think there's any real technical reason that stops Lisp, or any language that compiles down to native machine code, from being as fast as C. The real difference is that C compilers just have had so much more development effort behind them for so many years... they're very sophisticated at this point.

That said, it might be important to remember that C was developed to be a "slightly easier than assembly" way of programming. The C syntax was designed to enable the programmer to use the same design patterns as s/he would when using assembly. And given that processors today still have the same basic architecture of processors when C was first developed (stack-based, procedural), C-like languages might still have a kind of natural edge.

This is exactly whats happening already... OpenMP, OpenCL, CUDA, C++11... these all, in one way or another, have a focus on concurrency and they all compile to native machine code.

The difficulty of actually achieving a program that can scale across a multiple (and possibly variable) number of cores largely depends on problem at hand.

From my own experience, getting a program like SnG Solver to scale from 2 to 16 or even 1000 cores (on a GPU) has been relatively easy because the "work" is very homogeneous. Unlike say, Call of Duty on the PC. Even though the primary platform for CoD was the Xbox360 with its 3 cores, we pretty much hit a wall after 4 hyper-threaded cores. At the end of the day we were bottle-necked by the direct3d driver layer.

Oh, one more thing about the effectiveness of GOAL: I think the proof is pretty much in the pudding... those early Naughty Dog games were pretty much setting the bar for Playstation development. So if you ask me, I say time/money well spent.

fwiw, while i don't ultimately agree with the conclusion, i think this is a really well-written and well-reasoned argument for the benefits of C:

http://www-cs-students.stanford.edu/~blynn//c/ch01.html

EDIT: also, on sort of the same subject of simpler is better, i have recently discovered sinatra and find it infinitely more elegant than rails

I had a coworker who left to work in finance. I ran into him a couple of years later and they were using Java to write a trading application that needed to be really fast. He said that they'd eliminated GC by not creating objects. They'd even gone so far as rewriting some standard networking drivers that were creating objects.

I can't remember why they felt this was faster than using something like C++ but he was a pretty smart dude so I'm sure they weren't totally crazy.

Cool story Chips Ahoy. If I ran into a bug like that I wouldn't even know where to start

not creating objects and writing network drivers in Java?

sounds totally crazy to me.

was hoping to stay out of this but:

1. here's a talk i went to in 2010 from some guys doing very high volume, very high performance financial applications with java:

http://www.infoq.com/presentations/LMAX

i'll admit i haven't dug into their credentials and the talk was a bit over my head at times, but overall i think it's a pretty compelling argument for the "java can be plenty performant" side. (also it's a cool talk for other reasons: mechanical sympathy, their intersection vs traffic circle metaphor.)


2. i'm willing to believe there are applications where talking to the bare metal is faster than going through a jvm, but they are vanishingly few these days. basically, if you claim that your thing is too "hot" for java, the onus of proof is on you.


3. kyleb's comment about development speed dominating execution speed is spot on for the vast majority of applications.


3'. i'm surprised that sng_jason hasn't reached a similar conclusion about concurrent code. again, i'm far from an expert on massively multi-threaded development, but i think it's fair to say that it's a hard thing to do right. i would expect that trading a bit of performance for a lot of help from your language on not ****ing things up and not introducing crazy multi-threaded heisenbugs is worth a lot.

Haha heisenbug, love that name and it's so spot on with multi-threading stuff.

Gaming industry+finance isn't exactly huge compared to the bazillions of LOC in business software and so forth. Needing raw power is very often not required. If it is ... it's usually high payed and/or fun jobs though

I think you love it...

As interesting as that talk might be... there's nothing in it that suggests Java can perform as well as C++. He stresses the importance to writing "cache friendly code"... which is ironic because since Java has no aligned allocation or access to cache/branch control functions, you're already pretty hamstrung when it comes to following that very advice.

The system these guys have might perform very well compared to what is standard in that industry, but if they are bottlenecked on CPU performance, it could perform even better if written in C/C++. Thats a fact.

ORLY? Consider... Java has no access to SIMD instructions. This means that right from the start, your processing potential is 1/4th or 1/8th (SSE or AVX instruction sets, respectively) what it would be compared to using C++. This affects any app that does any image processing, video processing/encoding/decoding, audio processing/encoding/decoding, bulk string manipulation, cryptography, 2d/3d math, "number crunching" of any kind, etc.. etc.. etc..

I think you've got it backwards... the kind of apps that do this stuff is growing every day. Even "mobile" processors are sprouting SIMD instruction sets (e.g., ARM NEON) because people want to edit movies, do facial recognition, and play Forza on their phones.

No argument here... performance is not always the most important thing. Pick the right tool for the right job. I advocate Java/C# for projects all the time... but I was responding to comments specifically about comparing performance.

If you're working on UIs and database frontends, then of course, C# or Java are great choices.

If performance doesnt matter and you feel most productive writing in Logo and turtle graphics, then I say go for it.

Writing good concurrent code certainly is an extra challenge... but its a false dichotomy to say that either you pick a "safe" language or your code will end up in total chaos.