It does not cost them anything to pre-install Linux in the first place, any more than tweaking a copy to run on each model they have, which is not the worlds hardest job. Roll out and copy, that is it. And no need to pay royalties to MS. The decision was probably made as a result of suits taking a meeting with another group of suits that told their "friends" that their product is superior in every way and there is absolutely no reason to even consider Linux. This is the way of recent ISO-votes and it works. All you need is too much power.
Not every disappointment is a result of a Grand Microsoft Conspiracy, but this one is, and most others that are mentioned in context are too. We are not talking about Mars Polar Lander failure.
This is at least OS-specific. Crashing implying a segmentation fault WILL cause Windows NT kernel to abort the process that owns the thread and clean up the mess. You may however trap the segfaul exception signal and thus prevent the process from being bailed out by the OS.
The most common crash scenario on Windows is when the single thread that is part of any process misbehaves by accessing memory it does not have right to access, the CPU signals a segfault, Windows kernel catches the uncaught exception and decides, for the lack of capability and capacity to salvage a corrupt process, to "eject" it - aborting the process, freeing up memory, and restoring the system the best it can. So whatever you wrote in your post above, does not apply at least to Windows NT derivatives. I am pretty sure it is a pretty common default scenario action and reaction in Linux too.
The whole thing crashes because pretty much nobody can be bothered to process the exceptions that rise and cause the OS to abort the process and clean up the mess. But when we were kids we did learn to clean up our own mess, and not let our parents or computer operating systems slave for us. Jokes aside, if your thread screws up, the process should tidy up, and not let the OS remove the process altogether.
Then again, it is something that is not achievable today, and few if any programmers think about salvaging the processes they design. So you are essentially on spot here.
So, basically it comes down to WHAT you use threads for. Obviously, using threads to process tab page content wont speed up your 600-post Slashdot discussion, because only a single thread will be doing the job. Or a process with a single thread. Threads are not magic, but I am sure you know that.
There are multiple ways to optimize such scenarios with threads. There are multipple ways to optimize multi-page browsers too, with the one-process/thread-per-tab/page being the most known obviously.
Alternatively, you might want to use a single process, and dedicate one thread for page rendering, another for plugins (including updating all those pesky Flash animations for those who dont use NoScript/AdBlock+), and another for JavaScript processing.
My point is there are many ways to use processes and threads, and dedicating execution threads on a per-page/tab basis is just one of them, and I am not sure it is the wisest. Microsoft recommends themselves that any process uses 2 x CPU_core_count threads, and even though they are sometimes coming up with pretty weird recommendations, it is still a hardware bound feature, and too many threads, especially if waiting on locks of diff. kinds will have the OS spend more time on the whole thread scheduling than doing useful work for the user. I am sure Intel would NOT recommend either to load more than 6-8 threads in a GUI application process. Sometimes the whole threading can be "emulated" with benefits in speed and resource usage by faking it all. The way overlapping I/O is done f.e.
I did create a TCP/IP server once, creating a thread for every client connection it receives, and I noticed client would be waiting for the server OS scheduling their connection threads, so that they could receive some data already after 10 threads. That was on P4 NetBurst arch back in 2004, but I doubt the picture is much better now.
You do pick on details. Its all in details they say, yet you pick on something that does not make the point of my post. Which is, maybe an apartment building does not have ANY effect on general good-feeling of the inhabitants, and in fact may suit just fine and support them emotionally and whatever. But when you build a pyramid for over a million people with a base of one square kilometer (sounds much? It is not.), there better be some god damn good ergonomics inside it, because it is VERY difficult to provide good emotional conditions for living to a million people inside a pyramid. Not to mention the latter in a city already struggling with fresh-water and sanitary issues, it just does not make any sense.
There is a reason most big companies distribute their working offices over different areas, instead of building a single biggest building they possibly can and putting everyone over there. And no matter how many Bonsai trees and pictures of their family workers put on their desk, regardless of the architects best wishes, it don't feel like home. Similarly, this pyramid will fall hard on its face (pun intended) trying to be true home for every single person it houses.
Good informative post. Crossing fingers for your safety,)
However, did you take a trip to the Wikipedia article on Palm Islands? It seems the project is well on track as of August'08. Is the article hijacked, in your opinion?
For starters, have you heard of a building that housed over a million inhabitants?
It is different by a factor of 1000 roughly:
Average modern apartment skyscraper - ~1000 inhabitants. Architect ego - moderate.
Ziggurat - ~1100000 inhabitants. Architect ego - Uncharted beyond the 'Unusually high' mark on the ego scale.
Surely it might suit some folks, who have nothing against being 'slotted'. But on average, I d estimate that factor of 1000 to also apply to the level of happyness of such inhabitants (negatively).
People rebel against too much machinery. You don't have to be a psychologist or alike to notice that. They have problems already when you try to put everyone on the same floor into exactly the same type of living compound, assuming them to also be exactly the same. This is what the communist dream was like at the top of their game, before it started to rot. Capitalism may have its inherent flaws, but it in no way criticizes people that decide to build their own house by the sea, which is perfectly humane.
Yeah, in fact someone should design a computer game with this in mind.
" You are a privileged citizen of a unique upperclass society in Dubai, settled in a pyramide like housing structure of large proportions that you share with over a million immediate neighbours. And it was all like a dream on Earth... Until, one day the unthinkable happened. Noone knows what exactly did happen, but the life support systems failed with no warning, and people started to disappear... Someone reported of strange incidents involvind the paranormal. But you do not believe such rumours, do you? It is up to you however to now start discovering what exactly HAS happened and save what is left! "
Only in Dubai. Big deal - an eco-friendly pet project of a bunch of select few oil billionaires of the Mideast that can afford to spend their cheap dollars on something extravagant and exclusive and trendy like this. It maybe eco-friendly, but I seriously doubt it is even in remote proximity to cheap.
So, no point of paying too much attention, before this comes to the poor rural communities scattered all over the world for a price affordable to someone in say New Orleans and Russia.
Even a child should know that everything has a beginning and an end. Empire like Google starts to eat its own self with time, and collapses under its own weight. This is part of life, and Rome and a lot of other attempts to be larger than life went this way. And the more one is trying to fight this tendency the more weight it carries, and the harder is the fall. What do you expect, Google to stay on top forever? This only happens in fairy tales. The reality has something to do with particle physics, I am sure:-)
By ways of natural (and unnatural) selection, no Joe Schmo will have both hundreds acres of land, hundreds of construction workers and engineers, a lot of raw materials and be able to orchestrate it all. One out of four - perhaps, with a lot of tough luck, but not all at the same time. Even in the U.S. of A.
If you are a software developer yourself, try to set up proper division yourself by talking to appropriate people in positions.
If not, stick to biotech. Software developing is engineering too, and it is not a good idea to do amateur in-house engineering, especially if your software products need to be of mission-critical kind. Outsource all software related job(s) to someone else who specializes in software design and development, and you yourself will sleep better.
Yes, in that case there is potential (through evolving NGEN) for C# to yield what is called native code, which may or may not be as fast as any other machine code. Machine code differs too from one program to another, so the weight falls on the pieces of sofware that generate such code - the C compiler and NGEN, in this case.
I am not sure however whether NGEN takes the bytecode or C# source code as input. If it takes the former, it is a potential weakness, because it makes for two chains of processing, where the first chain - the C# bytecode compiler has no idea that the subsequent NGEN instance will be using the bytecode to generate the machine code, and the NGEN instance has no idea where the bytecode came from. Essentially the knowledge and information about and in the source code is lost to NGEN, making it unable to do optimisation based on such information (or, lack of). If NGEN however, takes the original C# source code as input, then there is potential for it to be able to produce machine code as efficient as any produced from C code, and even faster given a more complex smart C# compiler that uses the level of expressiveness of C# syntax to its advantage.
There may also be people who would claim NGEN may produce as efficient machine code from bytecode as from source code, but I really do not think this is the case. The very translation from source to bytecode by the C# compiler is essentially truncating (aliasing) information by altering human logic down one step to a more machine-like logic, albeid platform-independent machine logic (which.NET is designed to be). Which your last paragraph quote supports too, by the way. I would even say "It makes sense for NGEN to link the "hot" compiler output to its input, so that compiler-aiding information is not lost between translation steps Source-Compiler-Bytecode-NGEN-Machine. Bottomline, NGEN will never be as efficient compiling from bytecode as compiling from source code, because of the nature of compilation/translation facilities and the inherent way they operate - much like signal-aliasing that drops parts of the signal during the signal travelling through stages of processing.
I am curious as to how this new engine performs on older computers. I want to know, is it the evolution for this kind of software rooted in the capabilities of newer computers, or is it evolution of logic concepts based on R&D that is also easily accessible to old hardware still?
1. C is not faster in no most cases to the languages that descend from it. Compilers are getting more clever, and are becoming smart enough to deduce a higher level (more generic) logic to the lower level (more platform-specific) logic with minimizing the translation overhead. This has been proven NUMEROUS time when the speed of cleverly designed C++ expressions were compared to their C counterparts. At best, you are partially right, partially meaning you are right today. Today is valuable, but is of no big concern.
2. Did you try to google for "C Interpreter"?
3. You cannot translate assembly into something high-level (in terms of expressiveness, or closeness to human ease of perception) in most cases, because it is broken into primitive compounds, and there arise conditions where there is ambiguity of choices translating these compounds back into their source. x86 instructions are not to C, what say, pieces of a vase are to a vase.
A good example would be a compiler emitting machine code from source based on a compile-time global variable. Since the value of the global variable is no longer known when the machine code is retrieved for reverse-engineering, it is ABSOLUTELY IMPOSSIBLE to safely predict which source code emitted the machine code in question.
We all should do our research. More research. That includes you too.
And for the last time, C cannot be faster or slower, because C is not a car, a plane, a compiler, a machine code program, or a CPU. It is a bunch of rules for composing a certain strict type of plain text variations we call program source code.
One thing though - please do not call C a "high level language" - this has no meaning. And since you accuse others of mangling terms, it is important to get this straight. C is human readable textual language expression. That is what it is.
Also, be careful generalizing. It is true that since C is a plaintext, it cannot be "fast" or "slow".But because of the way it expresses certain things, variables for instance, some optimizations will be out of reach for any C compiler.
This is why Bjarne for example advances C++ into the C++0x. The STL has gotten to the point where it was near the very performance ceiling it could provide with the C++ syntax, but some clever tricks using C++0x expression MAY help future C++0x compilers to optimize the code by having more information (which the code contains).
Stuff like "inline", "static" etc. This is an aid to compilers in optimizing code for speed. So even though strictly speaking C cannot be fast or slow, because it lacks such properties altogether, the real world compiler implementations do allow for certain languages to emit significantly faster process images than others. Consider an assembler program. Designed for one architecture, when ported to another, it becomes useless, because the abundance of many detailed instructions confuses the compiler, robbing it of the big picture. After all, a mov, cmp and jmp sequence does not tell much about what the program is all about, and there is little room for optimization.
Transforming whatever into "bytecode" (please stop overusing that term, it can mean ANYTHING) does not make it run "as fast as C code". C is not a code, C is a language typed as text into a file. A typical C compiler will then parse that human readable expression and emit code which can be parsed at run-time by the CPU conveniently, making it what is called process image, and we call it "running" the process. JIT does not tell you what it does emit. If it emits "bytecode", and if that bytecode cannot be run by the hardware CPU, some other form of translation is necessary, and is mostly handled by virtual CPUs - processor (software) that will "run" your bytecode.
What do we learn from that? We learn that C# is not as fast as C code, because there is no such thing as C code, there is compiled process image from C source code however, that is run by a hardware code processor. C# may be as fast as CPU run process, if the C# source code is translated into a process image too.
Most JIT compilers are bytecode compilers, because that is much of the point of having the privilege of Just In Time compiling - to quickly emit a "intermediate" byte sequence which can be parsed at run-time at reasonably fast speeds by a dedicated bytecode execution machine.
You did get one thing right though - Google JIT indeed:)
Just because you cringe everytime you see it, doesn't mean you figured it all out.
Databases are created to store data and data relations. Database servers strive to function to rapidly update databases in parallel with other system services, achieving great speeds, especially when client and server are distributed over network. The number of advantages is obvious, even more so when the whole testing is on Gigabit LANs, where one can send the log packet to a nearby database server with a single UDP Berkeley API call, an analogy with Fire-And-Forget missile launch. Logs can later be retrieved and analyzed without doing homecooked decoding and funky string parsing, and even without the client machine service.
What is poor STRATEGY is instead clogging diskspace with plaintext home-brewed logs, that noone else understands (only people firing up text-editors). This wastes CPU, system bus and the harddrive. This aint MS-DOS no more, mind you.
The ONLY reason one does not REALLY need it, as you put it, is when one wants to reinvent the wheel with style.
Granted, the problem with my proposal, and the reason you are asking "Do you REALLY need this?" is because we are afraid to burden client systems with uniform system-wide industry-grade logging interfaces and implementations, so that both Solitaire (god forbid) and the latest Linux enterprise application benemoth MyApp may use the same shared logging facility.
Right now Windows only has the Event Reporting Service API (with few others prolly, given the rate MS is jumping APIs all the time) and AFAIK Linux uses the (much better longterm- wise) pipe logs on filesystem (also with few other options being available, I am sure). The former is just too much overhead for tracing, even though it is called Event Reporting, it only is able to keep with such reporting in case of really BIG events, not like "variable i incremented" type of events.
Even the very filesystems we use to distribute and store our logs with, are moving in the direction to become database driven. Which means that people thinking "oh, let me just invent my little log, and store it plaintext to disk" will be doing themselves double disservice, by designing applications that in a few years from now will look archaic, because they do logging like composing the log string then issuing a file write call, which invokes a database driven fs that allocates a single column tuplet table and stores the entire complex string to it. Could work, but looks sort of useless.
Please be careful giving advice like that, everything that is put into the world is used by real people. Not just made by programmers, that do not REALLY need this or that.
When you assume real people would be writing that code, you have to understand it is just too much for a simple trace call.
Also, since fewest of projects will be switching the isTraceEnabled variable at runtime, it is completely useless to check it every time. It is either enabled or not for most cases during the entire program run.
When doing C on Linux (since C is a preference there), use preprocessor - like
A system may be developed that only authenticates a person if it senses a willing user - i.e. one that is not being forced to authenticate under gunpoint etc. Combining traditional biometrics with sensory that reads and interprets "will" may eliminate that weakest link you refer to.
However I see where you are heading with this. One cannot have a terrorist that is prepared to die reveal a password, even with torture. With a retina scan that does not distinguish a live eye from a dead eye, the terrorist may be executed and the system authenticated with his dead eye retina scan.
Still the above is hardly any relevant. A password that only exists in the mind of a user ultimately becomes "something you are", because a human mind is a mystery, and no one has extracted memories from it to a resolution of words yet, and I am sure it is quite some time away from realization, given the complexities involved with keeping a dead brain alive, etc. If you consider that, a retina-scan biometrics can in fact hardly match the good old password scheme (if the latter is used correctly) in terms of being effective.
Slashdot Mirror
It does not cost them anything to pre-install Linux in the first place, any more than tweaking a copy to run on each model they have, which is not the worlds hardest job. Roll out and copy, that is it. And no need to pay royalties to MS. The decision was probably made as a result of suits taking a meeting with another group of suits that told their "friends" that their product is superior in every way and there is absolutely no reason to even consider Linux. This is the way of recent ISO-votes and it works. All you need is too much power.
Not every disappointment is a result of a Grand Microsoft Conspiracy, but this one is, and most others that are mentioned in context are too. We are not talking about Mars Polar Lander failure.
Are you joking?
This is at least OS-specific. Crashing implying a segmentation fault WILL cause Windows NT kernel to abort the process that owns the thread and clean up the mess. You may however trap the segfaul exception signal and thus prevent the process from being bailed out by the OS.
The most common crash scenario on Windows is when the single thread that is part of any process misbehaves by accessing memory it does not have right to access, the CPU signals a segfault, Windows kernel catches the uncaught exception and decides, for the lack of capability and capacity to salvage a corrupt process, to "eject" it - aborting the process, freeing up memory, and restoring the system the best it can. So whatever you wrote in your post above, does not apply at least to Windows NT derivatives. I am pretty sure it is a pretty common default scenario action and reaction in Linux too.
The whole thing crashes because pretty much nobody can be bothered to process the exceptions that rise and cause the OS to abort the process and clean up the mess. But when we were kids we did learn to clean up our own mess, and not let our parents or computer operating systems slave for us. Jokes aside, if your thread screws up, the process should tidy up, and not let the OS remove the process altogether.
Then again, it is something that is not achievable today, and few if any programmers think about salvaging the processes they design. So you are essentially on spot here.
So, basically it comes down to WHAT you use threads for. Obviously, using threads to process tab page content wont speed up your 600-post Slashdot discussion, because only a single thread will be doing the job. Or a process with a single thread. Threads are not magic, but I am sure you know that.
There are multiple ways to optimize such scenarios with threads. There are multipple ways to optimize multi-page browsers too, with the one-process/thread-per-tab/page being the most known obviously.
Alternatively, you might want to use a single process, and dedicate one thread for page rendering, another for plugins (including updating all those pesky Flash animations for those who dont use NoScript/AdBlock+), and another for JavaScript processing.
My point is there are many ways to use processes and threads, and dedicating execution threads on a per-page/tab basis is just one of them, and I am not sure it is the wisest. Microsoft recommends themselves that any process uses 2 x CPU_core_count threads, and even though they are sometimes coming up with pretty weird recommendations, it is still a hardware bound feature, and too many threads, especially if waiting on locks of diff. kinds will have the OS spend more time on the whole thread scheduling than doing useful work for the user. I am sure Intel would NOT recommend either to load more than 6-8 threads in a GUI application process. Sometimes the whole threading can be "emulated" with benefits in speed and resource usage by faking it all. The way overlapping I/O is done f.e.
I did create a TCP/IP server once, creating a thread for every client connection it receives, and I noticed client would be waiting for the server OS scheduling their connection threads, so that they could receive some data already after 10 threads. That was on P4 NetBurst arch back in 2004, but I doubt the picture is much better now.
You do pick on details. Its all in details they say, yet you pick on something that does not make the point of my post. Which is, maybe an apartment building does not have ANY effect on general good-feeling of the inhabitants, and in fact may suit just fine and support them emotionally and whatever. But when you build a pyramid for over a million people with a base of one square kilometer (sounds much? It is not.), there better be some god damn good ergonomics inside it, because it is VERY difficult to provide good emotional conditions for living to a million people inside a pyramid. Not to mention the latter in a city already struggling with fresh-water and sanitary issues, it just does not make any sense.
There is a reason most big companies distribute their working offices over different areas, instead of building a single biggest building they possibly can and putting everyone over there. And no matter how many Bonsai trees and pictures of their family workers put on their desk, regardless of the architects best wishes, it don't feel like home. Similarly, this pyramid will fall hard on its face (pun intended) trying to be true home for every single person it houses.
This is as good as I can put it.
Good informative post. Crossing fingers for your safety ,)
However, did you take a trip to the Wikipedia article on Palm Islands? It seems the project is well on track as of August'08. Is the article hijacked, in your opinion?
Hehe, funny post aside,
Not comparable.
Babylon was built with the purpose to reach the Heaven. Literally.
I doubt Ziggurat project has much a of a religious motivation in it. Those sheiks in Dubai just want more bling. And they got plenty already.
For starters, have you heard of a building that housed over a million inhabitants?
It is different by a factor of 1000 roughly:
Average modern apartment skyscraper - ~1000 inhabitants. Architect ego - moderate.
Ziggurat - ~1100000 inhabitants. Architect ego - Uncharted beyond the 'Unusually high' mark on the ego scale.
Surely it might suit some folks, who have nothing against being 'slotted'. But on average, I d estimate that factor of 1000 to also apply to the level of happyness of such inhabitants (negatively).
People rebel against too much machinery. You don't have to be a psychologist or alike to notice that. They have problems already when you try to put everyone on the same floor into exactly the same type of living compound, assuming them to also be exactly the same. This is what the communist dream was like at the top of their game, before it started to rot. Capitalism may have its inherent flaws, but it in no way criticizes people that decide to build their own house by the sea, which is perfectly humane.
Yeah, in fact someone should design a computer game with this in mind.
" You are a privileged citizen of a unique upperclass society in Dubai, settled in a pyramide like housing structure of large proportions that you share with over a million immediate neighbours. And it was all like a dream on Earth... Until, one day the unthinkable happened. Noone knows what exactly did happen, but the life support systems failed with no warning, and people started to disappear... Someone reported of strange incidents involvind the paranormal. But you do not believe such rumours, do you? It is up to you however to now start discovering what exactly HAS happened and save what is left! "
Only in Dubai. Big deal - an eco-friendly pet project of a bunch of select few oil billionaires of the Mideast that can afford to spend their cheap dollars on something extravagant and exclusive and trendy like this. It maybe eco-friendly, but I seriously doubt it is even in remote proximity to cheap.
So, no point of paying too much attention, before this comes to the poor rural communities scattered all over the world for a price affordable to someone in say New Orleans and Russia.
Talk about reading between lines.
Even a child should know that everything has a beginning and an end. Empire like Google starts to eat its own self with time, and collapses under its own weight. This is part of life, and Rome and a lot of other attempts to be larger than life went this way. And the more one is trying to fight this tendency the more weight it carries, and the harder is the fall. What do you expect, Google to stay on top forever? This only happens in fairy tales. The reality has something to do with particle physics, I am sure :-)
By ways of natural (and unnatural) selection, no Joe Schmo will have both hundreds acres of land, hundreds of construction workers and engineers, a lot of raw materials and be able to orchestrate it all. One out of four - perhaps, with a lot of tough luck, but not all at the same time. Even in the U.S. of A.
But I guess you were joking. Ha-ha!
What could go wrong?
If you are a software developer yourself, try to set up proper division yourself by talking to appropriate people in positions.
If not, stick to biotech. Software developing is engineering too, and it is not a good idea to do amateur in-house engineering, especially if your software products need to be of mission-critical kind. Outsource all software related job(s) to someone else who specializes in software design and development, and you yourself will sleep better.
Yes, in that case there is potential (through evolving NGEN) for C# to yield what is called native code, which may or may not be as fast as any other machine code. Machine code differs too from one program to another, so the weight falls on the pieces of sofware that generate such code - the C compiler and NGEN, in this case.
I am not sure however whether NGEN takes the bytecode or C# source code as input. If it takes the former, it is a potential weakness, because it makes for two chains of processing, where the first chain - the C# bytecode compiler has no idea that the subsequent NGEN instance will be using the bytecode to generate the machine code, and the NGEN instance has no idea where the bytecode came from. Essentially the knowledge and information about and in the source code is lost to NGEN, making it unable to do optimisation based on such information (or, lack of). If NGEN however, takes the original C# source code as input, then there is potential for it to be able to produce machine code as efficient as any produced from C code, and even faster given a more complex smart C# compiler that uses the level of expressiveness of C# syntax to its advantage.
There may also be people who would claim NGEN may produce as efficient machine code from bytecode as from source code, but I really do not think this is the case. The very translation from source to bytecode by the C# compiler is essentially truncating (aliasing) information by altering human logic down one step to a more machine-like logic, albeid platform-independent machine logic (which .NET is designed to be). Which your last paragraph quote supports too, by the way. I would even say "It makes sense for NGEN to link the "hot" compiler output to its input, so that compiler-aiding information is not lost between translation steps Source-Compiler-Bytecode-NGEN-Machine. Bottomline, NGEN will never be as efficient compiling from bytecode as compiling from source code, because of the nature of compilation/translation facilities and the inherent way they operate - much like signal-aliasing that drops parts of the signal during the signal travelling through stages of processing.
I am curious as to how this new engine performs on older computers. I want to know, is it the evolution for this kind of software rooted in the capabilities of newer computers, or is it evolution of logic concepts based on R&D that is also easily accessible to old hardware still?
You are mistaken on several points.
1. C is not faster in no most cases to the languages that descend from it. Compilers are getting more clever, and are becoming smart enough to deduce a higher level (more generic) logic to the lower level (more platform-specific) logic with minimizing the translation overhead. This has been proven NUMEROUS time when the speed of cleverly designed C++ expressions were compared to their C counterparts. At best, you are partially right, partially meaning you are right today. Today is valuable, but is of no big concern.
2. Did you try to google for "C Interpreter"?
3. You cannot translate assembly into something high-level (in terms of expressiveness, or closeness to human ease of perception) in most cases, because it is broken into primitive compounds, and there arise conditions where there is ambiguity of choices translating these compounds back into their source. x86 instructions are not to C, what say, pieces of a vase are to a vase.
A good example would be a compiler emitting machine code from source based on a compile-time global variable. Since the value of the global variable is no longer known when the machine code is retrieved for reverse-engineering, it is ABSOLUTELY IMPOSSIBLE to safely predict which source code emitted the machine code in question.
We all should do our research. More research. That includes you too.
And for the last time, C cannot be faster or slower, because C is not a car, a plane, a compiler, a machine code program, or a CPU. It is a bunch of rules for composing a certain strict type of plain text variations we call program source code.
Bob, your C is weak.
Good point.
One thing though - please do not call C a "high level language" - this has no meaning. And since you accuse others of mangling terms, it is important to get this straight. C is human readable textual language expression. That is what it is.
Also, be careful generalizing. It is true that since C is a plaintext, it cannot be "fast" or "slow".But because of the way it expresses certain things, variables for instance, some optimizations will be out of reach for any C compiler.
This is why Bjarne for example advances C++ into the C++0x. The STL has gotten to the point where it was near the very performance ceiling it could provide with the C++ syntax, but some clever tricks using C++0x expression MAY help future C++0x compilers to optimize the code by having more information (which the code contains).
Stuff like "inline", "static" etc. This is an aid to compilers in optimizing code for speed. So even though strictly speaking C cannot be fast or slow, because it lacks such properties altogether, the real world compiler implementations do allow for certain languages to emit significantly faster process images than others. Consider an assembler program. Designed for one architecture, when ported to another, it becomes useless, because the abundance of many detailed instructions confuses the compiler, robbing it of the big picture. After all, a mov, cmp and jmp sequence does not tell much about what the program is all about, and there is little room for optimization.
Transforming whatever into "bytecode" (please stop overusing that term, it can mean ANYTHING) does not make it run "as fast as C code". C is not a code, C is a language typed as text into a file. A typical C compiler will then parse that human readable expression and emit code which can be parsed at run-time by the CPU conveniently, making it what is called process image, and we call it "running" the process. JIT does not tell you what it does emit. If it emits "bytecode", and if that bytecode cannot be run by the hardware CPU, some other form of translation is necessary, and is mostly handled by virtual CPUs - processor (software) that will "run" your bytecode.
What do we learn from that? We learn that C# is not as fast as C code, because there is no such thing as C code, there is compiled process image from C source code however, that is run by a hardware code processor. C# may be as fast as CPU run process, if the C# source code is translated into a process image too.
Most JIT compilers are bytecode compilers, because that is much of the point of having the privilege of Just In Time compiling - to quickly emit a "intermediate" byte sequence which can be parsed at run-time at reasonably fast speeds by a dedicated bytecode execution machine.
You did get one thing right though - Google JIT indeed :)
Irrelevant. And incorrect.
With all due respect..
Just because you cringe everytime you see it, doesn't mean you figured it all out.
Databases are created to store data and data relations. Database servers strive to function to rapidly update databases in parallel with other system services, achieving great speeds, especially when client and server are distributed over network. The number of advantages is obvious, even more so when the whole testing is on Gigabit LANs, where one can send the log packet to a nearby database server with a single UDP Berkeley API call, an analogy with Fire-And-Forget missile launch. Logs can later be retrieved and analyzed without doing homecooked decoding and funky string parsing, and even without the client machine service.
What is poor STRATEGY is instead clogging diskspace with plaintext home-brewed logs, that noone else understands (only people firing up text-editors). This wastes CPU, system bus and the harddrive. This aint MS-DOS no more, mind you.
The ONLY reason one does not REALLY need it, as you put it, is when one wants to reinvent the wheel with style.
Granted, the problem with my proposal, and the reason you are asking "Do you REALLY need this?" is because we are afraid to burden client systems with uniform system-wide industry-grade logging interfaces and implementations, so that both Solitaire (god forbid) and the latest Linux enterprise application benemoth MyApp may use the same shared logging facility.
Right now Windows only has the Event Reporting Service API (with few others prolly, given the rate MS is jumping APIs all the time) and AFAIK Linux uses the (much better longterm- wise) pipe logs on filesystem (also with few other options being available, I am sure). The former is just too much overhead for tracing, even though it is called Event Reporting, it only is able to keep with such reporting in case of really BIG events, not like "variable i incremented" type of events.
Even the very filesystems we use to distribute and store our logs with, are moving in the direction to become database driven. Which means that people thinking "oh, let me just invent my little log, and store it plaintext to disk" will be doing themselves double disservice, by designing applications that in a few years from now will look archaic, because they do logging like composing the log string then issuing a file write call, which invokes a database driven fs that allocates a single column tuplet table and stores the entire complex string to it. Could work, but looks sort of useless.
Please be careful giving advice like that, everything that is put into the world is used by real people. Not just made by programmers, that do not REALLY need this or that.
I am out.
When you assume real people would be writing that code, you have to understand it is just too much for a simple trace call.
Also, since fewest of projects will be switching the isTraceEnabled variable at runtime, it is completely useless to check it every time. It is either enabled or not for most cases during the entire program run.
When doing C on Linux (since C is a preference there), use preprocessor - like
#ifdef LOG_TRACE_ENABLED /* do nothing */
#define logtrace(x) log.trace(x)
#else
#define logtrace(x)
#endif
It is not the worst use of preprocessor, and is a good tradeoff. In C++ i would do templates instead.
A system may be developed that only authenticates a person if it senses a willing user - i.e. one that is not being forced to authenticate under gunpoint etc. Combining traditional biometrics with sensory that reads and interprets "will" may eliminate that weakest link you refer to.
However I see where you are heading with this. One cannot have a terrorist that is prepared to die reveal a password, even with torture. With a retina scan that does not distinguish a live eye from a dead eye, the terrorist may be executed and the system authenticated with his dead eye retina scan.
Still the above is hardly any relevant. A password that only exists in the mind of a user ultimately becomes "something you are", because a human mind is a mystery, and no one has extracted memories from it to a resolution of words yet, and I am sure it is quite some time away from realization, given the complexities involved with keeping a dead brain alive, etc. If you consider that, a retina-scan biometrics can in fact hardly match the good old password scheme (if the latter is used correctly) in terms of being effective.
Yes they can. What's your point (if any) ?