(1) will still charge for the licenses, except minimal ones with every Windows version. (2) will try to tie it very strictly to the Windows platform (3) when it is very established, will tighten the noose even worse than Adobe did.
However I think that 1 and 2 will already prevent Metro from eclipsing PS before it even gets to (3).
Hardware vendors aren't terribly fond of licensing from very strong software partners, and become dependant on them. (see e.g. the M$ phone business)
The slowing effect of protection stuff is as much diskaccess, the growing size of binaries (ever entered a directory with a few 100MB self extracting.exe's?) as the pure CPU.
The main problem with protection stuff is that nowadays people seem to develop software to be able to run stand-alone on todays hardware. People that run a bit more, or use yesterdays computer are left in the cold.
However it is pretty much also the customers fault. They buy the new versions while pretty much nothing changed except the versionnumber, a new desktop theme, and something to make it up to date with buzzwords. (wifi/xml).
Stick to your old versions of aviri as long as the signatures are still on. Kill the firewall, it is useless anyway if you are patched correctly. I know that the avg user is paranoid and thinks every FW event is a threat averted, but in reality they are just a few scanning bots and nutters.
I'm only lukewarm to security (do my patches every so and so many months, and use the oldest still support McAfee engine), and no firewall, while I'm in a totally open university net. Despite that I had more dataloss and trouble from protection software than from actual malware.
Oh, and btw, if you reinstall your Windows, PLEASE disconnect the network, and install the SPs and a select few (worm) hotfixes from CD. Half of the hacked machines are hacked during install, not use.
I think using a bare bones language as plain C already comes pretty close to manual optimising.
In general, for each manual optimisation, a case must be based, preferably based on profiling. Optimisation in its own is not bad. The problem is that it is too often done based on perception, and that perception is often down right faulty, or grossly out of date.
Re:Get clipboard. Stand over shoulder. Watch.
on
What Makes a Good UI?
·
· Score: 2, Interesting
Agree very much. Specially point 2.
Another one is to get rules about data documented, and keep on asking, when they say "and then I know that this record is bogus, so I ignore it"
The Roman empire controlled all shores of the Mediterranean, either directly or as Protectorat (like e.g. Israel) and Romans refered to the Mediterranean like that.
Seriously, I think there is no catch. During the last years M$ probably got signals that it would be excluded from government contracts if the format wasn't somewhat open.
They just waited a period to let their own Microsoft XML tools and libs to establish themselves, and now make some good press with it.
Nevertheless, it is a good thing. Open is open, Microsoft or not.
One of the worst problems I had was related to hyperthreading. Turned out an 3rd party component that was a black box was threadsafe, but not multi-processing safe.
When I finally figured it out (of course it happened only once in days, had to write and tune exercisers for weeks to get it to occur within minutes), an update became available. (we nailed 4 from the 6 spots in that patch already ourselves by then)
[i]I suspect you're probably trying to discuss DCUs, but that would be a faulty analogy; the parallel to DCUs are compiled libraries (*.o, *.lib, etc depending on platform,) not uncompiled libraries, and as such the issue of recompilation is a non-issue. [/i]
They are both (interface(read: compiled header)+implementation(as in code)) You can have a program importing units. The compiler will load the interface in symbolic form from the DCU, and compile the main program.
Only the linker, takes the compiled program and the implementation part from the.dcu. (or.tpu)
[i]Because Pascal doesn't have headers, [/i]
The interface part of the unit more or less is. At least according to the definition. I'm used to.
If you really want to make a point, try to explain something instead of just flame arrogantly. I'm not native english, and not very well versed in C(C++) jargon, but arrogancy won't help to fix that language barrier.
[i]it also doesn't have precompiled headers. Do you not realize that there is a major distinction between precompiled headers and vtbls?[/i]
I don't know what a vtbls in your definition is, or how it relates to the discussion. I assume object vtables, but I don't get what you are hinting at.
[i]Uh. Headers can't change, no matter what. They never carry anything which changes. Do bear in mind that both inlined code and templates are injected into implementations, where any changing occurs.[/i]
What I was hinting at:
simply a commandline override variatn of the manual avoidance of the C header. So to avoid having to code the workaround you show with test1 and test2.
What I could also state:
If you have a mutual dependancy in units, you can resolve it by compiling the mutual units twice. E.g. A import B and B imports A, both in interface.
The first compile simply has to determine size, the second compile has the other units types, and adds the typeinfo.
(compiler reinitialisation)
In the BP case you have a main program that compiles A and B.
Compiler starts compiling main program, but then decides to do A. Above the USES statement, already preprocessor symbols can be defined. This state doesn't go over to when you are compiling the unit. It is not a real reinitialisation of course, since it just swaps to a different namespace for the unit.
Maybe I should have said preprocessor state per compilation unit, and not reinit compiler.
I had a whole reply ready, but IMHO it is not worth the trouble replying to. Maybe it is better when you read the original post with some comments.
Oh, and:
you>Namedropping doesn't make you seem correct, y'know.
Neither does getting personal about perceived faults, when it's pretty much your own assumptions that are the problem.
-------------------
Reread the original msg with this in mind: - I never said _anything_ about C++. Neither does the thread starter. I assume roughly some C like language, non in particular. So the whole template rant is bogus.
- When I am talking about state, I'm talking about state in the compiler. (which in most _performing_ tools has the preprocessor built in btw) There is more than just the code trees in a serious compiler, specially when it can do whole programs in a run. E.g. state about precompiled headers. For something serious to make header systems peroformant, the compiler needs access to the preprocessor internal state anyway, to decide if a header needs reevaluation. - The pascal angle is mostly to illustrate a system that depends less on the "simply inline" header system. The philosophic differences between C and Pascal languages are large, but the basic principle is that there are two ways of including foreigh code: -- by {$i} ({$include in delphi), like #include in C -- by uses, which invokes the unit system.
The main reason, and the fundament of a unit system, why the second way is more optimal than headers, is that the compiler reinitialises before reading a unit interface. IOW the preprocessor symbols from the program that USES don't affect the unit, and the decision about recompiling the unit is easy. Load the precompiled header from the compiled unit (if it is not already in the unit cache), and let's go on with it.
Any way to speed up C headers should keep this in mind: - either preserve the state of the preprocessor (defined symbols etc) before entering a header. - or add a flag to header or compiler cmdline to signal that headers are not allowed to change.
Of course, saying "pascal" to most C(++) users is equivalent to waving a red cloth to a bull, but contrary to the bull case, that is not my problem.
IMHO the crucial question is (and I can't answer it, don't know C++ that well): Does in C++ preprocessor state flow from header to header?
In Modula2/(Turbo)Pascal you can simply check filedate (and compute file crc if you want to), and if it is the same, you can assume your precompiled header is ok, since no other _code_ can influence it.
Of course commandline params can, therefore, the precompiled header also contains a struct with the parameters with the header was compiled, and you can check if that is equivalent.
In Turbo Pascal, you also have to do recursive header detangling, but I don't know if recursive inclusions in the header are allowed in std Modula2. (in TP they are, but must be resolved after one mutual recompile)
You can accomplish (1) by letting make keep the compiler alive, and only call some init.
I also agree with (2), and a simple example is inlining small calls across compilation units.
IMHO the best solution would be to allow tighter integration between make - cpp - gcc - as - ld
4 binaries to run per compilation unit is quite a lot of overhead. (ld runs for the bin only). This would push up memory requirements a bit though.
Caching headers in-compiler/preprocessor would then also be possible.
If this was done, it should be mainly done as an optional mode for the "current" target, and allow the old ways for crosscompiling/bootstrapping purposes.
Also note the speed of e.g. Turbo Pascal or Delphi. It stems mostly from not having to cope with recursively included headers.
If a unit is imported for the second time, they can simply copy the state, since preprocessor state has no effect on the precompiled header. The compiler only has to resolve recursive inclusions.
Header caching _is_ possible for C though; make could keep the compiler alive, and have e.g. a CRC over the conditional state, to see if the state changed.
I think the separate header is simply code duplication and memory limitations of old C compilers.
Larger programs (compilation unit) could be compiled if the preprocessor - compiler were separated, and used batch processing, unused parts of the headers were never seen by the compiler.
The main problem with headers is that preprocessor stat is global to the entire operation, not per header or C file.
This makes conditional state flow from one to the other, which makes separate precompiled headers hard (since the conditionals might not match).
Also the header system requires manual making of makefiles (or using quite complex scanners and tools) , while this could be easily done by a compiler fairly easily. See most Wirthian languages (e.g. Turbo Pascal vs Turbo C++) for examples.
Very high recall and (need to be serviced) rates is also my experience with Dell. Nearly every non-desktop (laptop, server) has had servicing. (desktops fine though)
With HP/Compaq it was only incidental. Also I liked the finishing of the HP servers better.
Correct. And this is how it went with 4.x either. 3.6 was significantly better than the first 4.xRC.
It's not even something of FreeBSD in particular. In the project we are RC'ing for 2.0, and all kinds of detail benchmarks are popping up.
However overall, for significant programs 2.0.x is generally faster than 1.0.x even when 2.0.x doesn't even use optimizations (the project is a compiler).
The failure at microbenchmarks is just that the 1.0.x branch had 6 revisions in 3-4 years, some a full year tuning apart even.
FreeBSD's focus is typically on overall throughput of massive server, with responsetime as a tradeoff, while this benchmark with all of its timings of single OS operations is more something realtimish?
If NetBSD aspires to be a RT focussed distro/OS, they'd better have benchmarked it against some Linux with RT patches?
As in being able to quickly increase and decrease the editor area surface (by maximizing the editor window so no others are visible except window bar with menu) for e.g. some major edit
Slashdot Mirror
I think the trouble in this is that Microsoft
(1) will still charge for the licenses, except minimal ones with every Windows version.
(2) will try to tie it very strictly to the Windows platform
(3) when it is very established, will tighten the noose even worse than Adobe did.
However I think that 1 and 2 will already prevent Metro from eclipsing PS before it even gets to (3).
Hardware vendors aren't terribly fond of licensing from very strong software partners, and become dependant on them. (see e.g. the M$ phone business)
An old helldesk hacks opinion:
.exe's?) as the pure CPU.
The slowing effect of protection stuff is as much diskaccess, the growing size of binaries (ever entered a directory with a few 100MB self extracting
The main problem with protection stuff is that nowadays people seem to develop software to be able to run stand-alone on todays hardware. People that run a bit more, or use yesterdays computer are left in the cold.
However it is pretty much also the customers fault. They buy the new versions while pretty much nothing changed except the versionnumber, a new desktop theme, and something to make it up to date with buzzwords. (wifi/xml).
Stick to your old versions of aviri as long as the signatures are still on. Kill the firewall, it is useless anyway if you are patched correctly. I know that the avg user is paranoid and thinks every FW event is a threat averted, but in reality they are just a few scanning bots and nutters.
I'm only lukewarm to security (do my patches every so and so many months, and use the oldest still support McAfee engine), and no firewall, while I'm in a totally open university net. Despite that I had more dataloss and trouble from protection software than from actual malware.
Oh, and btw, if you reinstall your Windows, PLEASE disconnect the network, and install the SPs and a select few (worm) hotfixes from CD. Half of the hacked machines are hacked during install, not use.
I think using a bare bones language as plain C already comes pretty close to manual optimising.
In general, for each manual optimisation, a case must be based, preferably based on profiling.
Optimisation in its own is not bad. The problem is that it is too often done based on perception, and that perception is often down right faulty, or grossly out of date.
Agree very much. Specially point 2.
Another one is to get rules about data documented, and keep on asking, when they say "and then I know that this record is bogus, so I ignore it"
The Roman empire controlled all shores of the Mediterranean, either directly or as Protectorat (like e.g. Israel) and Romans refered to the Mediterranean like that.
Seriously, I think there is no catch. During the last years M$ probably got signals that it would be excluded from government contracts if the format wasn't somewhat open.
They just waited a period to let their own Microsoft XML tools and libs to establish themselves, and now make some good press with it.
Nevertheless, it is a good thing. Open is open, Microsoft or not.
One of the worst problems I had was related to hyperthreading. Turned out an 3rd party component that was a black box was threadsafe, but not multi-processing safe.
When I finally figured it out (of course it happened only once in days, had to write and tune exercisers for weeks to get it to occur within minutes), an update became available.
(we nailed 4 from the 6 spots in that patch already ourselves by then)
[i]I suspect you're probably trying to discuss DCUs, but that would be a faulty analogy; the parallel to DCUs are compiled libraries (*.o, *.lib, etc depending on platform,) not uncompiled libraries, and as such the issue of recompilation is a non-issue. [/i]
.dcu. (or .tpu)
They are both (interface(read: compiled header)+implementation(as in code)) You can have a program importing units. The compiler will load the interface in symbolic form from the DCU, and compile the main program.
Only the linker, takes the compiled program and the implementation part from the
[i]Because Pascal doesn't have headers, [/i]
The interface part of the unit more or less is. At least according to the definition. I'm used to.
If you really want to make a point, try to explain something instead of just flame arrogantly. I'm not native english, and not very well versed in C(C++) jargon, but arrogancy won't help to fix that language barrier.
[i]it also doesn't have precompiled headers.
Do you not realize that there is a major distinction between precompiled headers and vtbls?[/i]
I don't know what a vtbls in your definition is, or how it relates to the discussion. I assume object vtables, but I don't get what you are hinting at.
[i]Uh. Headers can't change, no matter what. They never carry anything which changes. Do bear in mind that both inlined code and templates are injected into implementations, where any changing occurs.[/i]
What I was hinting at:
simply a commandline override variatn of the manual avoidance of the C header. So to avoid having to code the workaround you show with test1 and test2.
What I could also state:
If you have a mutual dependancy in units, you can resolve it by compiling the mutual units twice.
E.g. A import B and B imports A, both in interface.
The first compile simply has to determine size, the second compile has the other units types, and adds the typeinfo.
(compiler reinitialisation)
In the BP case you have a main program that compiles A and B.
Compiler starts compiling main program, but then decides to do A. Above the USES statement, already preprocessor symbols can be defined. This state doesn't go over to when you are compiling the unit. It is not a real reinitialisation of course, since it just swaps to a different namespace for the unit.
Maybe I should have said preprocessor state per compilation unit, and not reinit compiler.
I had a whole reply ready, but IMHO it is not worth the trouble replying to. Maybe it is better when you read the original post with some comments.
Oh, and:
you>Namedropping doesn't make you seem correct, y'know.
Neither does getting personal about perceived faults, when it's pretty much your own assumptions that are the problem.
-------------------
Reread the original msg with this in mind:
- I never said _anything_ about C++. Neither does the thread starter. I assume roughly some C like language, non in particular. So the whole template rant is bogus.
- When I am talking about state, I'm talking about state in the compiler. (which in most _performing_ tools has the preprocessor built in btw) There is more than just the code trees in a serious compiler, specially when it can do whole programs in a run. E.g. state about precompiled headers. For something serious to make header systems peroformant, the compiler needs access to the preprocessor internal state anyway, to decide if a header needs reevaluation.
- The pascal angle is mostly to illustrate a system that depends less on the "simply inline" header system. The philosophic differences between C and Pascal languages are large, but the basic principle is that there are two ways of including foreigh code:
-- by {$i} ({$include in delphi), like #include in C
-- by uses, which invokes the unit system.
The main reason, and the fundament of a unit system, why the second way is more optimal than headers, is that the compiler reinitialises before reading a unit interface. IOW the preprocessor symbols from the program that USES don't affect the unit, and the decision about recompiling the unit is easy. Load the precompiled header from the compiled unit (if it is not already in the unit cache), and let's go on with it.
Any way to speed up C headers should keep this in mind:
- either preserve the state of the preprocessor (defined symbols etc) before entering a header.
- or add a flag to header or compiler cmdline to signal that headers are not allowed to change.
Of course, saying "pascal" to most C(++) users is equivalent to waving a red cloth to a bull, but contrary to the bull case, that is not my problem.
IMHO the crucial question is (and I can't answer it,
don't know C++ that well): Does in C++ preprocessor state flow from header to header?
In Modula2/(Turbo)Pascal you can simply check filedate (and compute file crc if you want to), and if it is the same, you can assume your precompiled header is ok, since no other _code_ can influence it.
Of course commandline params can, therefore, the precompiled header also contains a struct with the parameters with the header was compiled, and you can check if that is equivalent.
In Turbo Pascal, you also have to do recursive header detangling, but I don't know if recursive inclusions in the header are allowed in std Modula2. (in TP they are, but must be resolved after one mutual recompile)
You can accomplish (1) by letting make keep the compiler alive, and only call some init.
I also agree with (2), and a simple example is inlining small calls across compilation units.
IMHO the best solution would be to allow tighter integration between make - cpp - gcc - as - ld
4 binaries to run per compilation unit is quite a lot of overhead. (ld runs for the bin only). This would push up memory requirements a bit though.
Caching headers in-compiler/preprocessor would then also be possible.
If this was done, it should be mainly done as an optional mode for the "current" target, and allow the old ways for crosscompiling/bootstrapping purposes.
_Avoid_ code duplication of course.
Also note the speed of e.g. Turbo Pascal or Delphi.
It stems mostly from not having to cope with recursively included headers.
If a unit is imported for the second time, they can simply copy the state, since preprocessor state has no effect on the precompiled header. The compiler only has to resolve recursive
inclusions.
Header caching _is_ possible for C though; make could keep the compiler alive, and have e.g. a CRC over the conditional state, to see if the state changed.
I think the separate header is simply code duplication and memory limitations of old C compilers.
Larger programs (compilation unit) could be compiled if the preprocessor - compiler were separated, and used batch processing, unused parts of the headers were never seen by the compiler.
The main problem with headers is that preprocessor stat is global to the entire operation, not per header or C file.
This makes conditional state flow from one to the other, which makes separate precompiled headers hard (since the conditionals might not match).
Also the header system requires manual making of makefiles (or using quite complex scanners and tools) , while this could be easily done by a compiler fairly easily. See most Wirthian languages (e.g. Turbo Pascal vs Turbo C++) for examples.
Very high recall and (need to be serviced) rates is also my experience with Dell. Nearly every non-desktop (laptop, server) has had servicing. (desktops fine though)
With HP/Compaq it was only incidental. Also I liked the finishing of the HP servers better.
Correct. And this is how it went with 4.x either. 3.6 was significantly better than the first 4.xRC.
It's not even something of FreeBSD in particular. In the project we are RC'ing for 2.0, and all kinds of detail benchmarks are popping up.
However overall, for significant programs 2.0.x is generally faster than 1.0.x even when 2.0.x doesn't even use optimizations (the project is a compiler).
The failure at microbenchmarks is just that the 1.0.x branch had 6 revisions in 3-4 years, some a full year tuning apart even.
You don't know that. Maybe freebsd prepares some tables that makes syscalls go faster, or fs operations, or really committing memory.
If you want to test that, you really have to test that role (web server), in controlable and duplicatable circumstances.
And maybe then after, you can finally do some microbenchmarks to see what could be the bottle neck on FreeBSD.
_after_, not _before_.
Exactly
Nothing in the benchmarks is about performance of a certain role. It is all about the performance of certain functions, like (v)fork.
The only reason to judge a whole system on these I can think of is because of guaranteed minimal response.
Of course micro benchmarking is usefultoo, but it should then be correlated to real performance.
It could e.g. be that FreeBSD does some extra preparational work in some functions that NetBSD doesn't that increase overall throughput.
FreeBSD's focus is typically on overall throughput of massive server, with responsetime as a tradeoff, while this benchmark with all of its timings of single OS operations is more something realtimish?
If NetBSD aspires to be a RT focussed distro/OS, they'd better have benchmarked it against some Linux with RT patches?
Free Pascal release a 2.0RC1 on new year!
Lazarus binaries have been rebuilt. Check it out.
Or try Lazarus:
http://lazarus.freepascal.org
I prefer it, at least the delphi way.
As in being able to quickly increase and decrease the editor area surface (by maximizing the editor window so no others are visible except window bar with menu) for e.g. some major edit
I thought it was OpenBSD
I also miss N. Wirth
Do we want to forget C nowadays or so?
Slap a XP-teletubby look on some desktop environment, and presto.