It's all about the opponents. Remember that they're fluffing it up with enough ultra-stupid dummies that you don't have a hope in hell unless you beat these dummies soundly
The dummies arn't very stupid. There are a few varations of random, some "play oponets move+1", and some simplistic prediction systems. They are short, they are simple, but they ain't "rock, rock, rock...."
Sure, it'll wear down the battery, but I'm not talkin' about watching freakin' Shoah on your plane trip here.;-) We're just on a flight of a few hours, and you can just plug your laptop in and recharge the battery later on the ground
Some (most? a few?) airlines have power for portables in bissness class now. It requires a sort-of-cig-adaptor thing. Hopefully this trikkles down to coach which is what I have to fly...
Does anyone know what the typical power budget is for a laptop computer? How much power is used by the CPU, hard drive, DRAM and display?
Depends strongly on the portable, and even how you use it. If you use the disk (or CD ROM, or anything it has to spin, esp. spin fast) that sucks a whole lot of your power. If it has to use active cooling, then the fan will suck power too. The backlight (if in use) sucks a lot of power also. The CPU can be pretty low on that list. Or fairly high (the 650/500Mhz SpeedStep things can suck a fair amount of power, maybe more then the backlight!). The CPU also makes heat (as does the drive) which can make the fan spin....
If you look at a really simple portable like a Palm Pilot the backlight sucks most of the power, the CPU a distant second, and the DRAM a more distant third. AA rechargables last me over a month with no backlight use, about three weeks with a fair amount of backlight, or about 10 hours of dinking with "Pocket Life" with the backlight on (est from looking at the batt meter before and after 2 hours of said dinking). I've heard that it'll keep it's DRAM running for 2 or 3 months on "dead" battries.
I would love to have a laptop computer that could run for days on a battery charge, even if the CPU was slow by desktop standards.
The only thing that comes close is the Palm, and in part because you tend to turn it on, use it for three minutes, and turn it off for a while (what's that phone number? Gotta remember to get the car serviced this week. What time is it anyway? When is sunset today? [dee-DEE-dee-DEE-dee-DEE] Oh! Gotta run if I want to catch buffy tonight...). Still, it is a computer:-)
Mobile computers have one feature in common with iMac's : they haven't any fan
Heh. The Sony Z505JS (portable) has a fairly loud fan. Unless I go to the power profile thingie and ask for low fan noise (which seems to also get variable CPU speed) it is louder then my home machine. Of corse my home machine uses the all important PC Power and Cooling Silencer fan (I think it is a scroll cage fan). The CPU fan makes modestly more noise (with the case closed) then the real fan. Of corse disk chatter is louder then both those...so I have to make sure the MP3 player never stops:-)
Still it goes to show you can make quietish desktop machines with fans, and loud notebooks too.
It would be nice if there were enough demand for quiet fans on other parts of the machine too, if the CPU fan had a scroll cage I would be even happyer. Regretably scroll cage fans appear to be expensave. I don't know if that's because they are harder to make, or just in way less demand, so less compatation, so higer price, so less demand....
If you want a quiet machine, I urge you to check out the PC Power & Cooling fans (the silencer ones, not the turbo cool), and if anyone knows where to get quiet stuff cheaper, drop me a line.
Alpha has been around longer than Rambus, I think...
RAMBUS is older then people think. It was around in 1992. I think the Alpha predates it by a little.
However the EV6 memory bus, the part that you think may be prior art is fairly new (1995 at the earylest? Not to market until '97 or '98?). As others have said using both edges of the clock isn't innovatave, RAMBus was just the first to use and try to patent it for use with memory.
Hell, VHDL will try to do it for you by accident if you just ask for "CLOCK events" not "CLOCK event and clock high" (or low).
My reasoning is that another process would never get your old "dirty" memory with your key after a malloc. They would have to resort to spying in your memory in realtime.
There is no Unix I know of where you get another processes' dirty memory when you malloc. When malloc first gets it's memory from the OS (with sbrk) it is zero'ed (I think in thery it is merely "not valid data", but in practice it is zero'ed). If you free that memory and malloc it again it might contain your own dirty data. Similar things happen with mmap'ing annon memory, and/dev/zero (the other way malloc is implmented nowadays). In Net and FreeBSD the free'ed memory is frequently madvis;ed as unused and will not be written to swap unless it is written to again (and will tend to come back as zero, unless it is written again).
When I say "no Unix I know of" this includes V7 (or V6 -- what is it the Lyon's book covers?).
Could someone more in the know explain what encryption buys you that kernel-level zeroing doesn't?
Others have already said, but I'll state for completeness... If your system is seized by a hostle force (say your goverment, or it's a laptop, it could be a competeing bissness), the swap area could have cleartext passwords, or chunks of important documents. Of corse if you didn't encrypt your real data then there are other areas of intrest on the disk...
Yes, there _is_ FFT in MPG. It's Discrete Cosinus Transform (DCT).
Thanks for answering, but didn't the "get rid of" the DCT for MPEG2 because it was "too slow"? I'm pretty sure it is part of MPEG1 and JPEG, but not so clear on MPEG2.
To me, it's a glaring ommission to not have any string matching algorithms. In other words, where are the regular expressions?!?
Two reasons:
It's a engenering list, so if it doesn't directly help build bridges or blow them up, it ain't eliagable
Regular Expresions are a intresting bit of math that predates the computer. A lot of NFA/DFA work was done around the turn of the centrey. I think much of it before the turn of the centery (i.e. late 1800s!).
Which I found pretty bizzare, since I'm not aware of any good non-computer use of DFAs and NFAs, but I'm not much for non-computer things anyway...
Note, if you poke a bit farther in the dragon book there is a algo to construct a DFA directly from a regexp, without making the NFA first. I think the NFA->DFA also makes a more compact DFA though (and no, I don't recall the name either, and I just coded one up last year).
Also note, the dragon book is defintly not the end-all source of NFA/DFA/regex knolage. There is another book of Aho (and I think Ullman) that talks about more things, like it being an intractable problem to find the minimal regex to match a given set of symbols (exponantial in both space and time).
Are any of these algorithms related to things like compression algorithms (MP3, Zip, LZW, etc.),[...]
Not really. [...]
I'm pretty sure I saw an FFT when I was looking at the ISO reference MP3 encoder source (or maybe that was LAME, I forget). I think MPEG1, and JPEG do as well. I don't know if MPEG2 does. None of them have much to do with LZW...except the optimising FORTRAN compiler being the first step away from assembly for "serious work" did allow later languages like C...of corse if it hadn't been FORTRAN, it would have been something else.
I susspect anytime you see a spectrum eq, or a spectrum band display there is a FFT, so even if MP3 doesn't have one, WinAmp, and the WinAmp-like things for Unix probbably have them.
It is a shame they didn't list the Kolman Predictor. Great for turning messy Nth order control problems into, er, messy less then Nth order problems:-) It is also why a cheap ass servo in a $100 CD player can be positioned as well as the expensave steppers in the orignal $900 CD players (it really is a big cunk of hte cost reduction there). It also does intresting stock predictions for some trading firms. Oh, and it works great to figure out where to shoot a flamethrower too.
Two CPUs will outperform one single, large one when it comes to doing many tasks at once and the Power4 has the additional benefit that data can be exchanged between the two CPUs at a fairly high speed without leaving the processor core. The Power4s speciality is highly bandwith-intensive multithreaded applications, which will make it THE CPU for servers and the like.
That's one thery.
Another thery is making one CPU capable or running instrucitons from more then one stream in the same clock cycle and allowing it to choose which functional units get assigned to which thread on every clock will be faster. The Alpha 21364 designers obviously beleve in this thery, since that is how it works.
A simple thought exparament will show the multiple threads CPU is faster if it has all the functional units the multiple CPU on a die version has. Of corse if it is far simpler to put a whole bunch of CPUs on one die then to make a whole bunch of FUs for one CPU, then it might not be such a win.
Since both CPUs are due out next yearish I guess we can find out who is right then.
Personally I think the Alpha approch will win for the more common workloads we see today. But that the multi-CPU method will be far simpler to ramp up, and will win on more losely cuppled problems.
I may be totally wide of the mark here, but does this spell trouble for Palm?
The Aqua is 1.5 pounds, the Palm is lighter then a can of soda. The Aqua is the size of a sheet of paper (B4 paper), the screen alone is 7.5 inches. The Palm fits in my pocket. My shirt pocket if I'm not wearing a tee shirt. The Aqua's battries last about 7 to 8 hours. The Palm's battries last well over a month.
Either the Aqua sucks big rocks, or the Aqua is aimed at a totally diffrent set of problems.
Part of the Palm's success (I'd guess) was its appeal to nerds; and when one nerd brought his to a LUG, suddenly everyone else had to have one too.
I'll admit, they have a lot of geek appeal. But they have a broader base then that. My lawyer has one. My accountant has one (he promised me he only keeps names, phone numbers, and meeting times, not account numbers in it). The guy behind the desk at the car dealer thought it was cool, and was thinking of getting one "if only they were cheaper". Lots of executaves seem to have them. So I'de say the geeks arn't the big market segment there.
Of corse, fewer geeks would mean fewer after merket doo-dads for it. Certinally no more pocket Rouge.
PS oh, I want one. As well as my palm.
I thought so. I want one too. But it will never replace my Pilot (Visor actually). It's way too big. I might take it into boring meetings to fiddle around with (we have 802.11b at work). I'll use it at home, maybe. But it won't come to lunch with me. It won't go out on weekends. It won't even go into work every day.
I doubt anyone who has a Palm will stop using it after buying a Webpad.
P.S. the Moto 680x0 (or CPU32/DragonBall) in the Pilot is one of the few CPUs other then the x86 that the Crousoe could emulate quite well (similar ALU flags, Crousoe's 44ish registers are enough to deal witht he 16 in the 68010, and the non-IEEE FP in the Crouse won't stop it from emulating a CPU with no FP at all). So if push came to shove, Palm could "upgrade" to a Crosue. If they could solve the battrey problem -- the Crouse uses more then a DragonBall by a longshot. More even then the ARM which is what slashdot rand a bizzare story saying that's what Palm is going with.
I can't find a link to prove it, but I'm pretty sure that the 700 Mhx chip had Windows-specific optimizations while the 400Mhz (while not specifically optimized for Linux) was intended for Linux use.
The "Windows-specific" optimizations (according to IEEE Spectrum is merely support for the 16-bit operations. Apparently (a) Windows still has a ton of 16-bit code in performance critical areas, and (b) nobody at Transmeta realised it before their first CPU (the article said they were pretty much all Unix heads).
I find it a little supprising that they didn't do a better job of checking the dyanmic instruction mix of popular OSes and applications (maybe using bochs) before spinning Si, but what the hell.
In any even the 400Mhz CPU will run Windows (or anything else a x86 CPU can run), and so can the 700Mhz chip. It's just when running Linux (or any all 32bit OS) more of hte transistors of the 700Mhz part will go to waste, and while running Windows the 400Mhz CPU will spend more time in the slow part of the emulator...
I wonder which aggressive nation will be the first to attempt to take them over.
The 2nd article claims a group of germans tried (actually took the island, and then were later forced off it by Prince Roy, and some of his (I assume army) friends). More details in the article.
One could also assume the UK made an effort (I assume a rather half hearted, or accidental one) in 1968 as "two Trinity House officials complained that they had come under fire when approaching Roughs Tower." That was probbably about as much as the USA used as an excuse to get into Vietnam (two rifle holes in a Battleship -- if I remember correctly).
The first incident is more intresting as a Germen offical of some sort negoiated with Sealand to get one of their citizens back. Or maybe the second one was, as that is the one the Judge dismissed after accepting the claim that Sealand is not part of the UK.
Because they can make up laws as they go, I would assume this would also cover any data housed on the island.
They can make up (or change) laws. Any goverment can. But you seem to assume they have no laws allready.
According to some random web site google spat up they follow British Common Law and British Law of Contract. Which I beleve would make the GPL as valid there as in the UK.
Of corse they could change their minds, but so could any country. Even a democratic one. Ask anyone whose assets were frozen by the US goverment. Or whose bisness was nationalised in South America. You just have to ask yourself, do you trust Prince Roy?
No. 2.95.* releases are bugfix releases on 2.95. The new x86 backend will be coming out in 2.95 or 3.0, which ever comes first.
Ah! Yeah, that would make sense (other then you saying "2.95 or 3.0" when 2.95 is out...did you mean 2.96? or is there something about gcc release numbers that I don't understand?).
AFAIK, 2.95 also does not have the new i386 backend yet. However, I've seen no benchmarks on that, so I really don't know how it does.
According to the egcs/gcc news page from 2Sep99: Richard Henderson has finished merging the ia32 backend rewrite into the mainline GCC sources. The rewrite is designed to improve optimization opportunities for the Pentium II target, but also provides a cleaner way to optimize for the Pentium III, AMD-K7 and other high end ia32 targets as they appear.
That was post 2.95, and post 2.95.1, but before 2.95.2. Looking at the article it was using 2.95.2, so I assume it has the new x86 backend.
2.95.mumble-mumble also lacks most of the (deemed unstable or too hackish) optimizations from pgcc.
I think the issue they had with pgcc was it did a lot of x86 things at the machine independent level of gcc, and a lot of machine indepenedent things were in the x86 code (like branch prediction). A lot of the pgcc optimasations are in the new x86 backend, or were properly added to the machine independent code.
That is to say a lot of the stuff pgcc did someone re-did and put in gcc. Not all of it. And gc now does stuff I don't think pgcc does.
I don't know which is faster at this point, but I could beleve either. After all egcs got a whole lot of MI speedups that pgcc hasn't.
I'd be curious about the C++ allocation. I think some STL classes have a special allocator that's supposed to be faster than malloc (is new using the same allocator as malloc?).
C++'s new tends to be a thin layer over malloc. The STL allicator wasn't designed to be faster then new/malloc, but to deal with segment issues, shared memory issues, and maybe even object perminance.
The allicator SGI's STL (which gcc currently ships) allocates about 20 objects when you ask it to allocate, and doles them out one by one. That's for "small" objects. Anything over about half a K (or maybe 2K? I forget) goes through to new. This might be faster then 20 mallocs. Or not. Some mallocs are pretty good. Better then the STL allicator overhead. It does tend to reduce fragmentation. By a whole lot more then I expected.
If you don't like the default allicator, they are easy to write, and Alloc_malloc is allways ready to step in. There is even a #def to ask it to be used everywhere.
Gcc i386 optimizations have gotten much better lately. They recently integrated a new i386 backend (I don't think that was used in these tests, though.)
The test claimed to use some version of gcc 2.95.mumble-mumble. 2.95 has a lot of x86 improvments (and generic improvments!) from egcs. What 2.95 doesn't have, that the dev snapshots do is -mtune=k7 and -march=k7, which should have made the FP stuff go faster (scheduling for the PPro and running on a K7 isn't bad, but scheduling for the K7 and running on a K7 is better).
There is also some experimental code to do cach line prefetching, but I didn't follow the thread to see how it turned out (last I say it made the streams benchmark numbers twice as good, or better, but there was some concern that it might make other things slower).
When a JVM is launched, the maximum amount of memory it can use is set. Since the JVM uses garbage collection, it will eventually use all of this memory, whether it needs it or not. Most JVMs don't clean up after themselves until they have used up most of their available memory. This way garbage collection is more efficient since it is done less often.
Generational Garbage Collectors try to run a GC sweep after every X K of allocs (where X is about the size of the cache). They are quite a bit faster then most GCs that only collect when memory is critically low (memory accesses in cache are an order of magnitude faster then out of cache references). The downside is they GC more frequently, so rather then being "fast" for five minutes, and then a short pause, they nick you for a few 100ms all the damn time. Of course that is also an upside, they don't feel jerky.
Generational GC also tends to pack items allocated at the same time (and still live) together, which for many programs increases the locality of reference, and helps a whole hell of a lot if the system is paging.
I don't know how many JVMs use generational GC, but since it is a 70s Lisp technology, I can't imagine they use something worse. GC hasn't been a red hot research area, but it has had a lot of good work done in the last 20 years (and a lot more before that!)
I do know many JVMs run GC sweeps periodically if there is idle CPU (get a Java profiler, and check out the activity in the GC thread).
What the original post was complaining about was the "overhead" with each object. I'm not convinced that exists. I know every object has the equivalent of a C++ vptr (four bytes). Every object type has a virtual function table (possibly shared if it doesn't define new functions, or override any of the parent's), and a small description of the data fields, and the name of the type, and the function names and such.
That's a lot of crap -- say 400 bytes. Easily more then a simple structure (say a 2D point, 2 4 byte ints). If you have one point object, you probably have 100 times as much memory dedicated to describing the point object (in case you need to serialize it and send it via an RPC or something). But if you have 5000 points, the overhead of the meta data is vanishing low (400 bytes out of 40,400 bytes, 1%). Er, except for the vptrs (4 bytes on most systems), that'll bring it up to 20,400 overhead bytes for 60,400 total bytes or about 33%.
So for very simple objects Java does have a noticeable overhead. But for less simple objects the overhead is much smaller. If you compare any Java class with a C++ class that has virtual functions the per-instance overhead is identical. The per class overhead is different (with Java almost certainly having more overhead), but the per class overhead isn't interesting. There are not enough classes in most programs to make a difference (and believe it or not, with templates it's far easier to "accidentally" make 1000s of different classes in C++ then in Java).
That leaves arrays. C/C++ arrays need not have a length stored with them while Java ones do. Java is behind 4 bytes per array on that score. Relevant if you have lots of small arrays, irrelevant otherwise. Except....
You know C++ does need to know how many elements are in an array so it can call the destructor for each one (it can omit this, if there is no destructor, but I don't know of compilers that do that). So it doesn't beat Java, it ties.
...Oh, and C needs the length for dynamically allocated arrays (via malloc) so it can free them again. But it does win on static arrays.
Personally, I want a JVM that will only use as much memory it needs plus a "buffer" so it doesn't have to garbage collect every time I free something. It would probably just need to garbage collect every few seconds whether it needed it or not. It would sacrifice some performance for memory; therefore, it would be best of the client side and useless on the server side. I missing an existing one that does this?
Pretty much all of them if you make a thread that calls java.lang.runtime.gc() and then sleeps for a few seconds in a loop. Or even most of them (I think) if you merely have some idle CPU.
No Java VM garbage collects every time you free something. Where'd you get that idea? GC happens on a thread a regular intervals or when it's out of memory.
No Java VM doesn't have any defined tome to collect. Diffrent JVMs do it at diffrent times.
Most have a low pri thread that will GC either whenever it is runable (for GCs that are intrruptable), or when it has waited "long enough", or when "enough" memory is allocated. All JVMs I know of also GC when they are out of memory. Except for the Java subsets that don't GC at all (like SmartCard Java).
The one time Java doesn't GC as a rule is "when you free something", because it doesn't know when you free anything. There is no free operator. You can assign a pointer NULL, but that won't free the object unless that is the last pointer to it! Running a GC on every NULL (or other!) pointer assignment would be staggeringly expensave. Java could keep a reference count hint with each object (like Limbo does), but that has it's own problems (and advantages). I don't know of any JVM that does.
As for not being able to do what you want - all python imposes is that separate lines at the same block level must have the same indentation, and increasing levels have greater indentation w.r.t. their containing blocks. (The amount of indentation is up to you, and can vary.) I would be surprised if this is contrary to the vast majority of seasoned programmers' personal styles.
It is contraray to mine. I use an extra half-indent to indicate a continued line. Even in languages that require the backslash on the end of the last line. It is a pretty rare quirk, but I have seen other use it, and more importantly, it helps me a great deal when I look over code (as for avoiding long lines, that's hard with long typenames, and C/C++ functions decl syntax, esp. with C++'s constructor init-list syntax as well).
I have also seen a lot of code that uses "extra" spaces to line up parts of similar lines to emphisize similarity. Sometimes those spaces are before the first non-white space. This isn't something I do (I like moving the common parts into local const variables when I can, or macros, or I line them up but only after the first non-whitespace), so I won't miss it.
That said I don't hate Python. I dislike one feature. I can't think of a single language I use that doesn't have at least one feature I don't dislike. Sometimes even as strongly as Python preventing me from throwing in a bit of extra indentation where I think I need it.
I don't use it because I have plenty of mid-performance psudo-embedable languages in my toolbox allready (Perl, Tcl, sh). I have little need for another. Hell I have little enough need for the three I know! Mostly I'm stuck doing stuff that really needs to be in C (part of an existing C program -- like a device driver), or C++ (new program, but expected to be CPU bound, and pushed hard). A pity I can't get my boss to let me try Eifel for some production system.
what esperanto has, is less ambiguity, something which no computer language has at all...
Technically C has one ambiguity when looked at as a LALR grammer. I think it is a shift/reduce mixing braced and unbraced blocks with a nested if. Of corse they define it away, but outside the context of a strict LALR grammer.
Less nitpickey Perl has a number of ambiguities. Not in what the interpreter will do from run to run, but large gaps between what is defined, and what is implmented. Witness the Perl poems of Perl4 (the syntax tightened a bit for P5) . The trickyness of array vs. scalar context. The supprising, and only after the fact documented meaning of multiple "e flags" to a substitute.
On the slightly more nitpickey side, Perl's grammer can not be parsed by a YACCer, or any LALR parser. It needs huge amounts of context feed back from the interpreter (far more then C's typecasts force it to need). If you look at the.y file you'll see huge amounts of state chugged around.
If somone re-implmented Perl given only the existing documentation, it would have a huge number of diffrences from the existing Perl. Ones that would probbably break running code, and probbably more then half the time by reveling some construct the author was unaware of!
Note: I'm not saying Perl is bad. I use it a lot more then I use Python. But it is the least rigidly defined language I use. With the arguable exception of the shell (arguable in that all these "extensions" in the form of files with the x bit are laying about, and pooping into existance...)
Slashdot Mirror
The dummies arn't very stupid. There are a few varations of random, some "play oponets move+1", and some simplistic prediction systems. They are short, they are simple, but they ain't "rock, rock, rock...."
www.pix.com is one. Mugs, mouse pads, all kinds o stuff. crowded market, www.mymug.com use too as well, but they seem to be gone.
Some (most? a few?) airlines have power for portables in bissness class now. It requires a sort-of-cig-adaptor thing. Hopefully this trikkles down to coach which is what I have to fly...
Depends strongly on the portable, and even how you use it. If you use the disk (or CD ROM, or anything it has to spin, esp. spin fast) that sucks a whole lot of your power. If it has to use active cooling, then the fan will suck power too. The backlight (if in use) sucks a lot of power also. The CPU can be pretty low on that list. Or fairly high (the 650/500Mhz SpeedStep things can suck a fair amount of power, maybe more then the backlight!). The CPU also makes heat (as does the drive) which can make the fan spin....
If you look at a really simple portable like a Palm Pilot the backlight sucks most of the power, the CPU a distant second, and the DRAM a more distant third. AA rechargables last me over a month with no backlight use, about three weeks with a fair amount of backlight, or about 10 hours of dinking with "Pocket Life" with the backlight on (est from looking at the batt meter before and after 2 hours of said dinking). I've heard that it'll keep it's DRAM running for 2 or 3 months on "dead" battries.
The only thing that comes close is the Palm, and in part because you tend to turn it on, use it for three minutes, and turn it off for a while (what's that phone number? Gotta remember to get the car serviced this week. What time is it anyway? When is sunset today? [dee-DEE-dee-DEE-dee-DEE] Oh! Gotta run if I want to catch buffy tonight...). Still, it is a computer :-)
Heh. The Sony Z505JS (portable) has a fairly loud fan. Unless I go to the power profile thingie and ask for low fan noise (which seems to also get variable CPU speed) it is louder then my home machine. Of corse my home machine uses the all important PC Power and Cooling Silencer fan (I think it is a scroll cage fan). The CPU fan makes modestly more noise (with the case closed) then the real fan. Of corse disk chatter is louder then both those...so I have to make sure the MP3 player never stops :-)
Still it goes to show you can make quietish desktop machines with fans, and loud notebooks too.
It would be nice if there were enough demand for quiet fans on other parts of the machine too, if the CPU fan had a scroll cage I would be even happyer. Regretably scroll cage fans appear to be expensave. I don't know if that's because they are harder to make, or just in way less demand, so less compatation, so higer price, so less demand....
If you want a quiet machine, I urge you to check out the PC Power & Cooling fans (the silencer ones, not the turbo cool), and if anyone knows where to get quiet stuff cheaper, drop me a line.
RAMBUS is older then people think. It was around in 1992. I think the Alpha predates it by a little.
However the EV6 memory bus, the part that you think may be prior art is fairly new (1995 at the earylest? Not to market until '97 or '98?). As others have said using both edges of the clock isn't innovatave, RAMBus was just the first to use and try to patent it for use with memory.
Hell, VHDL will try to do it for you by accident if you just ask for "CLOCK events" not "CLOCK event and clock high" (or low).
There is no Unix I know of where you get another processes' dirty memory when you malloc. When malloc first gets it's memory from the OS (with sbrk) it is zero'ed (I think in thery it is merely "not valid data", but in practice it is zero'ed). If you free that memory and malloc it again it might contain your own dirty data. Similar things happen with mmap'ing annon memory, and /dev/zero (the other way malloc is implmented nowadays). In Net and FreeBSD the free'ed memory is frequently madvis;ed as unused and will not be written to swap unless it is written to again (and will tend to come back as zero, unless it is written again).
When I say "no Unix I know of" this includes V7 (or V6 -- what is it the Lyon's book covers?).
Others have already said, but I'll state for completeness... If your system is seized by a hostle force (say your goverment, or it's a laptop, it could be a competeing bissness), the swap area could have cleartext passwords, or chunks of important documents. Of corse if you didn't encrypt your real data then there are other areas of intrest on the disk...
Thanks for answering, but didn't the "get rid of" the DCT for MPEG2 because it was "too slow"? I'm pretty sure it is part of MPEG1 and JPEG, but not so clear on MPEG2.
Two reasons:
Which I found pretty bizzare, since I'm not aware of any good non-computer use of DFAs and NFAs, but I'm not much for non-computer things anyway...
Note, if you poke a bit farther in the dragon book there is a algo to construct a DFA directly from a regexp, without making the NFA first. I think the NFA->DFA also makes a more compact DFA though (and no, I don't recall the name either, and I just coded one up last year).
Also note, the dragon book is defintly not the end-all source of NFA/DFA/regex knolage. There is another book of Aho (and I think Ullman) that talks about more things, like it being an intractable problem to find the minimal regex to match a given set of symbols (exponantial in both space and time).
That's one thery.
Another thery is making one CPU capable or running instrucitons from more then one stream in the same clock cycle and allowing it to choose which functional units get assigned to which thread on every clock will be faster. The Alpha 21364 designers obviously beleve in this thery, since that is how it works.
A simple thought exparament will show the multiple threads CPU is faster if it has all the functional units the multiple CPU on a die version has. Of corse if it is far simpler to put a whole bunch of CPUs on one die then to make a whole bunch of FUs for one CPU, then it might not be such a win.
Since both CPUs are due out next yearish I guess we can find out who is right then.
Personally I think the Alpha approch will win for the more common workloads we see today. But that the multi-CPU method will be far simpler to ramp up, and will win on more losely cuppled problems.
The Aqua is 1.5 pounds, the Palm is lighter then a can of soda. The Aqua is the size of a sheet of paper (B4 paper), the screen alone is 7.5 inches. The Palm fits in my pocket. My shirt pocket if I'm not wearing a tee shirt. The Aqua's battries last about 7 to 8 hours. The Palm's battries last well over a month.
Either the Aqua sucks big rocks, or the Aqua is aimed at a totally diffrent set of problems.
I'll admit, they have a lot of geek appeal. But they have a broader base then that. My lawyer has one. My accountant has one (he promised me he only keeps names, phone numbers, and meeting times, not account numbers in it). The guy behind the desk at the car dealer thought it was cool, and was thinking of getting one "if only they were cheaper". Lots of executaves seem to have them. So I'de say the geeks arn't the big market segment there.
Of corse, fewer geeks would mean fewer after merket doo-dads for it. Certinally no more pocket Rouge.
I thought so. I want one too. But it will never replace my Pilot (Visor actually). It's way too big. I might take it into boring meetings to fiddle around with (we have 802.11b at work). I'll use it at home, maybe. But it won't come to lunch with me. It won't go out on weekends. It won't even go into work every day.
I doubt anyone who has a Palm will stop using it after buying a Webpad.
P.S. the Moto 680x0 (or CPU32/DragonBall) in the Pilot is one of the few CPUs other then the x86 that the Crousoe could emulate quite well (similar ALU flags, Crousoe's 44ish registers are enough to deal witht he 16 in the 68010, and the non-IEEE FP in the Crouse won't stop it from emulating a CPU with no FP at all). So if push came to shove, Palm could "upgrade" to a Crosue. If they could solve the battrey problem -- the Crouse uses more then a DragonBall by a longshot. More even then the ARM which is what slashdot rand a bizzare story saying that's what Palm is going with.
The "Windows-specific" optimizations (according to IEEE Spectrum is merely support for the 16-bit operations. Apparently (a) Windows still has a ton of 16-bit code in performance critical areas, and (b) nobody at Transmeta realised it before their first CPU (the article said they were pretty much all Unix heads).
I find it a little supprising that they didn't do a better job of checking the dyanmic instruction mix of popular OSes and applications (maybe using bochs) before spinning Si, but what the hell.
In any even the 400Mhz CPU will run Windows (or anything else a x86 CPU can run), and so can the 700Mhz chip. It's just when running Linux (or any all 32bit OS) more of hte transistors of the 700Mhz part will go to waste, and while running Windows the 400Mhz CPU will spend more time in the slow part of the emulator...
If you look at the 80s publicity shot it looks like they have had a helipad for some time now.
The 2nd article claims a group of germans tried (actually took the island, and then were later forced off it by Prince Roy, and some of his (I assume army) friends). More details in the article.
One could also assume the UK made an effort (I assume a rather half hearted, or accidental one) in 1968 as "two Trinity House officials complained that they had come under fire when approaching Roughs Tower." That was probbably about as much as the USA used as an excuse to get into Vietnam (two rifle holes in a Battleship -- if I remember correctly).
The first incident is more intresting as a Germen offical of some sort negoiated with Sealand to get one of their citizens back. Or maybe the second one was, as that is the one the Judge dismissed after accepting the claim that Sealand is not part of the UK.
They can make up (or change) laws. Any goverment can. But you seem to assume they have no laws allready.
According to some random web site google spat up they follow British Common Law and British Law of Contract. Which I beleve would make the GPL as valid there as in the UK.
Of corse they could change their minds, but so could any country. Even a democratic one. Ask anyone whose assets were frozen by the US goverment. Or whose bisness was nationalised in South America. You just have to ask yourself, do you trust Prince Roy?
Ah! Yeah, that would make sense (other then you saying "2.95 or 3.0" when 2.95 is out...did you mean 2.96? or is there something about gcc release numbers that I don't understand?).
According to the egcs/gcc news page from 2Sep99: Richard Henderson has finished merging the ia32 backend rewrite into the mainline GCC sources. The rewrite is designed to improve optimization opportunities for the Pentium II target, but also provides a cleaner way to optimize for the Pentium III, AMD-K7 and other high end ia32 targets as they appear.
That was post 2.95, and post 2.95.1, but before 2.95.2. Looking at the article it was using 2.95.2, so I assume it has the new x86 backend.
I think the issue they had with pgcc was it did a lot of x86 things at the machine independent level of gcc, and a lot of machine indepenedent things were in the x86 code (like branch prediction). A lot of the pgcc optimasations are in the new x86 backend, or were properly added to the machine independent code.
That is to say a lot of the stuff pgcc did someone re-did and put in gcc. Not all of it. And gc now does stuff I don't think pgcc does.
I don't know which is faster at this point, but I could beleve either. After all egcs got a whole lot of MI speedups that pgcc hasn't.
C++'s new tends to be a thin layer over malloc. The STL allicator wasn't designed to be faster then new/malloc, but to deal with segment issues, shared memory issues, and maybe even object perminance.
The allicator SGI's STL (which gcc currently ships) allocates about 20 objects when you ask it to allocate, and doles them out one by one. That's for "small" objects. Anything over about half a K (or maybe 2K? I forget) goes through to new. This might be faster then 20 mallocs. Or not. Some mallocs are pretty good. Better then the STL allicator overhead. It does tend to reduce fragmentation. By a whole lot more then I expected.
If you don't like the default allicator, they are easy to write, and Alloc_malloc is allways ready to step in. There is even a #def to ask it to be used everywhere.
The test claimed to use some version of gcc 2.95.mumble-mumble. 2.95 has a lot of x86 improvments (and generic improvments!) from egcs. What 2.95 doesn't have, that the dev snapshots do is -mtune=k7 and -march=k7, which should have made the FP stuff go faster (scheduling for the PPro and running on a K7 isn't bad, but scheduling for the K7 and running on a K7 is better).
There is also some experimental code to do cach line prefetching, but I didn't follow the thread to see how it turned out (last I say it made the streams benchmark numbers twice as good, or better, but there was some concern that it might make other things slower).
D'oh! Sorry, we appear to be in violent agreement. Sorry.
Generational Garbage Collectors try to run a GC sweep after every X K of allocs (where X is about the size of the cache). They are quite a bit faster then most GCs that only collect when memory is critically low (memory accesses in cache are an order of magnitude faster then out of cache references). The downside is they GC more frequently, so rather then being "fast" for five minutes, and then a short pause, they nick you for a few 100ms all the damn time. Of course that is also an upside, they don't feel jerky.
Generational GC also tends to pack items allocated at the same time (and still live) together, which for many programs increases the locality of reference, and helps a whole hell of a lot if the system is paging.
I don't know how many JVMs use generational GC, but since it is a 70s Lisp technology, I can't imagine they use something worse. GC hasn't been a red hot research area, but it has had a lot of good work done in the last 20 years (and a lot more before that!)
I do know many JVMs run GC sweeps periodically if there is idle CPU (get a Java profiler, and check out the activity in the GC thread).
What the original post was complaining about was the "overhead" with each object. I'm not convinced that exists. I know every object has the equivalent of a C++ vptr (four bytes). Every object type has a virtual function table (possibly shared if it doesn't define new functions, or override any of the parent's), and a small description of the data fields, and the name of the type, and the function names and such.
That's a lot of crap -- say 400 bytes. Easily more then a simple structure (say a 2D point, 2 4 byte ints). If you have one point object, you probably have 100 times as much memory dedicated to describing the point object (in case you need to serialize it and send it via an RPC or something). But if you have 5000 points, the overhead of the meta data is vanishing low (400 bytes out of 40,400 bytes, 1%). Er, except for the vptrs (4 bytes on most systems), that'll bring it up to 20,400 overhead bytes for 60,400 total bytes or about 33%.
So for very simple objects Java does have a noticeable overhead. But for less simple objects the overhead is much smaller. If you compare any Java class with a C++ class that has virtual functions the per-instance overhead is identical. The per class overhead is different (with Java almost certainly having more overhead), but the per class overhead isn't interesting. There are not enough classes in most programs to make a difference (and believe it or not, with templates it's far easier to "accidentally" make 1000s of different classes in C++ then in Java).
That leaves arrays. C/C++ arrays need not have a length stored with them while Java ones do. Java is behind 4 bytes per array on that score. Relevant if you have lots of small arrays, irrelevant otherwise. Except....
You know C++ does need to know how many elements are in an array so it can call the destructor for each one (it can omit this, if there is no destructor, but I don't know of compilers that do that). So it doesn't beat Java, it ties.
...Oh, and C needs the length for dynamically allocated arrays (via malloc) so it can free them again. But it does win on static arrays.
Pretty much all of them if you make a thread that calls java.lang.runtime.gc() and then sleeps for a few seconds in a loop. Or even most of them (I think) if you merely have some idle CPU.
No Java VM doesn't have any defined tome to collect. Diffrent JVMs do it at diffrent times.
Most have a low pri thread that will GC either whenever it is runable (for GCs that are intrruptable), or when it has waited "long enough", or when "enough" memory is allocated. All JVMs I know of also GC when they are out of memory. Except for the Java subsets that don't GC at all (like SmartCard Java).
The one time Java doesn't GC as a rule is "when you free something", because it doesn't know when you free anything. There is no free operator. You can assign a pointer NULL, but that won't free the object unless that is the last pointer to it! Running a GC on every NULL (or other!) pointer assignment would be staggeringly expensave. Java could keep a reference count hint with each object (like Limbo does), but that has it's own problems (and advantages). I don't know of any JVM that does.
It is contraray to mine. I use an extra half-indent to indicate a continued line. Even in languages that require the backslash on the end of the last line. It is a pretty rare quirk, but I have seen other use it, and more importantly, it helps me a great deal when I look over code (as for avoiding long lines, that's hard with long typenames, and C/C++ functions decl syntax, esp. with C++'s constructor init-list syntax as well).
I have also seen a lot of code that uses "extra" spaces to line up parts of similar lines to emphisize similarity. Sometimes those spaces are before the first non-white space. This isn't something I do (I like moving the common parts into local const variables when I can, or macros, or I line them up but only after the first non-whitespace), so I won't miss it.
That said I don't hate Python. I dislike one feature. I can't think of a single language I use that doesn't have at least one feature I don't dislike. Sometimes even as strongly as Python preventing me from throwing in a bit of extra indentation where I think I need it.
I don't use it because I have plenty of mid-performance psudo-embedable languages in my toolbox allready (Perl, Tcl, sh). I have little need for another. Hell I have little enough need for the three I know! Mostly I'm stuck doing stuff that really needs to be in C (part of an existing C program -- like a device driver), or C++ (new program, but expected to be CPU bound, and pushed hard). A pity I can't get my boss to let me try Eifel for some production system.
Technically C has one ambiguity when looked at as a LALR grammer. I think it is a shift/reduce mixing braced and unbraced blocks with a nested if. Of corse they define it away, but outside the context of a strict LALR grammer.
Less nitpickey Perl has a number of ambiguities. Not in what the interpreter will do from run to run, but large gaps between what is defined, and what is implmented. Witness the Perl poems of Perl4 (the syntax tightened a bit for P5) . The trickyness of array vs. scalar context. The supprising, and only after the fact documented meaning of multiple "e flags" to a substitute.
On the slightly more nitpickey side, Perl's grammer can not be parsed by a YACCer, or any LALR parser. It needs huge amounts of context feed back from the interpreter (far more then C's typecasts force it to need). If you look at the .y file you'll see huge amounts of state chugged around.
If somone re-implmented Perl given only the existing documentation, it would have a huge number of diffrences from the existing Perl. Ones that would probbably break running code, and probbably more then half the time by reveling some construct the author was unaware of!
Note: I'm not saying Perl is bad. I use it a lot more then I use Python. But it is the least rigidly defined language I use. With the arguable exception of the shell (arguable in that all these "extensions" in the form of files with the x bit are laying about, and pooping into existance...)