Why can't we have a computer like Amiga?

[Thorham]

Originally Posted by Mrs Beanbag

Well, it depends how basic. If it is a fixed size and you can guarantee no collisions, it is very simple. If it can dynamically grow, you have to think about different strategies. And just the hash function can range from simple to complex.

Fixed size with collisions and a simple hash algorithm. In C that's not complex at all, while it's already very effective.

[meynaf]

Originally Posted by Mrs Beanbag

If you use polymorphic classes, you are using RTTI. Or at least if you ever use dynamic_cast.

I didn't ever use dynamic_cast. In fact i didn't use polymorphism much - i had very few needs for it and it ain't good for performance.

Originally Posted by Mrs Beanbag

ok. i have no idea, to be honest! i have wanted a PNG decoder for Amiga though, it strikes me as a convenient format to store my game data in, since it's much more efficient than ILBM and then i can create the graphics on anything.

Does it fully implement the PNG format, with all modes and colour depths?

I don't remember the exact details, but it does implement everything that's useful for an aga fullscreen picture viewer, i.e. it ignores transparency and converts 16 bit rgb (48 bits) to 8 bit rgb (24 bits).
All normal images are shown ; only malformed files will be rejected.

And, yes, someone here may try to inject code in an image to take control of the machine, using an exploit in my code

There is certainly free code available to decode these (this is where you will see that it's not as efficient as it looks ).

Originally Posted by Mrs Beanbag

Are you sure it is not just because old hard drives outlive new ones? They seem to have become terribly unreliable these days, a computer i built a few years ago had a hard drive fail recently and i was looking for a replacement and realised consumer drives now only come with 1 year warranties! It used to be 3 year warranties were standard. I guess they just don't care any more. It went downhill when they went over 500Gb i think, manufacturers were in such a competition for data density. Samsung had big problems with their platters and ended up having to limit drives to 5400 rpm for reliable operation.

Also temperature is a consideration. I keep my own PC very cool, and it is not very high-powered. There was a study that showed reliability decreased with increasing temperature. Gaming PCs can get very hot inside...

I am only using enterprise grade HDDs from now on and hang the expense.

Or SSDs... but for 2Tbs of SSD you are talking serious money.

Of course old drives outlive new ones, but nevertheless, i don't think many peecees from 2001, running nearly every day, have reached 2015 with the same hd...

[meynaf]

Originally Posted by Thorham

Fixed size with collisions and a simple hash algorithm. In C that's not complex at all, while it's already very effective.

A hash is quite easy in asm as well. This is what PhxAss does for label handling (making a sizeable part of its speed).

[Thorham]

Originally Posted by meynaf

A hash is quite easy in asm as well. This is what PhxAss does for label handling (making a sizeable part of its speed).

Indeed, but you should see it in C, it's almost nothing.

[meynaf]

Originally Posted by Thorham

Indeed, but you should see it in C, it's almost nothing.

A hash has no interest apart its speed. Why wasting it with C ?

[Mrs Beanbag]

"simple" hash table, vs hash table with full functionality in C++ stl...

https://gcc.gnu.org/onlinedocs/libst...le-source.html

*eyes bleed*

Originally Posted by meynaf

A hash has no interest apart its speed. Why wasting it with C ?

If C is slower than Asm then you definitely want to be using an efficient algorithm!

[meynaf]

Originally Posted by Mrs Beanbag

If C is slower than Asm then you definitely want to be using an efficient algorithm!

Normally if you use C, speed isn't an issue.

[Mrs Beanbag]

Originally Posted by meynaf

Normally if you use C, speed isn't an issue.

What absolute twaddle!

[meynaf]

Originally Posted by Mrs Beanbag

What absolute twaddle!

When you will have disassembled as much compiled code as i have, you'll know better.

[Megol]

Originally Posted by meynaf

Normally if you use C, speed isn't an issue.

LOL! As an assembly coding fan I must remind you that current compilers are very good and often produce much better code than assembly language programmers. Assembly can still be faster but require a good programmer, a limited problem and a lot of time compared to higher level languages.

[Mrs Beanbag]

Assembly might be faster than C (i don't even care if it is or not, let alone by how much) but the idea that if you're writing in C you wouldn't want to use a fast algorithm instead of a slow one is just so wat i don't even

[meynaf]

Originally Posted by Megol

LOL! As an assembly coding fan I must remind you that current compilers are very good and often produce much better code than assembly language programmers. Assembly can still be faster but require a good programmer, a limited problem and a lot of time compared to higher level languages.

This is completely wrong. Code quality on compilers is a myth.
When I wrote my FLaC decoder it was 4 times faster than its C counterpart (GCC compile). Just an example among many.

[Megol]

Originally Posted by guybrush

Beside the love and the passion that the community have; I would like to see things from a different perspective:

Today, my multi core i5 with a GTX that has more MFLOPS than a battery of flying saucers. The AmigaOS was running on 14 Mhz processor, with 2 MB of ram and a bus at 33 Mhz I believe.

Beside the fact that it was actually a multi-core computer (the CPU was just driving the 3 custom chips); how advanced was the Amiga design, to see nowadays computers with GHz and GB of ram, having troubles to run even simple OS like linux?

I have got a Raspberry pi, since it is cheap and is a great retro machine; that thing has 4 core and 1 Ghz processor I believe, with a GPU integrated and 1 Gb of ram? That's 100 times an Amiga, but when you run even the simplest version of Linux, with minimal UI, it struggle.

I was wondering if today, someone would make an evolution of that design, so we can actually have a full computer, with OS and everything, on a small single board; so we can actually throw away all the various micro controllers that are sold for hobby use (like arduino and such); something light, multitasking, optimized.

is there a reason why the Amiga design was abandoned? From what I see it, a dedicated video card, audio card and northbridge/southbridge are in fact replacing the 3 custom chips, but there is no chance to see an OS like AmigaOS, running as it does on the "puny" specs of a standard Amiga.

What are you calling "the Amiga design"?
The specific combination of blitter, copper, paula? If so it is severely outdated. The copper have no use at all in a modern display system. The blitter is too limited and to slow for modern systems and the paula really isn't much either. The combination of them did provide good performance for a consumer system at the time - that's all.
Or do you mean the use of coprocessors? If so a current modern system have more coprocessors with much more power than the Amiga design.
The GPU can do things Amiga programmers could only dream about.

Did the programmers got worst with the increase of speed? Or Jay was in fact an alien genius that did something that nobody else is able to replicate?

Programmers worse? Perhaps. But the real reason are IMHO 1) that current systems do so much more with a design intended to provide more features 2) rose colored glasses 3) not comparing like to like.

