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.:-) Which family DSPs?
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
- push
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.
The 'view spec' thing is idiocy in its purest form. Consider the following case:
-You create a branch and a view that shows files in the branch on top of the trunk. -You edit file A. -Some other guy edits files A and B so that B won't work without the changes in A. -Your branched version blocks the other guy's changes in A so you have broken source code until you merge.
The same thing happens even if you are both on same branch. In that case, the explicitly checked out file blocks any changes to tip or tagged revision.
Now think what this becomes when there are lots of files and several branches / tags in the mix. Yes, ClearCase tracks every single file separately and does not have any atomic operations, which makes things very interesting.
With dynamic views, you see everyone else's changes immediately, which opens opportunities to all kinds of messes. Heck, if your software takes a while to compile, the source code can change a few times during the compile (remember, no atomic operations, so changes happen one file at a time). The dynamic view also needs constant access to server. The latest and greatest version I had to use just froze when the connection lost and crashed completely if the machine came back to net with different IP address.
Anyway, the service is quite new, and before this incident relatively unknown. At least I had never heard of it until this incident, and same applies to several people who discussed this on Helsingin Sanomat website (many of which noted they shall be using the service as text book prices are not reasonable for majority of students).
Interesting. At my university (TKK) used textbooks have been traded on the local news server at least since early 1990s. My first reaction was "Why would anybody pay to use a service that already has a better free alternative?". I guess the news are not part of internet.
An ex-coworker of mine went to work for a similar startup. I'm not sure if it was this company, but very similar. Anyway, I made the exactly same questions about latency and bandwidth everyone here makes. The answer was interesting.
This service was not even meant to compete with consoles and PCs. Instead, the real competition were those TV game shows where you play with text messages or calling the station and controlling the game with phone number keys. I, or no one of you, would never play one of those but there sure are a lot of people who do.
If they manage to stay in business until technology advances to the point where real games over internet are possible, they should be ahead of possible competition. The overall quality will still be well below local dedicated hardware, but tolerable enough for really casual gamers.
In Asian languages 234 is written as äOEç(TM)¾äåå, or literally translated: "[2][100][3][10][4]".
Well, it is also the way you read it and pretty straight forward to convert to and from Arabic numbers. On the other hand, European languages reading numbers tend to be more complex:
In English, that's "two hundred thirty four". "[2][100][3*][4] in your notation, pretty straight forward except for the "thirty". The literal translation from German is "two hundred one and thirty" or "[2][100][4][3*]", which is already a bit weird. And then there are all Latin derived languages that use some variation of the Roman system.
In Finnish, the reading of numbers has actually changed to resemble the way you described as Asian. The archaic way would translate to "two hundred four of the fourth". The old reading still remains for numbers 11-19, which are also exceptions in every other language I know.
The cool thing about RISC is that you do well without scoreboarding and, depending on the architecture, probably without branch prediction.
In typical RISC setups (i'm talking from experience with C55x and C64x DSPs, AFAIK ARM is pretty similar to the latter) the pipeline is well documented. It is the compiler's job to check for conflicts. No scoreboarding. Since the compiler optimizes code to this particular pipeline, there is no need for out of order execution either.
This also puts an interesting twist on branches: If the condition for branch can be calculated before the actual branching point, there may be code after the branch instruction that still gets executed before the actual branch takes place. This allows explicitly writing code that fully utilizes the pipeline even at branch.
C64x and ARM can have a predicate for every instruction. This means that every instruction may have a binary flag that tells if the instruction is to be actually executed. The value of the flag is checked after instruction decoding and other steps, exactly when the instruction is executed. So, a lot of branches for only few instructions can be replaced with predicated instructions.
Of course, these tricks need a lot of compiler support. Lack of it was one thing that killed the Itanium, but the TI DSPs and ARM seem to be doing well.
Things like PlayStation 3, XBOX 360 and such are running on RISC processors. I would guess that if CISC was really that superior to RISC, they would not have gone the RISC way when designing those custom processors. Actually, they could have just taken off-the-shelf x86 processors and enjoy all the research that has gone to them over the decades.
Actually, ATMs around here let you pull out the card during transaction. Unlike with voting machines, you can easily tell that the transaction failed by the fact that you have no cash.
And the usually unstated observation is that Finnish and most other European school systems have a much stronger tracking mechanism than U.S. schools--not in the sense of "knowing where the kids are," but in the sense of putting them into classes oriented towards universities or not, trade school or not, and such.
Speaking as a Finn, I call this utter bullshit.
The Finnish school system has similar classes for everyone for the first 9 years. The tests referred here are taken during these. After these, the kids have to choose between high school and vocational school. It not possible to have extra math classes for those who plan to go to high school and take so-called long mathematics.
The test results are as good as they are mainly because all the teaching effort goes to those who do most poorly. The fact that brighter kids don't do much better does not show up because the test is too easy.
For late bloomers, it is still possible take so-called 'evening high school' after vocational school while working or go to 'vocational university' which is where many go after high school anyway. For those unfortunate enough to take 'short maths' at high school, the science and engineering programs have quotas for them and special programs to teach the missing maths courses during the first year.
Also: Most of the software running telephone networks is written to work in environment where everyone else adheres to standards. This is possible because everything is audited and approved before use in live networks. In Internet this attitude would lead (and has led) to giant security holes.
Now if phones were left loose to mess with base stations, they could probably crash not only network cells but entire networks.
The company where I used to work still has legacy binaries for VAX, which is an extension to PDP-11. The actual machines are finally starting to break, but the software runs now on emulators. The VMS operating system is a big awful mess, but it was also the reason BSD was created. Guess which one our machines run...
Sure, but as I pointed out earlier in the thread, this is a flawed solution: if you ever change that code (or perhaps something it depends on), it might no longer be appropriate to suppress the Lint warning, but the comment won't go away by itself.
I don't think that changing the code itself is a problem - the lint warning suppression is a big red flag for everyone who is editing the code. A bigger problem is that the underlying data structure that cannot be accessed without questionable pointer arithmetic might change. Even then, it will be easier to grep for that particular warning suppression than for every use of the data type.
The problem with Windows at my workplace is that it comes pre-crippled with Tivoli Endpoint, mandatory anti-virus and various other pieces of adminware. If even some of these were not available for Mac, that would be a good reason to switch. Of course, that would also prevent the change, but one can always dream...
Well, Nokia Networks (now Nokia Siemens Networks) has TNSDL, which is a kludgy home-brew thing. It has not prevented them making things with some nines uptime.
There is some kind of ported standard C library, but it is both lacking and buggy. Also, when using the C library, there are only two symptoms when something goes wrong: either the application crashes or the entire phone crashes. If the software runs differently on PC emulator and the phone, you're pretty much out of luck. Standard C++ is of course a dream far away. Ported STL exists but it has its own set of troubles.
Slashdot Mirror
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. :-) Which family DSPs?
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
- push
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.
The 'view spec' thing is idiocy in its purest form. Consider the following case:
-You create a branch and a view that shows files in the branch on top of the trunk.
-You edit file A.
-Some other guy edits files A and B so that B won't work without the changes in A.
-Your branched version blocks the other guy's changes in A so you have broken source code until you merge.
The same thing happens even if you are both on same branch. In that case, the explicitly checked out file blocks any changes to tip or tagged revision.
Now think what this becomes when there are lots of files and several branches / tags in the mix. Yes, ClearCase tracks every single file separately and does not have any atomic operations, which makes things very interesting.
With dynamic views, you see everyone else's changes immediately, which opens opportunities to all kinds of messes. Heck, if your software takes a while to compile, the source code can change a few times during the compile (remember, no atomic operations, so changes happen one file at a time). The dynamic view also needs constant access to server. The latest and greatest version I had to use just froze when the connection lost and crashed completely if the machine came back to net with different IP address.
Anyway, the service is quite new, and before this incident relatively unknown. At least I had never heard of it until this incident, and same applies to several people who discussed this on Helsingin Sanomat website (many of which noted they shall be using the service as text book prices are not reasonable for majority of students).
Interesting. At my university (TKK) used textbooks have been traded on the local news server at least since early 1990s. My first reaction was "Why would anybody pay to use a service that already has a better free alternative?". I guess the news are not part of internet.
An ex-coworker of mine went to work for a similar startup. I'm not sure if it was this company, but very similar. Anyway, I made the exactly same questions about latency and bandwidth everyone here makes. The answer was interesting.
This service was not even meant to compete with consoles and PCs. Instead, the real competition were those TV game shows where you play with text messages or calling the station and controlling the game with phone number keys. I, or no one of you, would never play one of those but there sure are a lot of people who do.
If they manage to stay in business until technology advances to the point where real games over internet are possible, they should be ahead of possible competition. The overall quality will still be well below local dedicated hardware, but tolerable enough for really casual gamers.
I'm still not sure this will fly, though.
In Asian languages 234 is written as äOEç(TM)¾äåå, or literally translated: "[2][100][3][10][4]".
Well, it is also the way you read it and pretty straight forward to convert to and from Arabic numbers. On the other hand, European languages reading numbers tend to be more complex:
In English, that's "two hundred thirty four". "[2][100][3*][4] in your notation, pretty straight forward except for the "thirty". The literal translation from German is "two hundred one and thirty" or "[2][100][4][3*]", which is already a bit weird. And then there are all Latin derived languages that use some variation of the Roman system.
In Finnish, the reading of numbers has actually changed to resemble the way you described as Asian. The archaic way would translate to "two hundred four of the fourth". The old reading still remains for numbers 11-19, which are also exceptions in every other language I know.
Java has final references. Just set one in the constructor, and it is guaranteed to never change.
It is annoying, though, that every small member object carries its own memory allocation and garbage collection overhead.
The cool thing about RISC is that you do well without scoreboarding and, depending on the architecture, probably without branch prediction.
In typical RISC setups (i'm talking from experience with C55x and C64x DSPs, AFAIK ARM is pretty similar to the latter) the pipeline is well documented. It is the compiler's job to check for conflicts. No scoreboarding. Since the compiler optimizes code to this particular pipeline, there is no need for out of order execution either.
This also puts an interesting twist on branches: If the condition for branch can be calculated before the actual branching point, there may be code after the branch instruction that still gets executed before the actual branch takes place. This allows explicitly writing code that fully utilizes the pipeline even at branch.
C64x and ARM can have a predicate for every instruction. This means that every instruction may have a binary flag that tells if the instruction is to be actually executed. The value of the flag is checked after instruction decoding and other steps, exactly when the instruction is executed. So, a lot of branches for only few instructions can be replaced with predicated instructions.
Of course, these tricks need a lot of compiler support. Lack of it was one thing that killed the Itanium, but the TI DSPs and ARM seem to be doing well.
Things like PlayStation 3, XBOX 360 and such are running on RISC processors. I would guess that if CISC was really that superior to RISC, they would not have gone the RISC way when designing those custom processors. Actually, they could have just taken off-the-shelf x86 processors and enjoy all the research that has gone to them over the decades.
Actually, ATMs around here let you pull out the card during transaction. Unlike with voting machines, you can easily tell that the transaction failed by the fact that you have no cash.
(Disclaimer: I'm no scientist. Well, a computer scientist. But that doesn't apply here.)
Don't you mean "Damn it, I'm a computer scientist, not a doctor"?
I guess he has PhD in Computer Science.
And the usually unstated observation is that Finnish and most other European school systems have a much stronger tracking mechanism than U.S. schools--not in the sense of "knowing where the kids are," but in the sense of putting them into classes oriented towards universities or not, trade school or not, and such.
Speaking as a Finn, I call this utter bullshit.
The Finnish school system has similar classes for everyone for the first 9 years. The tests referred here are taken during these. After these, the kids have to choose between high school and vocational school. It not possible to have extra math classes for those who plan to go to high school and take so-called long mathematics.
The test results are as good as they are mainly because all the teaching effort goes to those who do most poorly. The fact that brighter kids don't do much better does not show up because the test is too easy.
For late bloomers, it is still possible take so-called 'evening high school' after vocational school while working or go to 'vocational university' which is where many go after high school anyway. For those unfortunate enough to take 'short maths' at high school, the science and engineering programs have quotas for them and special programs to teach the missing maths courses during the first year.
Also: Most of the software running telephone networks is written to work in environment where everyone else adheres to standards. This is possible because everything is audited and approved before use in live networks. In Internet this attitude would lead (and has led) to giant security holes.
Now if phones were left loose to mess with base stations, they could probably crash not only network cells but entire networks.
The company where I used to work still has legacy binaries for VAX, which is an extension to PDP-11. The actual machines are finally starting to break, but the software runs now on emulators. The VMS operating system is a big awful mess, but it was also the reason BSD was created. Guess which one our machines run...
Sure, but as I pointed out earlier in the thread, this is a flawed solution: if you ever change that code (or perhaps something it depends on), it might no longer be appropriate to suppress the Lint warning, but the comment won't go away by itself.
I don't think that changing the code itself is a problem - the lint warning suppression is a big red flag for everyone who is editing the code. A bigger problem is that the underlying data structure that cannot be accessed without questionable pointer arithmetic might change. Even then, it will be easier to grep for that particular warning suppression than for every use of the data type.With PC-lint, it is this easy to disable a warning for just one line:
//lint !e416 "Potential buffer overflow". I know what I am doing here
x = *(p + 10);
The problem with Windows at my workplace is that it comes pre-crippled with Tivoli Endpoint, mandatory anti-virus and various other pieces of adminware. If even some of these were not available for Mac, that would be a good reason to switch. Of course, that would also prevent the change, but one can always dream...
Well, Nokia Networks (now Nokia Siemens Networks) has TNSDL, which is a kludgy home-brew thing. It has not prevented them making things with some nines uptime.
I would be surprised, too, if they chose Python. Lightroom is already 40% Lua.
Basically, Symbian makes everything hard.
There is some kind of ported standard C library, but it is both lacking and buggy. Also, when using the C library, there are only two symptoms when something goes wrong: either the application crashes or the entire phone crashes. If the software runs differently on PC emulator and the phone, you're pretty much out of luck. Standard C++ is of course a dream far away. Ported STL exists but it has its own set of troubles.