Mmmm. And you've fallen for the notion that Microsoft is actually writing DirectX's core APIs *in*.NET, have you? Bull Honky..NET is getting an API to DirectX and certain high-level, non-performance-related elements of DirectX may be written in.NET libraries for.NET programs only. There is no relevant difference between this and jogl.
You're a twit, and I'm done with you. Go read a book on computer science.
This is for all those kids who are learning chords on their guitars -- be ready to pay fees for practicing 'Smoke On The Water.'
Gotta love those posters who don't understand basic copyright law. Practicing is not performance.
Copyright law has always granted songwriters the rights to performance of their art. In fact, this used to be the primary right demanded by musical artists, back when performance was the main form of deriving money from their work. And it's still a big deal. Madonna has no right to make big-time $$$ playing a song I wrote.
Where this falls down is the composers' guild trying to get money from things like Happy Birthday, which has clearly fallen into the public domain. But Beatles songs have not, and they clearly fall under copyright violation in the US as in Japan.
NPR is using taxpayer money to broadcast under legally licensed channels. XM is violating those channels illegally, ruining them for listeners. NPR is trying to prevent them from doing this. How is this harassment again?
.NET is a far distance from JAVA, at least.NET can pull credible performance out of its engine.
Care to back up that ridiculous implication (that.NET is much more efficient than Java) with even a modicum of evidence?
3) You are correct, MS is no longer an issue, but on the same front, JAVA is no longer an issue as well. JAVA development is at an all time low in the industry for serious development where you see.NET used on everything from Web Servers to even even performance areas like DirectX9 - again something JAVA just can't reach.
Oh, man, that was funny. Thanks, I needed some humor today.
Oh, wait this was serious? I guess I should expect as much from someone who thinks "JAVA" is an acronym.
Compare this to Python or Ruby or Java or Perl, where there is not only a standard, but a benchmark program which every implementation must be bug-for-bug compatable with. That's when you start seeing real portability.
Actually, no. Most of these languages don't _have_ a standard, only an implementation.
Hmmm, both Python and Java have formal specifications easily found on the web. So your usage of "most" requires some... mathematical flexibility. But granted, I'm not sure if either Ruby of Perl have specs.
I still think my main point hasn't been addressed: Scheme has failed to catch on because there's no hegemon. No formal spec that everyone must implement and is sufficient for most real programming tasks (no need for RFIs like -- holy cow -- hash tables). And no reference implementation that anyone and everone can recompile on their own system, spreading the goodness rapidly. Instead we're stuck with lots of independent, widely varying Scheme implementations, mutually incompatable on which crazy subset of crucial RFIs they implement, and some of which implement R5, some R4 or IEEE, some have the full numerical tower, some don't, some have full continuations, some don't, on and on.
There are many Scheme implementations, some tiny, some slow, some fast, some with extensive libraries, some which interface to other programming languages, etc. etc.
IMHO, this is precisely why Scheme has failed to catch on in the Lisp community. There really isn't a standard: there are a series of standards and a whole lot of RFIs, and every Scheme system implements its own subset. It's amazingly frustrating building a portable Scheme program. Common Lisp has fewer, more stringent standards, and is much more compatable across implementations. A lack of standard socket libraries notwithstanding.:-( Compare this to Python or Ruby or Java or Perl, where there is not only a standard, but a benchmark program which every implementation must be bug-for-bug compatable with. That's when you start seeing real portability.
I got tenure with a two-page CV. And when I was on a selection panel for a postdoctoral reesearcher, the successful applicant had a two-page CV. The next best two applicants had 2-3 page CVs, and the least qualified had 8 pages of filler.
I've seen a fair number of CVs in my time and not one tenure CV has been less than five pages. Sounds like you're from a "special" school.:-):-)
Postdocs have 2-page CVs all the time. That's because many of them were just grad students with four publications. [Though I (and most of my grad students) had at least twenty good publications on graduation, most first-authored. Not easy to fit that on two pages -- perhaps this is unusual].
An academic resume shouldn't be much longer than a normal resume. If you've written 150 peer-reviewed journal articles, say so, and list only the top 10 in full. If you've only written ten papers, consider only listing the top 5 in full.
Now there's a guaranteed way for someone to not get a job as an assistant professor. CVs are trimmed by senior people who are famous enough to not need to list their little poster publications. But your advice should apply to no one else. A typical CV is eight pages long.
I was once told that CV length grows, then shrinks during one's life. A grad student's CV is probably two pages long. Then it baloons up to 15 pages when you're applying for tenure. Full professors start trimming their CVs, all the way up to God, who has a CV that just says "hey, it's me."
Not sure why this was modded 4:informative. What resume is called in Europe is immaterial. In the US, "regular" workers have resumes; artists of various kinds have portfolios; and academics and scientists have CVs. A CV is a resume, plus a long list of your publications, received grants, awards and honors, teaching experience, graduate students and graduates, etc., that demonstrate your prowess as a researcher or professor.
Processes are patentable. The drug company's method for producing the drug from the vine is the patentable item. All the aborigines have to do is develop a different process, and they're in the money too.
Re:you don't know what you're talking about...
on
Apple's Growing Pains
·
· Score: 1
My AMD X2 4200+ has massive power savings modes, it changes its voltage from 1.1V to 1.4V, it changes its speed from 1GHz to 2.2GHz. But it never actually turns one core off either.
You're armchair theorizing on this and you don't even have a Mac?
The original Macintosh used a Motorola 68000, which was 16 bit internally (16 bit ALUs, 16 bit data bus, 16 bits of address space accessible at a time, 16 bit instructions), albeit with addresses stored as 32 bits in preparation for later 32 bit models.
Last time I coded assembly on a 68000, it had a 32-bit address space and 32-bit general-purpose registers. From a software point of view, it had both 32-bit and 16-bit words. How is this not a 32-bit processor? Who cares what the ALU or data bus actually did?
I must totally agree with the article: Apple's fascination with Vista IS childish. I mean, why in the world would Apple be obsessed with Microsoft's new operating system? It's not like Vista won't have 90% of the desktop market within the next four years or anything. Oh, wait...
I think it's relatively easy to see that the problem isn't coil buzz: keep both cores enabled, and fire up a job that blasts one core. You're heavily taxing the machine, and yet you still have the whine. Now disable the second core. Whine goes away instantly. Now drop the job. Whine still gone. Now reenable the core. Whine comes back. Now fire up tiny jobs on both cores. Whine goes away instantly.
The problem is not power draw. The problem is usage of the second core. It's the sleep mode Apple picked. If Apple had just shut off power to the core, like the CHUD tools do, the whine problem would never have existed. But Apple's Java VM crashes when a second core appears out of nowhere. They probably were (and are) being lazy.
I meant it was a trivial fix in the sense that it reliably and straightforwardly fixes the problem. I didn't say it was an acceptable approach. Apple's had eight months since the introduction of these machines and they still haven't automated turning the processor cores off when unneeded.
It's well known what the whine is. When one of the cores is not in use, the MacBook Pro puts it in a low-power sleep mode. The mode Apple picked was a bad one and it casuses the processor to whine. When both cores are being used, no sound. It's trivial to kill the whine too. Just install the Apple CHUD tools, which includes a CPU preference pane and menu. Using the menu, select "Single CPU" instead of "Dual CPU", which disables the CPU entirely.
Cache misses are the big deal. If you're continually allocating new, cache cold memory for new objects, rather
than reusing the hot memory as it logically becomes free (and instead wait for it to cool down as it goes
through a GC cycle), then you're increasing cache misses. This is a bad thing.
It is indeed: but it's not nearly as bad as people claim. Because machines don't dump items into cache by the byte. They dump them by the block. And GC allocations are all done in the same block. Additionally, good GC systems do allocations of new objects in incubators where the cache is hot. Thanks for playing.
Let me clarify this: number of allocations is fairly immaterial since allocation cost is the same as just doing a stack allocation. It's the number of deallocations and moves that gets ya.
Slashdot Mirror
Still won't be able to compete with the sheer density of colored symbols on A4 paper.
My understanding was that much of Google was in python.
Mmmm. And you've fallen for the notion that Microsoft is actually writing DirectX's core APIs *in* .NET, have you? Bull Honky. .NET is getting an API to DirectX and certain high-level, non-performance-related elements of DirectX may be written in .NET libraries for .NET programs only. There is no relevant difference between this and jogl.
You're a twit, and I'm done with you. Go read a book on computer science.
Copyright law has always granted songwriters the rights to performance of their art. In fact, this used to be the primary right demanded by musical artists, back when performance was the main form of deriving money from their work. And it's still a big deal. Madonna has no right to make big-time $$$ playing a song I wrote.
Where this falls down is the composers' guild trying to get money from things like Happy Birthday, which has clearly fallen into the public domain. But Beatles songs have not, and they clearly fall under copyright violation in the US as in Japan.
NPR is using taxpayer money to broadcast under legally licensed channels. XM is violating those channels illegally, ruining them for listeners. NPR is trying to prevent them from doing this. How is this harassment again?
Perhaps part of the XM-NPR anymosity stems from the fact that their respective headquarters are within walking distance of one another.
Oh, wait this was serious? I guess I should expect as much from someone who thinks "JAVA" is an acronym.
Sounds like it.
Hmmm, both Python and Java have formal specifications easily found on the web. So your usage of "most" requires some... mathematical flexibility. But granted, I'm not sure if either Ruby of Perl have specs.
I still think my main point hasn't been addressed: Scheme has failed to catch on because there's no hegemon. No formal spec that everyone must implement and is sufficient for most real programming tasks (no need for RFIs like -- holy cow -- hash tables). And no reference implementation that anyone and everone can recompile on their own system, spreading the goodness rapidly. Instead we're stuck with lots of independent, widely varying Scheme implementations, mutually incompatable on which crazy subset of crucial RFIs they implement, and some of which implement R5, some R4 or IEEE, some have the full numerical tower, some don't, some have full continuations, some don't, on and on.
IMHO, this is precisely why Scheme has failed to catch on in the Lisp community. There really isn't a standard: there are a series of standards and a whole lot of RFIs, and every Scheme system implements its own subset. It's amazingly frustrating building a portable Scheme program. Common Lisp has fewer, more stringent standards, and is much more compatable across implementations. A lack of standard socket libraries notwithstanding. :-( Compare this to Python or Ruby or Java or Perl, where there is not only a standard, but a benchmark program which every implementation must be bug-for-bug compatable with. That's when you start seeing real portability.
I've seen a fair number of CVs in my time and not one tenure CV has been less than five pages. Sounds like you're from a "special" school. :-) :-)
Postdocs have 2-page CVs all the time. That's because many of them were just grad students with four publications. [Though I (and most of my grad students) had at least twenty good publications on graduation, most first-authored. Not easy to fit that on two pages -- perhaps this is unusual].
I was once told that CV length grows, then shrinks during one's life. A grad student's CV is probably two pages long. Then it baloons up to 15 pages when you're applying for tenure. Full professors start trimming their CVs, all the way up to God, who has a CV that just says "hey, it's me."
Not sure why this was modded 4:informative. What resume is called in Europe is immaterial. In the US, "regular" workers have resumes; artists of various kinds have portfolios; and academics and scientists have CVs. A CV is a resume, plus a long list of your publications, received grants, awards and honors, teaching experience, graduate students and graduates, etc., that demonstrate your prowess as a researcher or professor.
Processes are patentable. The drug company's method for producing the drug from the vine is the patentable item. All the aborigines have to do is develop a different process, and they're in the money too.
It's not like it's exactly hard to get off your butt and see that you don't know what you're talking about here.
If they had any brains, they'd have first taken the laptop to Anchorhead to have its memory erased, and that'd be the end of it.
I must totally agree with the article: Apple's fascination with Vista IS childish. I mean, why in the world would Apple be obsessed with Microsoft's new operating system? It's not like Vista won't have 90% of the desktop market within the next four years or anything. Oh, wait...
The problem is not power draw. The problem is usage of the second core. It's the sleep mode Apple picked. If Apple had just shut off power to the core, like the CHUD tools do, the whine problem would never have existed. But Apple's Java VM crashes when a second core appears out of nowhere. They probably were (and are) being lazy.
I meant it was a trivial fix in the sense that it reliably and straightforwardly fixes the problem. I didn't say it was an acceptable approach. Apple's had eight months since the introduction of these machines and they still haven't automated turning the processor cores off when unneeded.
It's well known what the whine is. When one of the cores is not in use, the MacBook Pro puts it in a low-power sleep mode. The mode Apple picked was a bad one and it casuses the processor to whine. When both cores are being used, no sound. It's trivial to kill the whine too. Just install the Apple CHUD tools, which includes a CPU preference pane and menu. Using the menu, select "Single CPU" instead of "Dual CPU", which disables the CPU entirely.
Let me clarify this: number of allocations is fairly immaterial since allocation cost is the same as just doing a stack allocation. It's the number of deallocations and moves that gets ya.