More, bigger registers for 64 bit, not 32 bit
on
AMD's 64-bit Plot
·
· Score: 1
The additional registers and the wider register sizes do nothing for 32 bit applications running in the AMD's 32 bit x86 mode. A wider data bus will probably benefit 32 bit apps, but other than that, to get the *full* benefit of an AMD-64, you'll need applications recompiled for the AMD-64 bit instruction set.
That's the same as for the Intel Itanium. The AMD-64 architecture has two HUGE differences from the Intel Itanium setup:
1) the AMD-64 instruction set is a rather minor modification/rearrangement of the traditional x86 opcodes. That means existing x86 optimizing compilers should be able to produce AMD-64 executables in a matter of days, compared to the years it's taking to get decent Itanium codegen compilers.
2) The AMD-64 runs 32 bit apps in hardware 32 bit mode concurrently with 64 bit apps and OS running in hardware 64 bit mode. The Itanium doesn't get anywhere close to that - At best, 32 bit x86 code is emulated (slowly!) in software microcode on the Itanium chip.
If AMD can produce 64 bit chips that run 32 bit software as fast or faster than current 32 bit processors, at a price point near the high-end 32 bit processor prices, AMD will mop the floor with Itanium...
Anyone who actually read the referenced sys-con article would notice two things:
a) The article contains no factual reference to Comdex attendence (except a headline quoted from slashdot, which itself is a headline quoting the sys-con article...) and
b) The author of the sys-con article has been slighted by the Comdex press club
How better for an unknown journalist to "get even" with Comdex? Toss a misleading headline at a high-traffic site like Slashdot! "Nobody at slashdot will actually notice my fiendish ploy! Muwhahaha"
You need a car adapter. They work okay though my adapter overheated on AA last month -
That might be because you need a voltage regulator called an In Flight Adapter ("AirPort") to convert the 24v or higher power source from the plane to the lower voltage required by your laptop. The power outlet may look like a car cigarette lighter, but it's not.
US FAA regulations require that cellular phones and all other radio broadcast devices must be turned off for the *entire* flight, from when the cabin door is closed to when the cabin door is opened at the destination.
Nice try, but you're still on crack.;> The Delphi source code and unit support found in Borland C++ Builder is provided by the Delphi compiler, *not* by a C++ compiler that also has a Pascal parser. Go look in your bin directory - there is both a BCC executable and a DCC executable (dll). That's been the case in every release of C++Builder.
And, if we are really lucky, we'll see Borland making their.so's compatible with rest of the Linux community.
Borland's.so's are already compatible with the rest of the Linux system. Kylix produces and uses Linux standard ELF.so library files. The Kylix RTL relies heavily on glibc (libc.so) and libpthread.so. Why would a C++ from Borland be any different?
If you don't like the editor key bindings/behaviors in Delphi or C++Builder, write your own editor key binding module for the IDE. The source code for the emacs editor keybinding module is included in the products as demo + documentation.
The Borland C++ 5.5 compiler (free download from borland.com) is at least 6 years old, extracted from the original BC++ MSDOS/Win32 product. It's not the same compiler as the currently shipping Borland C++ Builder 5.0. If you're going to compare BC++ 5.5 to GCC, compare it to GCC 0.9x of the same era.
Cox didn't say he wasn't selling out. I'm sure he'll profit nicely from whatever stock swap AOL offers for RH. He's got to have RH options up the wazoo, and in many cases options vest instantly (become exerciseable) when there is a change of ownership or control of the company.
Borland has said that the Kylix 2 Open Edition will be available online "soon". They usually do time-locked evaluation editions and the Open Edition a few weeks after the primary product is released.
Sorry for not RTFM but I don't think I'll find an answer there that I can trust there anyway..
You could download the Kylix Open Edition and see for yourself. If you can't trust your own eyes, why bother?
If I develop an application in Kylix, will it require proprietary libs?
Nope. You can build non-GUI apps (console apps, Apache DSO modules, etc) in Kylix with no external library requirements other than the system-standard libc and libpthread. The only deployment requirement is that the target system have a modern version of the glibc libraries installed - version 2.2 is best, but 2.1.2 and 2.1.3 with patches also work. (Source diffs for the libdl patches for glib 2.1.2 and 2.1.3 are included on the Kylix CD)
If you build GUI apps with Kylix, you will need to deploy a QT interface library, and QT itself if it's not already on the target machine.
3. Much of the core of the compiler is highly optimized, with much of the critical portion written in finely tuned assembly language.
None of the Delphi/Kylix compiler is written in assembler. Borland says it's written in plain old C. Asm gives you incremental performance boosts in general. Design is where you get orders of magnitude performance gains.
The NEC Ultralite just looks like an oversized Sony Picturebook. The Picturebook also uses the Transmeta chip, but has been shipping for more than two months now. The picturebook is smaller and lighter with the same processing power and battery life (longer, actually) as this NEC machine. The only thing to ooh and ahhh about on the NEC machine is that it has a built-in NIC.
Declaring variables at the start of a function is NOT a good programming practice. It is, however, a good way to ensure that you forget to delete them once you remove the associated code - and then you have a wasted variable declaration.
Oh please. As if any self-respecting optimizing compiler (such as Kylix) isn't going to strip out unused variables?
I see a trend where people start in a RAD environment languages like VB and VB script, and now Java and Kylix without any fundamental computer concepts. They've never developed in lower level languages like C. They do not have even slightest, general understanding of microprocessors, RAM, stack, heap, pointers, memory allocation/deallocation, memory leaks and so on.
The trend is not new. It's what created and fueled the PC revolution. Back in the days of the IBM PC and XT, the CEO of DEC stated flatly that DEC would not waste time on developing a PC because there was no reason for a worker to have a PC on their desk, since all real software should be run (and developed) in the controled environment of a big iron mainframe. The market success of the PC caught IBM by surprise - the PC was not being bought by the engineers IBM expected, it was being bought by non-engineers, non-technicals, people who didn't fit the IT profile.
The vast majority of PC users have never had technical understanding of a PC, just as the vast majority of automobile users have never had technical understanding of how their car is built or what makes it go.
To further the analogy: Just as the vast majority of people who adjust ignition timing or change carbuerators do not have formal training in mechanical engineering or auto repair, the vast majority of people who write software are not formally trained ivory tower CS or IT druids. Programming is not part of the job description of most people who buy software development tools. They write code or scripts or spreadsheet macros to help them get their actual job done.
Should such accidental coders attempt to write an OS, or an inventory management system? Certainly not. But that does not mean that they should be shunned or spat upon by ivory tower elitists.
The existance of software development tools that can be used by the common man is not a threat to the technical superiority of the uber-geeks. So get over it already.
When notifying the benchmark author about this issue, he simply replied that he expects most users NOT to checkout any possible optimizations. If a user cares about speed, why would not he try to explore such possibilities? Or was the benchmark author just lazy, trying to cram as many languages into his little benchmark as possible?
The benchmark author has demonstrated "reviewer's syndrome" - that most people who review software (well, anything really) don't take the time to understand the subject in question. They make qualitative judgements based on first impressions instead of based on solid experience and understanding of the product. It's about as effective as asking an Amish farmer to review a high performance sports car.
It' not just an academic discussion - anticipating that reviewers will probably not take the time to select optimizations appropriate to their test cases, most commercial compiler vendors set the default compiler options to perform well in superficial benchmarks, even though that isn't what most customers will actually use the compiler for.
People have gone to jail for receiving illegal porn they claim they never requested. If a postal inspector doesn't like you, they can drop a package in your mailbox and you go to jail.
Um... NT does run on Alpha in 32 bit mode. Not that it helps much since practically nothing else besides the OS runs on Alpha. Even Microsoft didn't bother to port their own apps to Alpha.
NT runs on Alpha in 64 bit mode. The Alpha chip doesn't have a 32 bit mode. The NT kernel only recognizes the low 32 bits of pointer values for the normal kernel-managed page-swapped virtual address space, but native compiled Alpha apps can access more than the 2GB of data by calling special allocator functions in a support library shipped with the Alpha version of NT. Memory above the 32 bit address space is not page swapped, it must reside in physical RAM.
Other than the memory addres space being squished to 32 bit for normal apps, native compiled code running under NT on the Alpha chip is fully 64 bit code.
Yes, application availability was a major stumbling block for the Alpha back in the days when DEC was grooming it to be a major contender. However, I seem to recall that MS SQL Server was available as a native executable on the Alpha, and of course all the server chunks that shipped with the OS were native, such as COM, DCOM, and IIS. Solitare and the Space Cadet pinball game also ran native. I'm pretty sure there was an Alpha version of MS Word as well.
The only reason NT 4.0 for Alpha didn't make it out of beta was that Compaq laid off the DEC staff in residence at Microsoft that did the actual work of porting and supporting NT on Alpha. NT has run on several hardware platforms over the years, but the only one done by Microsoft was the Intel version of NT. MIPS, Alpha, and PowerPC versions of NT were all funded by the hardware vendor in one way or another.
There are various reasons this may not work well, but I was thinking... why not simply add the version number into the name of the library file, and have the program coded to look for that library.
Great idea. Linux already works like that.
Programs are supposed to be built to bind to shared object libraries using the general release number in the.so file name, like libfoo.so.2.1. That file should be a symlink to the actual specific version that implements the 2.1 spec, such as libfoo.so.2.1.5.95-35b. When a "better" implementation of the.so library is released, the symlinks can be updated to point libfoo.so.2.1 to the new libfoo.so.2.1.6 library.
The assumption is, whoever revectors that libfoo.so.2.1 symlink to point to a newer (or older!) implementation version will ensure that the new implementation is 100% compatible with the 2.1 "spec", whatever that is, including continuing to support bugs in the 2.1 implementations that some applications rely on or have workarounds for that will break when the bug is removed.
Some have suggested reversing the bind convention so that programs bind to the most specific version number of so's that they need, which can be revectored via symlinks to the implementations that support what they need. In practice, this only makes matters worse (by increasing the number of "versions" and symlinks) and in the end you have exactly the same problem - which implementation will work with this program?
None of the library management proposals on Linux or on Windows successfully deals with the problem of bozo developers (or bozo distros) deploying libraries with the wrong version numbers. The latest KDE deploys a stripped down version of the QT library, using the same filename (version) as the full-featured QT library. That causes all sorts of pain for apps that require the "real" QT lib.
Same goes for libgd.so. At some point, the developers of libgd.so decided to drop all GIF support from the library. Fine, whatever. But did they rev the library version number when they did that? No! So if you've got an app that wants to use the GIF functions in the old libgd.so, that app can't run in the same environment as an app that wants to use the new libgd.so's completely different PNG replacement functions. Total idiocy! At a minimum, the non-GIF rev of the libgd.so should have bumped the version number to the next whole number, indicating a major revision that might not be backwards compatible. That's what they were supposed to do, and if they had then old and new apps could run side by side using the old and new libgd.so implementations.
How many Kylix jobs are out there on the market?
none
Wrong. Kylix skills are Delphi skills. Demand for Delphi coders is outstripping supply. Borland has enjoyed some success lately in drawing VB developers into the Borland camp, capitalizing on Microsoft's VB /.NET incompatibilty fiasco.
With kylix, an HR person or phb interviewing you will say "Kylix! What the hell is that?".
Those people would respond the same way to Perl, PHP, Python, ObjectiveC, and 98% of all other development tools on the Linux platform that aren't C++ or Java.
Bottom line: The best tool for the job is rarely what the mob mentality is jawing about. Judge a tool on its merits, not it's glam factor.
"My point being is that mechanical things wear out. "
Solid state things wear out, too. There's this little thing called "ion migration" that occurs inside IC chips. Microfractures caused by thermal stresses within the chip allow metal ions to migrate off the circuit paths, growing metallic "hairs" between the paths. Eventually, the hairs reach another conductor and short-circuit the chip.
Overclocking and excessive heat or heat cycling (hot/cold/hot) accelerate ion migration.
So, don't be so sure about solid state stuff lasting forever. It may last longer than a spinning disk, but it too will fail eventually.
Slashdot Mirror
The additional registers and the wider register sizes do nothing for 32 bit applications running in the AMD's 32 bit x86 mode. A wider data bus will probably benefit 32 bit apps, but other than that, to get the *full* benefit of an AMD-64, you'll need applications recompiled for the AMD-64 bit instruction set.
That's the same as for the Intel Itanium. The AMD-64 architecture has two HUGE differences from the Intel Itanium setup:
1) the AMD-64 instruction set is a rather minor modification/rearrangement of the traditional x86 opcodes. That means existing x86 optimizing compilers should be able to produce AMD-64 executables in a matter of days, compared to the years it's taking to get decent Itanium codegen compilers.
2) The AMD-64 runs 32 bit apps in hardware 32 bit mode concurrently with 64 bit apps and OS running in hardware 64 bit mode. The Itanium doesn't get anywhere close to that - At best, 32 bit x86 code is emulated (slowly!) in software microcode on the Itanium chip.
If AMD can produce 64 bit chips that run 32 bit software as fast or faster than current 32 bit processors, at a price point near the high-end 32 bit processor prices, AMD will mop the floor with Itanium...
-mazor
a) The article contains no factual reference to Comdex attendence (except a headline quoted from slashdot, which itself is a headline quoting the sys-con article...) and
b) The author of the sys-con article has been slighted by the Comdex press club
How better for an unknown journalist to "get even" with Comdex? Toss a misleading headline at a high-traffic site like Slashdot! "Nobody at slashdot will actually notice my fiendish ploy! Muwhahaha"
Congratulations. You've been used, Slashdot.
That might be because you need a voltage regulator called an In Flight Adapter ("AirPort") to convert the 24v or higher power source from the plane to the lower voltage required by your laptop. The power outlet may look like a car cigarette lighter, but it's not.
-mazor
Listen to the stewardess next time!
-mazor
Wardialing? Never heard of that. We called it daemon dialing, and that was long before the movie "War Games" came out.
-mazor
-mazor
Borland's .so's are already compatible with the rest of the Linux system. Kylix produces and uses Linux standard ELF .so library files. The Kylix RTL relies heavily on glibc (libc.so) and libpthread.so. Why would a C++ from Borland be any different?
-mazor
If you don't like the editor key bindings/behaviors in Delphi or C++Builder, write your own editor key binding module for the IDE. The source code for the emacs editor keybinding module is included in the products as demo + documentation.
-mazor
The Borland C++ 5.5 compiler (free download from borland.com) is at least 6 years old, extracted from the original BC++ MSDOS/Win32 product. It's not the same compiler as the currently shipping Borland C++ Builder 5.0. If you're going to compare BC++ 5.5 to GCC, compare it to GCC 0.9x of the same era.
-mazor
Cox didn't say he wasn't selling out. I'm sure he'll profit nicely from whatever stock swap AOL offers for RH. He's got to have RH options up the wazoo, and in many cases options vest instantly (become exerciseable) when there is a change of ownership or control of the company.
-mazor
Well, that would make lightspeed much more convenient, now wouldn't it?
-mazor
Borland has said that the Kylix 2 Open Edition will be available online "soon". They usually do time-locked evaluation editions and the Open Edition a few weeks after the primary product is released.
If you build GUI apps with Kylix, you will need to deploy a QT interface library, and QT itself if it's not already on the target machine.
-mazor
Probably because HTML based search tools they tested couldn't handle the hundreds of thousands of help topics in the Kylix online help index.
HTML help is nice in concept, but for quick searching on your local machine the available tools are pretty awful.
-mazor
-mazor
The NEC Ultralite just looks like an oversized Sony Picturebook. The Picturebook also uses the Transmeta chip, but has been shipping for more than two months now. The picturebook is smaller and lighter with the same processing power and battery life (longer, actually) as this NEC machine. The only thing to ooh and ahhh about on the NEC machine is that it has a built-in NIC.
-Mazor
Oh please. As if any self-respecting optimizing compiler (such as Kylix) isn't going to strip out unused variables?
We're in the 21st century here. Try to keep up.
--mazor
The trend is not new. It's what created and fueled the PC revolution. Back in the days of the IBM PC and XT, the CEO of DEC stated flatly that DEC would not waste time on developing a PC because there was no reason for a worker to have a PC on their desk, since all real software should be run (and developed) in the controled environment of a big iron mainframe. The market success of the PC caught IBM by surprise - the PC was not being bought by the engineers IBM expected, it was being bought by non-engineers, non-technicals, people who didn't fit the IT profile.
The vast majority of PC users have never had technical understanding of a PC, just as the vast majority of automobile users have never had technical understanding of how their car is built or what makes it go.
To further the analogy: Just as the vast majority of people who adjust ignition timing or change carbuerators do not have formal training in mechanical engineering or auto repair, the vast majority of people who write software are not formally trained ivory tower CS or IT druids. Programming is not part of the job description of most people who buy software development tools. They write code or scripts or spreadsheet macros to help them get their actual job done.
Should such accidental coders attempt to write an OS, or an inventory management system? Certainly not. But that does not mean that they should be shunned or spat upon by ivory tower elitists.
The existance of software development tools that can be used by the common man is not a threat to the technical superiority of the uber-geeks. So get over it already.
--mazor
The benchmark author has demonstrated "reviewer's syndrome" - that most people who review software (well, anything really) don't take the time to understand the subject in question. They make qualitative judgements based on first impressions instead of based on solid experience and understanding of the product. It's about as effective as asking an Amish farmer to review a high performance sports car.
It' not just an academic discussion - anticipating that reviewers will probably not take the time to select optimizations appropriate to their test cases, most commercial compiler vendors set the default compiler options to perform well in superficial benchmarks, even though that isn't what most customers will actually use the compiler for.
--mazor
People have gone to jail for receiving illegal porn they claim they never requested. If a postal inspector doesn't like you, they can drop a package in your mailbox and you go to jail.
NT runs on Alpha in 64 bit mode. The Alpha chip doesn't have a 32 bit mode. The NT kernel only recognizes the low 32 bits of pointer values for the normal kernel-managed page-swapped virtual address space, but native compiled Alpha apps can access more than the 2GB of data by calling special allocator functions in a support library shipped with the Alpha version of NT. Memory above the 32 bit address space is not page swapped, it must reside in physical RAM.
Other than the memory addres space being squished to 32 bit for normal apps, native compiled code running under NT on the Alpha chip is fully 64 bit code.
Yes, application availability was a major stumbling block for the Alpha back in the days when DEC was grooming it to be a major contender. However, I seem to recall that MS SQL Server was available as a native executable on the Alpha, and of course all the server chunks that shipped with the OS were native, such as COM, DCOM, and IIS. Solitare and the Space Cadet pinball game also ran native. I'm pretty sure there was an Alpha version of MS Word as well.
The only reason NT 4.0 for Alpha didn't make it out of beta was that Compaq laid off the DEC staff in residence at Microsoft that did the actual work of porting and supporting NT on Alpha. NT has run on several hardware platforms over the years, but the only one done by Microsoft was the Intel version of NT. MIPS, Alpha, and PowerPC versions of NT were all funded by the hardware vendor in one way or another.
--mazor
Great idea. Linux already works like that.
Programs are supposed to be built to bind to shared object libraries using the general release number in the .so file name, like libfoo.so.2.1. That file should be a symlink to the actual specific version that implements the 2.1 spec, such as libfoo.so.2.1.5.95-35b. When a "better" implementation of the .so library is released, the symlinks can be updated to point libfoo.so.2.1 to the new libfoo.so.2.1.6 library.
The assumption is, whoever revectors that libfoo.so.2.1 symlink to point to a newer (or older!) implementation version will ensure that the new implementation is 100% compatible with the 2.1 "spec", whatever that is, including continuing to support bugs in the 2.1 implementations that some applications rely on or have workarounds for that will break when the bug is removed.
Some have suggested reversing the bind convention so that programs bind to the most specific version number of so's that they need, which can be revectored via symlinks to the implementations that support what they need. In practice, this only makes matters worse (by increasing the number of "versions" and symlinks) and in the end you have exactly the same problem - which implementation will work with this program?
None of the library management proposals on Linux or on Windows successfully deals with the problem of bozo developers (or bozo distros) deploying libraries with the wrong version numbers. The latest KDE deploys a stripped down version of the QT library, using the same filename (version) as the full-featured QT library. That causes all sorts of pain for apps that require the "real" QT lib.
Same goes for libgd.so. At some point, the developers of libgd.so decided to drop all GIF support from the library. Fine, whatever. But did they rev the library version number when they did that? No! So if you've got an app that wants to use the GIF functions in the old libgd.so, that app can't run in the same environment as an app that wants to use the new libgd.so's completely different PNG replacement functions. Total idiocy! At a minimum, the non-GIF rev of the libgd.so should have bumped the version number to the next whole number, indicating a major revision that might not be backwards compatible. That's what they were supposed to do, and if they had then old and new apps could run side by side using the old and new libgd.so implementations.
-mazor
Wrong. Kylix skills are Delphi skills. Demand for Delphi coders is outstripping supply. Borland has enjoyed some success lately in drawing VB developers into the Borland camp, capitalizing on Microsoft's VB / .NET incompatibilty fiasco.
Those people would respond the same way to Perl, PHP, Python, ObjectiveC, and 98% of all other development tools on the Linux platform that aren't C++ or Java.
Bottom line: The best tool for the job is rarely what the mob mentality is jawing about. Judge a tool on its merits, not it's glam factor.
-mazor
Visual Basic
FoxBase
QuickPascal (never made it to version 2.0)
Microsoft Fortran (yes, there was an MS Fortran)
Microsoft orphans products faster than it acquires them.
-mazor
Solid state things wear out, too. There's this little thing called "ion migration" that occurs inside IC chips. Microfractures caused by thermal stresses within the chip allow metal ions to migrate off the circuit paths, growing metallic "hairs" between the paths. Eventually, the hairs reach another conductor and short-circuit the chip.
Overclocking and excessive heat or heat cycling (hot/cold/hot) accelerate ion migration.
So, don't be so sure about solid state stuff lasting forever. It may last longer than a spinning disk, but it too will fail eventually.
-mazor