But it's not really that relevant, because even if the execution speed is 10:1 in favor of one language, language execution speed is only one of the bottlenecks. They'll be spending a fair amount of time outside of the language, executing the same APIs. There's network speed, disk access, shared libraries... a 10:1 difference might not be that significant when only 10% of the time is spent actually executing the program.
The point here is not to run the code faster. It is to use 10% of the original CPU power to run the code in the same time. Which leads to savings in hardware costs, electricity, air conditioning, even floor space. Of course, this is only the PHP frontend part and does not affect the database backend, but still I hear that the PHP frontend takes some significant processing power.
Allowing judges to use common sense is not really different from allowing them make arbitrary decisions based on their gut feeling, prejudice, bribes, etc.
Hmmm... I get the sinking feeling I work for that vendor.
TI C55x and C64x. The IDE - or our build process for that matter - didn't really support multiple targets. I guess multiplatform DSP code isn't that common out there.
FWIW, I don't use our GUI either except for loading stuff on silicon. Most of the time though, I'm working with the processor about a year or more before there's silicon, so that means I'm doing everything under Linux with make and the command-line compiler anyway.
Lucky you. The Linux tools were nice and blazingly fast compared to Windows ones.
Only one of these guys said anything about not liking to use an IDE. I use IDEs to write assembler language for microcontrollers at work every day. Sure I could do it in an editor as well but I much prefer the graphical debugger and simulator of my IDEs as being able to see all the dozens control registers' and fuses' bits graphically during the execution of each instruction is easier for my mind to wrap itself around than my screen littered in hex or ones and zeros, at least sometimes.
I used to write very low level C and assembly for two different DSP processors for a living, too. We used the vendor's joke of an IDE for debugging and only debugging. Everything else was better* with external editor (Emacs or UltraEdit depending on developer's taste, I don't think anyone used vi) and command line. I hear that the vendor has since then abandoned their home-brew IDE and maintains a fork of Eclipse instead.
* When I say "everything was better" I mean that everything still sucked pretty badly. Could have been improved, though, if anyone would have cared and had some time to redo the build process.
My current phone is a Nokia (E71), and it's bloody annoying. What they deserve is a kick up the arse.
E71 has Avkon and Symbian. They are pretty impossible to develop for, and it shows in the end result. There is a reason they are switching to Qt, Linux and Python.
By the way: One of the nice things about Clearcase is that, if you do make that error and get bit, you can fix your view AFTERWARD by editing one line in the view spec to back up the trunk view to a moment BEFORE the other guy checked in A and B.
A Clearcase-specific way to fix a problem that exists only in Clearcase. A sane system would allow checking out the previous revision, which has been checked in as one changeset.
As I recall the Clearcase make understands that the actual source changed even if its time went BACKWARD and gets the dependencies right. (Try THAT with other version control systems.)
Moving file dates backwards is a bug, not a feature. As is getting married to a slightly nonstandard version of a primitive build tool. Anyway, at least SCons manages to compile things right, as it uses MD5 sums to detect changes and cache objects.
Part of the POINT of diverge-converge is that you see NOBODY'S CHANGES BUT YOUR OWN until you have your part working and are ready to merge or you find you MUST incorporate somebody else's fix to get your stuff working.
Wow, that was complex and error-prone. It is also exactly what distributed systems do easily. Heck, SVN can do that if you accept a worse merge support. For comparison, in any sane VCS you
- create a branch
- do your stuff
- pull changes from trunk
Everything that you do with view specs happens automatically. No tricks with tags or dates (not that they work in CC, which still lacks atomic operations).
If you really want an expensive enterprise VCS that does what you describe, you should have a look at Synergy.
"Ahead warp factor 1" - Captain Kirk