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

ARM vs x86

Name: Anonymous 2011-10-21 5:04

What software absolutely needs the x86 performance from the user and programmer  perspective? Why can't we switch to ARM even if it was ~4 times slower but much cheaper?

Name: Cudder !MhMRSATORI!FBeUS42x4uM+kgp 2011-10-21 5:08

Two words: backwards compatibility

Name: Anonymous 2011-10-21 5:10

>>2
That's only one word, huh.

Name: Anonymous 2011-10-21 5:12

>>3
Thats 23 bytes or 6 words.

Name: Anonymous 2011-10-21 5:55

>>1
Speaking in absolute terms, only software with realtime requirements that cannot be satisfied by the slower system. In more practical terms, any software you don't want to waste time waiting on.

Name: Anonymous 2011-10-21 7:00

>>5
From user perspective anything, even a 1Mhz game with no pause will be real-time, but at video encoding will be noticeable delays.
ARM still has performance gap for concrete number crunching, but not for interactive stuff like games, which can be optimized to run even on Raspberry Pi.

Name: Anonymous 2011-10-21 7:16

What software absolutely needs Worse is Better from the user and programmer  perspective? Why can't we switch to Lisp Machines even if it was ~4 times less retarded but much convenient?

Name: Anonymous 2011-10-21 7:40

I endorse this thread as a former Acorn Archimedes and Risc PC owner

Name: Anonymous 2011-10-21 8:18

>>7
LISP machines were for slow LISP code, ARM are for everything.

Name: Anonymous 2011-10-21 8:22

>>9
ARM supports type tags and GC?

Name: Anonymous 2011-10-21 8:27

>>10
Explain why type tags can't be done with software efficiently?

Name: Anonymous 2011-10-21 8:32

>>11
Explain why 3d rendering can't be done with software efficiently?

Name: Anonymous 2011-10-21 8:34

>>12
Actually, it can. All good recent graphics cards only use hardware for bytecode interpretation and texture interpolation.

Name: Anonymous 2011-10-21 8:37

>>13
Ok. Implement following type-dispatcher, so it'll execute at the speed of C/C++ int addition

(defun add-fixnums (A B)
  (let* ((hash (or (shl (get-tag A) tag-bits) (get-tag B)))
         (h (aref handlers hash)))
    (funcall h A B)))

Name: Anonymous 2011-10-21 8:40

>>12
type tags are much simpler. 3D rendering is huge pipeline of memory intensive vector code,transforms over arrays,etc.
It can be done with tight SSE code but the result is of entry-level video card.

Name: Anonymous 2011-10-21 8:41

>>6
What the fuck are you on about and what the fuck does it have to do with the post you were replying to? If a real-time system can't satisfy its time constraints it does not work. The fact that they managed to get a 12-year old game running on some vaporware toy is irrelevant.

Name: Anonymous 2011-10-21 8:42

Name: Anonymous 2011-10-21 8:44

>>17
Your answer shows that you're out of viable arguments. I will interpret it as your surrender.

Name: Anonymous 2011-10-21 8:45

>>15
Ok. Division is simple. Implement it in software, using only NAND operator.

Name: Anonymous 2011-10-21 8:47

>>16
Realtime is just a software capability, a 1Mhz cpu can be realtime with proper software.

Name: Anonymous 2011-10-21 8:55

>>17
Why printf(typeof(A)) doesnt work?

Name: Anonymous 2011-10-21 8:55

>>21
doesnt work
If it ain't Lisp, it's crap.

Name: Anonymous 2011-10-21 9:00

>>22
you mena?
If it's crap, it's Lisp.
ya i thawt so

Name: Anonymous 2011-10-21 9:03

>>23
gb2g

Name: Anonymous 2011-10-21 9:18

>>14

mine is faster, ````````````faggo''''''''''''


typedef enum {
  A,
  B,
  C,
  D,
  E,
  F } type_tag;

struct A {
  type_tag type;
  ...
};

struct B {
  type_tag type;
  ...
};

struct C {
  type_tag type;
  ...
};

struct D {
  type_tag type;
  ...
};

struct E {
  type_tag type;
  ...
};

struct F {
  type_tag type;
  ...
};






typedef void (*bin_op) (type_tag*, type_tag*, void*);

// not supported
void bin_op_ns(type_tag*, type_tag*, void* ) {
  assert(0);
}

