Re: Overview Of New Intel Core i7(Nehalem) Processor

t

It is still step by step. The inlined routines are gone as are many variables and cases in your switch statements. It, however, never breaks out part of the code and sends it over to a different CPU or anything like that.

Many years back I saw an optimizing compiler for Fortran that had a "trivial program" message among the things it would say about your program. If your code could be replaced by just writing fixed text, it would create that program and print that message.

Reply to
MooseFET
Loading thread data ...

You do not know much about MPEG 2 then.

Reply to
Archimedes' Lever

Not if it is packetized.

Reply to
Archimedes' Lever

No shit.

Reply to
Archimedes' Lever

It unrolls loops, factors out loop invariants and common subexpressions, and so forth. Where the debugger stops doesn't have much to do with the source lines at that point.

Cheers,

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
Reply to
Phil Hobbs

of

HTTP,

the

I have actually looked at the mechanism used in both protocols, and =46TP wins on all counts. When i DL files i always look for the FTP link as it is more secure for my end and does not suffer from a bazillion flavorizations. =20 Let me summarize, FTP comes with the OS and is tied in to all browsers that i have tried. Why would i wish to gunk up my system with 57 varieties of unneeded software to do what i can already do?

Reply to
JosephKK

of

=20

But please remember that the checksum is applied by TCP/IP and on each datagram. The datagrams have a typical mtu of 1400 bytes, 4096 bytes, or sometimes 16386 bytes. Errored datagrams are resent before FTP sees them

Reply to
JosephKK

Doesn't change the statistics. It's really noticeable on poor connections.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
Reply to
Phil Hobbs

You'll need to substantiate this.

Nor does HTTP.

HTTP is also available in all browsers.

I don't know, why would you wish to?

What extra software (beyond a web browser) do you think that you need?

Reply to
Nobody

HTTP,

the

Check the RFCs. In particular the partial support for downloads in HTTP, thus the need for a downloader tool to replace much of the functionality native to FTP. e.g. error checking and block retry.

Really? Check the various generations, nicely documented in the RFCs.

Duh. That IS their job.

Precisely my point, it does NOT need 57 different HTTP downloader programs.

Reply to
JosephKK

any of

thinking?

firewall=20

=20

in=20

connections.

Correct. If the connection is poor then the blame for poor performance is on the connection, not the protocol designed to work in spite of poor connections.

Reply to
JosephKK

Yes it looks way different than your source but each step of getting there is a transformation that stays firmly in the step by step world. Even though it no longer looks like your source, it hasn't changed the theory behind the method. If you code the bogosort routine, you will end up with a fast running version of the bogosort and not a hash sort.

Reply to
MooseFET

A 16-bit checksum is not big enough for gigabyte files. 'Nuff said.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
Reply to
Phil Hobbs

That isn't what you claimed above, however. It isn't step-by-step in the source.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
Reply to
Phil Hobbs

I don't see how you get that from what I said. Where did I make that claim?

Reply to
MooseFET

How long are you going to keep trying this "check ..." or "read up on ..." schtick?

I don't doubt that, if there was actually something in the RFCs to substantiate your position, you would have cited chapter and verse. Vague "read the RFCs" statements tend to be reserved for when you wish to impute ignorance but can't actually find anything to substantiate such a claim (or if you find something which might help but where citing a specific opens the door for refutation).

I asked you to substantiate the *security* claims.

FTP doesn't provide any error detection beyond detecting premature termination (which can also be detected for HTTP). Block transfers permit the sender to indicate that portions of the data are missing; they don't deal with transmission errors.

I'm aware that there is more than one version of the HTTP standard. FTP is hardly immune from having been extended. Neither of these amount to "a bazillion flavorizations", although the process of extending HTTP is rather more formalised. Many of the FTP extensions started out as additions to specific programs which were subsequently adopted by other programs and eventually as part of the standard.

Which is precisely my point. HTTP does not need "57 different HTTP downloader programs" either. I've never seen any need to install anything other than the browser itself to download files via HTTP.

Most HTTP download managers are a scam; if you fell for it, that's your problem. The only actual "functionality" which most of them offer is the ability to circumvent the fair sharing of limited bandwidth. If bandwidth is limited, and shared equally by all connections, splitting a download across multiple connections may increase your download speed (or it may just get you banned).

Reply to
Nobody

You said "without ever moving away from a step-by-step description of the program".

Given that the processor can only proceed in steps (some of which may be done in parallel), which we all know perfectly well, merely saying that the program proceeds in steps isn't saying much.

The compiler is supposed to guarantee that the _result_ of the computation is the same as it would be if it interpreted the source line-by-line, which it usually does.

However, it can do so by performing arbitrarily different steps (including steps _not_ meeting the description in the source code, e.g. factoring out loop invariants). Therefore it isn't true that the compiler never moves away from the step-by-step description, unless you want to say that only the compiler's description to the compiler counts, in which case it's a bit of a stretch to call it a description at all.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
Reply to
Phil Hobbs

ine"

e

ame

ize but

on of

any

r

ons,

th the

n

An imaginary super smart compiler could break the problem up to spread it among the CPU cores, convert a bogosort to a shell sort or lots of other things like that that gcc doesn't so.

Yes but it doesn't do thins like hand things off to other CPUs etc. It doesn't break out of the step by step method to get to the result.

I was referring to exactly that. At every step in the optimization, the program is still described in a step by step manner. They don't translate to simultaneous operation as you would see in VHDL or ABEL.

Reply to
MooseFET

formatting link

The reason is that your version is in assembler and retains a 64bit intermediate result for the square multiplication and that register pair gets used for the division so that each succesive overshooting guess will be roughly half the value of the previous iteration until it becomes in range. Unless you handle the carry there is a minor technical error but it doesn't affect the outcome for final valid answers.

I took a strict modulo 32bit bounded arithmetic (which is what most HLLs would do). Although interestingly not what Zonnon (ETH's latest Modula 2 descendant does). This language has some nice features. I have only recently seen the language spec and never used it at all.

formatting link

It is very clearly a reaction against vastly over complicated languages by the computer science teaching community.

No need. Explanation is above.

I think we are basically on the same side here, although how we aim for bug free code is different. I only really trust mathematical proof or a complete brute force validation for every possible input. And I have to say that if I have to go into the danger area I insist on hardware safety interlocks.

I have met too many people in my time who insist vehemently that their code is *ENTIRELY* *BUG* *FREE*. They always shout and they never accept any form of criticism even when faults are found.

I am not defending the huge turgid GUI and their many sins. One of my pet hates is pointers to a who-knows-what object in the Windows GUI. Some of the inner workings of Office are ugly. If you remember Zork then "you are in a maze of twisty little passages all alike" goes a long way towards describing some of the object naming conventions.

Nothing wrong with that at all. Seriously though take a look at the CCI stuff - it is helpful at picking up hotspots where the flow of control is complex and therefore more at risk of containing errors. The number it gives tells you how many test cases are needed to excercise every possible path through the code at least once.

And it is applicable to any language you just have to make a suitable list of the keywords that create forks in the network of paths.

We could haggle about the utility of some of the measures that have been proposed and are still used but a nice summary of them is online at:

formatting link
It is slightly a plug for their product.

Regards, Martin Brown

Reply to
Martin Brown

HTTP,

both the

Vague

I have done my homework. I even pointed in the general direction of the source material. You can go read the relevant RFCs or not. I am not going to do your homework for you. Your choice, learn the material or not. Until then, quit bothering the rest of us.

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.