Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Why Modern Code is Slow

Name: Anonymous 2021-04-14 18:55

Because of the entire security nonsense, modern linkers do not support the classic statically linked executables, which were superfast. So all code is compiled the PIE bloatware. Of course that crap goes on top of already slow MMU and meltdown/spectre fixes (which are just an excuse to sell your new CPU). Remember these old COM files? They were ridiculously fast, compared to the modern ELF garbage, where just the header takes more space than the code itself.

Remember: security experts are the consumer's biggest enemies. Common people don't care about security, they care only about apps running fast, liek they used to run in C64.

Name: Anonymous 2021-04-14 18:58

Oh, and the Java/C# nigger code will also have to compile the application the first run. Why? Of course to sell you the new overpriced hardware! Otherwise you would still be using some old Amiga, because it is fast enough.

Name: Anonymous 2021-04-15 10:27

the Internet was a mistake

Name: Anonymous 2021-04-15 14:35

Ted Cockzynski was right about the Industrial Revolution.

Name: Anonymous 2021-04-15 19:03

>>4
His position was focused on the negative aspects, not overall life quality.
Anprim can't support much people to a level barely above starvation,
basically 'The Road' scenario. Without tech civilization is unsustainable and
will collapse hard: the survivors will have to adapt to bronze age level life quality or perish.

Name: Anonymous 2021-04-15 20:01

>>5
Good. Only the strong shall survive; subhumans be damned.

Name: Anonymous 2021-04-15 20:24

That's why everyone should program in Rust. It's guaranteed to be secure.

Name: Anonymous 2021-04-15 22:47

Rewrite GNU/Emacs in Rust!

Name: Anonymous 2021-04-15 22:54

What are you talking about? Programs are faster than ever. You can run things you wouldn't have dreamed of just 20 years ago. If you're writing programs smaller than the ELF header, then you're not making anything interesting. Unfortunately security is a necessary tradeoff for anything networked.

Name: Anonymous 2021-04-15 23:25

>>9
Programs are faster than ever.

Only if you use GPU. Common CPU have reached the frequency cap. Like physical one. We wont ever see a THz CPU. A few gains were mostly to improving the basic architecture (i.e. switching to MIPS-style design) and using the additional transistors to hardcode stuff like division tables, all while c64 CPU didn't even had a division opcode.

Name: Anonymous 2021-04-16 0:11

There's far more to performance improvement than just feature size and frequency scaling. The first few things (not comprehensive) that come to mind: pipelining, branch prediction, cache optimizations. I'd take a modern processor over a 6502 on a new process hitting the same clock frequency any day. If anything these improvements play to your preference for speed over security because they're at fault for all the high profile hardware vulnerabilities in recent years. To get back to the original topic: shitty slow code is nothing new. People used to actually write things in basic on their c64. I believe that there are better tools and more information out there, and the average program is better written today than ever before, but maybe that's a little too optimistic.

Name: Anonymous 2021-04-16 18:11

>>11
The first few things (not comprehensive) that come to mind: pipelining, branch prediction, cache optimizations.

These are the minor architecture things, which require some work on part of programmer and compiler designer, not the true hardware frequency improvements. I.e. they wont ever make you computer work faster than the 10 GHz (still unobtainable speed even by the most hardcore overclockers). The only real improvement comes in the form of quantum computers, but these are applicable only to a limited set of problems, some of which are already solvable by throwing more GPUs, and wont give you back the cycles stolen by MMU, address space randomization, and other management layers. Many processes are inherently sequential, therefore can be improved with GPUs or quantum computers, only with faster clock rate.

Name: Anonymous 2021-04-16 18:13

>>12
https://www.anandtech.com/show/680/6
Realistically speaking, we should be able to see NetBurst based processors reach somewhere between 8 – 10GHz in the next five years before the architecture is replaced yet again. Reaching 2GHz isn’t much of a milestone, however reaching 8 – 10GHz begins to make things much more exciting than they are today. Obviously this 8 – 10GHz clock range would be based on Intel’s 0.07-micron process that is forecasted to debut in 2005. These processors will run at less than 1 volt, 0.85v being the current estimate.

Name: Anonymous 2021-04-16 18:53

>>10
Modern CPUs have pretty beefy vector instructions.

Name: Anonymous 2021-04-16 21:38

>>14
Vector instructions wont speed up your C++ compilation. And 64-bit data types will only slow it down, due to double pressure on memory bus, which sometimes runs at half the CPU frequency.

Name: Anonymous 2021-04-17 1:43