static bin_op add_handlers[][] = {
// A        B         C         D          E          F
{  add_A_A, add_A_B, add_A_C , bin_op_ns, bin_op_ns, add_A_F}, // A
{  add_B_A, add_B_B, add_B_C , add_B_D,   bin_op_ns, bin_op_ns}, // B
{  add_C_A, add_C_B, add_C_C , bin_op_ns, bin_op_ns, bin_op_ns}, // C
{  bin_op_ns, add_D_B, bin_op_ns, add_D_D, bin_op_ns, bin_op_ns}, // D
{  bin_op_ns, bin_op_ns, bin_op_ns, bin_op_ns, add_E_E, add_E_F}, // E
{  add_F_A, bin_op_ns, bin_op_ns, bin_op_ns, add_F_E, add_F_F} }; // F

void add(type_tag* arg1, type_tag* arg2, void* ret ) {
  add_handlers[*arg1][*arg2](arg1, arg2, ret);
}

Name: Anonymous 2011-10-21 9:23

Why does every thread in this board get overrun with lispers

Name: Anonymous 2011-10-21 9:25

Name: Anonymous 2011-10-21 9:42

>>26
They feel guilty for using such a shitty language so they take it out on other people.

Name: Anonymous 2011-10-21 9:52

>>20
Again, what's the fucking relevance? If the 1MHz processor is too slow to complete the realtime task within the set time constraints, it's too slow and you must pick a faster one.

Name: Anonymous 2011-10-21 10:06

>>25
Is it faster than raw assembly?

Name: Anonymous 2011-10-21 10:07

>>30
Is assembly faster than handcoded AMD microcode?

Name: not >>1-29 2011-10-21 10:08

>>26
There's just enough of us here. You don't see most of us asking why there are so many C users (or insert other popular language here). Lisp is popular enough on this board, so you have enough Lisp-related discussion, at the same time there seem to be haters because they are looking at code they don't understand and that frustrates them.

Name: Anonymous 2011-10-21 10:12

>>31
Yep! It isnt, cause C/C++ is a static pile of shit.

Name: LISP HATER 2011-10-21 10:16

>>32
I understand Lisp code just fine, and I often find myself rewriting it in     Blub    to prove how unreadable the Lisp version is.

Name: Anonymous 2011-10-21 10:19

>>32


(lisp (has many legitimate) issues)
      (funcall #'and (quirks that make it)
                     (kindof ,@difficult to 'use ,(and read)))
      (I can 't speak for everyone)
      but
      (I think many people here have probably tried lisp)
      (only to realize that many of it 's features)
      (are implemented more elegantly in other ,@more mainstream and (funcall #'popular languages))
      (lisp is nice but it is very old ,@and maybe (CALL-NEXT-METHOD) doesn 't seem to be very well thoughtout as whole)
      (It seems more like an experimental language ,@made when current modern techniques where experimental))

Name: Anonymous 2011-10-21 10:28

>>35
Comma not inside backquote.

Name: Anonymous 2011-10-21 10:30

>>36

I also messed up the parenthesis on the first line.

Name: Anonymous 2011-10-21 10:36

>>35
You seem to be talking about Common Lisp (and CLOS), whose purpose was to unify the most popular Lisps at time, and did it fairly well*.
Saying that all Lisps are the same is like saying that C is the same as C++ is the same as ObjC is the same as D. They share common traits and syntax, but they're completely different languages.
The various quotes are not that difficult to understand. ' marks literal data, ` is just like ', but parts of it can be evaluated with unquotes: ,expr simply evaluates expr at runtime, and its result is added to the list, ,@ is just like ,, but the result must be a list whose elements are spliced inside the quasiquoted list. #' denotes a procedure used in a ``simple value'' context in CL.

* Hell, it may be a frankenstein monster, but there were so many Lisps out there at that time that it's a miracle that it didn't become like C++, which just tried to extend C with class-based OOP.

Name: Anonymous 2011-10-21 10:44

>>38

Yeah, that was just about my experiences with common lisp. I like using scheme myself, although I prefer lisp's defmacro.

Name: Anonymous 2011-10-21 10:51

>>38
Hell, it may be a frankenstein monster, but there were so many Lisps out there at that time that it's a miracle that it didn't become like C++, which just tried to extend C with class-based OOP.
Common Lisp is weird but I think it's a great language and most of its potential mistakes can be forgiven thanks to macros. IMO the only valid reasons to reject Common Lisp would be its size and garbage collection.
For Bjarne's defense, he extended C nearly alone, while Common Lisp was designed by a team of EXPERT PROGRAMMERS.

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