[Megol]

Originally Posted by meynaf

This is completely wrong. Code quality on compilers is a myth.
When I wrote my FLaC decoder it was 4 times faster than its C counterpart (GCC compile). Just an example among many.

There was a time when I would use your argument and could provide examples how bad compilers were. But it isn't the 90s anymore.
A 4x difference without changing the algorithm sound suspicious.

Edit:
Let me guess: your compiler of choice doesn't support 64 bit values well and you require them extensively in order to avoid precision losses?

[meynaf]

Originally Posted by Megol

There was a time when I would use your argument and could provide examples how bad compilers were. But it isn't the 90s anymore.
A 4x difference without changing the algorithm sound suspicious.

We can't truly compare anyway. Who will write a whole program in asm today ? You could just argue that 68k compilers are very bad, that todays x86 (or whatever) are good, and no proof can be shown.

However if you pretend that a compiler can make 68k code that can beat mine, i'll just laugh

Originally Posted by Megol

Edit:
Let me guess: your compiler of choice doesn't support 64 bit values well and you require them extensively in order to avoid precision losses?

Huh, no.

[Mrs Beanbag]

i had to go for a long walk before writing this reply.

it is as if everything i have said about algorithmic time complexity has just gone down a black hole. i said that a lot of problems in modern code are caused by programmers not understanding it, well it seems that old-timer asm coders don't understand it either. They know a hash map is "fast" but that's about it.

Maybe hand-coded asm (by an expert) is 4 times faster (i remember reading the figure 3 times faster on average, elsewhere) but let's just say 10 times for simplicity. In any case, it is a more-or-less constant factor for any given compiler.

The point is, you could write the most efficient bubble sort ever in hand-coded asm, but even a crudely implemented quick sort written in AMOS Basic would still outperform it given a sufficiently large input. The choice of algorithm makes far more difference than the choice of language for all but fairly trivial operations. Asm might be ten times faster than any given language, but an O(n log n) algorithm might be hundreds, thousands, even millions of times faster than a naive O(n^2) algorithm, for the size of data sets you are dealing with.

Well then you would say, if you wrote the quick sort in asm it would be ever faster still. And you'd be right. But the user really doesn't care if he gets his result in a tenth of a second or a hundredth of a second, but he sure as hell doesn't want to have to wait ten minutes.