>>12
Calling pipelining a "minor architectural thing" shows you are woefully ignorant on the topic of CPU design. Maybe come back to this conversation after you have designed a processor ;-). Yes single core performance is plateauing, but there are very few workloads that are entirely sequential AND not currently I/O bound. Computer industry thrives on the "easy" performance gains, and I foresee at least a lifetime's worth of meaningful improvements, even if they aren't in areas I expect today.

Name: Anonymous 2021-04-17 6:41

nerds

Name: Anonymous 2021-04-17 10:56

>>16
Pipelining is not as fundamental as herz count, or the transistor size. It is in fact, pipeline is the part of application, making assumptions on what the code will do, so as an effect it makes some code faster, while other code becomes slower. On the other end, we have hardware used by engineers and scientists to, say, detect particles, and it has totally different architecture, working as fast as currently possible, with any delays reduced to bare minimum.

Name: Anonymous 2021-04-17 12:07

Naughty >>17
Enamored
Radiant
Dedicated
Sisters https://gelbooru.com/index.php?page=post&s=view&id=3268176

Name: Anonymous 2021-04-17 12:22

>>10
We wont ever see a THz CPU
https://www.extremetech.com/extreme/193343-darpa-creates-first-1thz-computer-chip-earns-guinness-world-record
As you can imagine, though, it’s hard to build a chip that’s capable of switching on and off one trillion times per second. That seems to be the main breakthrough here: DARPA, working with Northrop Grumann, have built a 10-stage monolithic amplifier using fairly standard CMOS processes. Exact details aren’t available, but I believe the chip is fabricated out of indium phosphide (InP), which is capable of switching at much higher frequencies (and at higher power levels) than common semiconductors such as silicon or gallium arsenide.
Official PR image for DARPA's World Record 1THz chip

Official PR image for DARPA’s World Record 1THz chip. Yup.

The DARPA/Northop chip reportedly has excellent properties, with a gain of 9dB at 1THz, and 10dB at 1.03THz. “Gains of six decibels or more start to move this research from the laboratory bench to practical applications — nine decibels of gain is unheard of at terahertz frequencies” says Dev Palmer, DARPA’s THz Electronics program manager. “This opens up new possibilities for building terahertz radio circuits.”

Name: Anonymous 2021-04-17 13:00

>>20
That THz chip is a not a general purpose CPU. At best they will prduce a few transistors device, that will be used as a part of some sensor in some lab.

So yeah, it makes sense to design a modern no-MMU operating system, and start practicing assembly, because "smart enough compiler" is still a running joke. Just like Hitler, Terry Davis was right about some things.

Name: Anonymous 2021-04-17 13:25

>>19 virus

Name: Anonymous 2021-04-17 22:53

Vibrant >>22
Incestuous
Resplendent
United
Sisters https://danbooru.donmai.us/posts/1840606

Name: Cudder !cXCudderUE 2021-04-18 0:46

"security" and idiots (i.e. "diversity/inclusion" tards) who don't know anything about actual programming.

Name: Anonymous 2021-04-18 2:51

>>23 virus

Name: Anonymous 2021-04-18 17:48

>1
Is there any way to statically link now?
The Unreal Tournament binary for Linux was statically linked; still works to this day.
Anything compiled for linux only works on the distro it was compiled for.
GCC won't allow static linking as far as I can tell: there's no "static link this all" switch IIRC.

Name: Anonymous 2021-04-18 17:51

>12
The military had 100GHZ CPUs in the 70s. (Not using silicon, gallium arsenide)
They aren't increasing it because they don't want civillians to have the power.
Same reason they don't allow you to have machine guns, no matter what their "founding fathers" said.

Name: Anonymous 2021-04-18 17:55

>>memory bus, which sometimes runs at half the CPU frequency.
Really? Why?

Name: Anonymous 2021-04-18 18:00

Name: Anonymous 2021-04-18 18:47

>9
>Unfortunately security is a necessary tradeoff for anything networked.
Security doesn't exist in linux without grsecurity (which is violating the linux copyright license by adding additional terms when distributing)

Name: Manual Reading Enthusiast 2021-04-18 20:20

>>26
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Link-Options.html#index-static
$ cat a.c
#include <stdio.h>

int main(int argc, char ** argv) {
printf("Hello world!\n");
return 0;
}
$ gcc a.c -static -o a
$ file a
a: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2582ab1b2a50a677d32d3b311a2c4a2e2227a3c0, for GNU/Linux 4.4.0, not stripped
$ ldd a
not a dynamic executable

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List