Of course we care about speed, but performance isn't the only consideration. There are other priorities too, such as development time, portability, maintainability, and of course being able to hire people who can actually do it.

[Megol]

Originally Posted by meynaf

We can't truly compare anyway. Who will write a whole program in asm today ? You could just argue that 68k compilers are very bad, that todays x86 (or whatever) are good, and no proof can be shown.

There's a lot of assembly code produced by those that claim assembly is superior, in general the code is shit.

However if you pretend that a compiler can make 68k code that can beat mine, i'll just laugh

Given the same time and on a large project?

Huh, no.

And you use the same algorithm? Still sounds fishy.

[Megol]

Originally Posted by Mrs Beanbag

i had to go for a long walk before writing this reply.

it is as if everything i have said about algorithmic time complexity has just gone down a black hole. i said that a lot of problems in modern code are caused by programmers not understanding it, well it seems that old-timer asm coders don't understand it either. They know a hash map is "fast" but that's about it.

Maybe hand-coded asm (by an expert) is 4 times faster (i remember reading the figure 3 times faster on average, elsewhere) but let's just say 10 times for simplicity. In any case, it is a more-or-less constant factor for any given compiler.

Such huge differences is either the result of the compiler not being mapped well to the processor or using a feature that can't be directly exposed in the high level language model.
The solution to those problem is in most cases inline assembly code or using intrinsics.

In the general case what causes compilers to be slower is rigid calling conventions.

The point is, you could write the most efficient bubble sort ever in hand-coded asm, but even a crudely implemented quick sort written in AMOS Basic would still outperform it given a sufficiently large input. The choice of algorithm makes far more difference than the choice of language for all but fairly trivial operations. Asm might be ten times faster than any given language, but an O(n log n) algorithm might be hundreds, thousands, even millions of times faster than a naive O(n^2) algorithm, for the size of data sets you are dealing with.

Obviously true for anybody with some programming education. Unless one have a problem with (almost) sorted data

Well then you would say, if you wrote the quick sort in asm it would be ever faster still. And you'd be right. But the user really doesn't care if he gets his result in a tenth of a second or a hundredth of a second, but he sure as hell doesn't want to have to wait ten minutes.

Of course we care about speed, but performance isn't the only consideration. There are other priorities too, such as development time, portability, maintainability, and of course being able to hire people who can actually do it.

And the programmer that have more time on his/her hands can spend it by testing other algorithms potentially leading of huge speedups.

Strictly speaking assembly can be faster than higher level languages (but not generally) but for most problems runtime generated machine code is the fastest. But that's even messier.

[meynaf]

Originally Posted by Megol

There's a lot of assembly code produced by those that claim assembly is superior, in general the code is shit.

It may be shit sometimes, but this shit still runs faster than what compilers produce

Originally Posted by Megol

Given the same time and on a large project?

I can write asm faster than many people write C (or java, or anything else).

Originally Posted by Megol

And you use the same algorithm? Still sounds fishy.

Yes. When i change the algorithm itself, you can expect even bigger gains (i got a routine 14x faster in my heroes2 port, in the editor).

As an example, take my picture viewer (aga only). You will never ever find a compiler that can just approach its speed. Actually it might even beat x86-compiled native code on the same machine when ran under winuae's jit.
http://meynaf.free.fr/pr/mv.lzx

[meynaf]

Originally Posted by Mrs Beanbag

The point is, you could write the most efficient bubble sort ever in hand-coded asm, but even a crudely implemented quick sort written in AMOS Basic would still outperform it given a sufficiently large input.

Of course the algorithm helps, but it's not always like bubble vs quick sort. My asm implementation of jpeg's "slow int" DCT is faster than the compiled "fast int" version - slower algorithm, but still faster code.

Originally Posted by Mrs Beanbag

Well then you would say, if you wrote the quick sort in asm it would be ever faster still. And you'd be right. But the user really doesn't care if he gets his result in a tenth of a second or a hundredth of a second, but he sure as hell doesn't want to have to wait ten minutes.

Obviously, but if you have something taking 90% cpu, you're happy it's not twice as slow. When i rewrote mpega.library's huffman decoder (which was C), i was happy to finally be able to listen to 320kbps mp3s on my 030 with acceptable quality.

Originally Posted by Mrs Beanbag

Of course we care about speed, but performance isn't the only consideration. There are other priorities too, such as development time, portability, maintainability, and of course being able to hire people who can actually do it.

Never said otherwise.